-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modernize to c++14 for gcc/clang like compilers #1074
Conversation
This reverts commit e9958ed.
…on 1.4.0 backwards)
I belief that it was another situation back then. There was a plethora of different available compilers, which nowadays have converged to LLVM/CLang, GCC and MSVC basically. In the past we have accepted patches for all kinds of exotic combinations (e.g. Gcc on Cygwin). |
We are probably safe to go all C++14 if that would be easier to deal with. I just won't go to C++20 for a long while. |
I see codecov is mad about a bunch of missing test cases. I guess I will take another shot at improving coverage after this one goes in. |
partial merge, jp_exception still to do
I am hoping to get out 1.5 this month. Is this PR in good shape? |
@marscher should I try to get this included in 1.5 |
Sorry for the delay. I guess this is in a good shape - it has been a while since I looked into it. One major change is that JPypeExceptions are now children of std::runtime_error. Honestly I cannot tell if this has any unwanted side effects. |
return data[0]; | ||
} | ||
if (_PyUnicode_STATE(self).kind == PyUnicode_1BYTE_KIND) | ||
{ | ||
Py_UCS1 *data = (Py_UCS1*) ( ((PyCompactUnicodeObject*) self) + 1); | ||
auto *data = (Py_UCS1*) ( ((PyCompactUnicodeObject*) self) + 1); |
Check failure
Code scanning / CodeQL
Suspicious pointer scaling High
PyJPChar
return data[0]; | ||
} | ||
Py_UCS2 *data = (Py_UCS2*) ( ((PyCompactUnicodeObject*) self) + 1); | ||
auto *data = (Py_UCS2*) ( ((PyCompactUnicodeObject*) self) + 1); |
Check failure
Code scanning / CodeQL
Suspicious pointer scaling High
PyJPChar
self->m_Obj.utf8_length = 0; | ||
} else | ||
{ | ||
|
||
Py_UCS2 *data = (Py_UCS2*) ( ((PyCompactUnicodeObject*) self) + 1); | ||
auto *data = (Py_UCS2*) ( ((PyCompactUnicodeObject*) self) + 1); |
Check failure
Code scanning / CodeQL
Suspicious pointer scaling High
m_Error.l = errType; | ||
m_Message = msn; | ||
//m_Message = msn; |
Check notice
Code scanning / CodeQL
Commented-out code Note
@@ -154,15 +154,15 @@ | |||
{ | |||
if (_PyUnicode_STATE(self).ascii == 1) | |||
{ | |||
Py_UCS1 *data = (Py_UCS1*) (((PyASCIIObject*) self) + 1); | |||
auto *data = (Py_UCS1*) (((PyASCIIObject*) self) + 1); |
Check failure
Code scanning / CodeQL
Suspicious pointer scaling High
So far, we have used c++14 standard only for the Windows platform, but Unix still used c++11.
This PR modernizes some constructs already introduced in c++11, but really not used so far. I've used clang-tidy to provide most of the fixes.
In addition I cleaned up JPype.h to only contain STL related stuff, if it is mandatory to declare types used within headers. The implementation now includes what is really needed. This should speed up compilation a little bit.
Another important change is that JPypeException now derives from std::runtime_error, which adds some additional safety. The copy constructor of JPypeException was not marked "noexcept", so it could have thrown exceptions during the initialization (leading to a terminate call). As I didn't get the logic why the (string) message gets copied into a stringstream without any other additions just to make a string and then a cstring again, I just got rid of this behaviour.
By using a std exception type, we are safe that we use the proper standard definitions for exception safety. If this is undesired, I can also revert these changes.