C++17 detection is too broad

[Hartmut Kaiser]

Dear Klaus,

this is just to let you know that one of the recent commits to Blaze master (https://bitbucket.org/blaze-lib/blaze/commits/e9fc567e6bcd5ba11fd0611dc2f0863d60b75d2) breaks our builds. While this could be a temporary issue as you might be planning to augment those changes in the future, I'd like to suggest to make the detection of C++17 features a bit more fine-grained (instead of just looking at the __cplusplus macro). The way you have set up things now will make all compilations fail that rely on a compiler that understands -std=c++17 (as the compiler itself is conforming) but that might not have all of the C++17 library features implemented (like std::uninitialized_move, std::destroy, etc.).

Thanks! Regards Hartmut

[Klaus Iglberger]

Hi Helmut!

Thanks a lot for pointing out this defect. Although unfortunately I apparently don't have a compiler with this property in my current test setup, I understand the problem and will fix it as quickly as possible. Thanks again,

Best regards,

Klaus!

[Klaus Iglberger]

Commit d2c1363 resolves the compilation issues with compilers that don't support the C++17 raw memory algorithms that was introduced with commit e9fc567. The fix is immediately available via cloning the Blaze repository and will be officially released in Blaze 3.5.

[Hartmut Kaiser]

Thanks for the quick fix Klaus!