Re: [Boost] [Describe] Review

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-03-11 09:23:26

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/eea288e04961374721020b5454707590815b2fcf/include/boost/describe/enum.hpp#L12
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...?