Am 10.03.21 um 18:44 schrieb Peter Dimov via Boost:
Alexander Grund wrote:
- All tests are silently skipped if C++(14) support is not good enough ("silently" as in b2 they will be reported as "run" although nothing is done) I changed that recently on purpose, as the library is intended to be "usable" (that is, not cause compilation errors) if types are described under C++11.
The describe_* primitives don't return anything then, of course, but this makes it possible to BOOST_DESCRIBE types without having to #ifdef. I'm personally not a fan of that being the default especially as there are now many levels: C++98, C++11, GNU++14, C++14 and each silently enables parts of the library.
I kinda understand the motivation: Likely being able to pull in external, C++11/14 libs (headers) into C++98/11 libs, but I think the use case is too narrow: Likely other parts won't work But this comment was on tests: Why not skip tests altogether if the required features are not supported just as done with pretty much any other test? And add (compile) tests for C++98/11 mode (or actually all) where only the macros are used? To empathize: My complaint was, that it is currently indistinguishable if a test succeeded or was completely ignored due to C++ requirements.
- requirement for gnu++14 on GCC < 8 is also very odd for a Boost lib. I'm not sure what is supposedly missing here, but at least the enum stuff seems to fundamentally work at least: https://godbolt.org/z/n3foGn The ##__VA_ARGS__ extension is not supported. See https://godbolt.org/z/hc3eEv.
The default for g++ 6/7 when no -std is given is gnu++14, so I expect this to cause less trouble than one would ordinarily expect. Of course it would have been better for the library to just work, but I don't know how to fix it. (I've already learned way too much preprocessor programming than the WHO recommends.) That's why I argued to use the BOOST_* feature test macros (or own ones if new ones are required). E.g. you also disabled the enum stuff although it works just fine: https://github.com/pdimov/describe/blob/eea288e04961374721020b5454707590815b... https://godbolt.org/z/n3foGn
This could be avoided if you would have used BOOST_NO_VARIADIC_EXPAND_FEATURE (or so) which would allow to see, that this feature is not used for the enum case. This is meant as a suggestion for improvement to make this even more useful. I experimented a bit with that and found a PoC that it does work with GCC < 8 under at least some constraints: https://godbolt.org/z/9WxnbG Or https://godbolt.org/z/PEKofd There might be more options, see e.g. https://gustedt.wordpress.com/2010/06/08/detect-empty-macro-arguments/ Although the default is gnu++ the majority of software installations I've seen do add -std=c++xx in their configure scripts (if they check at all) and in the project I'm maintaining we use the CMake setting to disallow the GNU stuff. I'm also actually surprised, that it works on MSVC without ##__VA_ARGS__ . I though their preprocessor is now standards conformant...?