general code cleanup #184
general code cleanup #184
Conversation
| #define NPY_BEGIN_THREADS_DEF PyThreadState *_save=NULL; | ||
| #define NPY_BEGIN_THREADS _save = PyEval_SaveThread(); | ||
| #define NPY_END_THREADS do {if (_save) PyEval_RestoreThread(_save);} while (0); | ||
| #define NPY_BEGIN_THREADS_DEF PyThreadState *_save=NULL |
There was a problem hiding this comment.
A potential problem with this change is that originally most of these macros were used without a trailing semicolon. I tried to clean most of those uses up, but some may remain. Have you tested this or audited the places they are used? I'm also concerned about third party code, although they should be using semicolons, but they may have just copied earlier usage.
Since double semicolons don't cause compiler problems, so I'd just as soon leave them in even if it is a bit ugly.
There was a problem hiding this comment.
I am mixed on this. The code uses NPY_BEGIN_THREADS*, NPY_END_THREADS, and the non-NPY_ prefix versions of the macros with semicolons everywhere, so getting rid of the semicolons there is safe. Of course, if there is third-party code out there that doesn't use the semicolons, then it will break. I have no idea if this is the case or not.
There was a problem hiding this comment.
I think in general it's better forcing the usage to have the semicolon, some auto-indent code behaves poorly with that. I agree with Chuck about third party code - this doesn't affect the ABI, but some third party code might have to add a semicolon. If they do this, their code will still work with older NumPy versions, so it's probably fine.
|
Generally looks good. I'm always a bit wary of these sort of changes and like to be sure they've been tested, but then again, the code does need cleaning up. Thanks for looking into this. |
|
PS, changing blocks, which don't need following semi-colons, into statements that do can also cause problems with existing code. |
|
Thanks for reviewing this. I submitted the pull request in a bit of a hurry, so I didn't try building and testing numpy with the changes. I have now done so, and with a little bit more change for consistency/errors correction, the tests pass. I am not very familiar with github pull request system. I can submit another pull request with my commit on top of the current master, and close this one, or is there a way to modify this pull request? |
|
You can push new commits to your github branch and they will show up here. That is the preferred way as the comments are preserved. Just don't try rewriting any of the history. |
|
That was easy. I built numpy with my changes and it passes all the tests. I believe that these changes are harmless overall, but other than the check for |
|
Pushed in 7bb277b. We'll see how it goes. Thanks. |
feat: Add vhaddq_[s8|s16|s32|u8|u16|u32]
Pretty simple and small changes: remove semicolons from #defines, add "do... while(0)" to some macros, and check for PyArray_malloc() failure right after the call.