From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-03-11 16:58:18
> The problematic case is BOOST_DEFINE_ENUM(A), which I actually don't
> handle properly even on newer compilers. It only compiles because of
> another problem - that a trailing comma is silently accepted and produces
> an invalid descriptor. BOOST_DEFINE_ENUM_CLASS(A) fails, and so will the
> enum one, once I unify the two macros.
IMO that case is not problematic because you only would need to
differentiate between BOOST_DEFINE_ENUM(A) and BOOST_DEFINE_ENUM(A, xxx)
but not BOOST_DEFINE_ENUM(A,). This is possible without any extension:
https://godbolt.org/z/1qrrn4
Another point could be made that enums without enumerators are simply
unsupported as I fail to see a use case.
In either case the GNU extension is not required so I see no reason to
not support enums
> It's not used, but by mistake. :-)
My point was that the more specific macro name allows to see that more
easily. E.g. I had to ask, which GNU extension you need as that isn't
mentioned anywhere in the code
I have less of an issue with the CXX11 macro, although I'd likely call
it BOOST_DEFINE_ENABLE or so, but that's bikeshedding.(Actually: see below)
> MSVC implicitly does the ## thing without being told. Their newer preprocessor,
> enabled with /Zc:preprocessor, does not (as pointed out by Edward Diener), but
> it supports the ## extension.
Does this mean the library will break in that mode? Or could you always
use the ## extension? (Didn't understand if only the new PP supports it)
> The motivation, as I said, is for people to be able to BOOST_DESCRIBE
their types without making their libraries require C++14.
Sure, makes sense, I don't mind as I have since then realized, that
calling the functions will fail to compile. So only "issue" is, that
mistyped/outdated stuff in the macros will not appear until compiled
with C++11(14?). On that matter: The library is C++14, isn't it? I'm
confused by the BOOST_DESCRIBE_CXX11 macro. What is it used for? My
impression is, that the library cannot be used in C++11 mode at all.
(I.e. call functions), so that macro doesn't make much sense to me
Similar to my actual point here (tests being compiled and run as No-Ops
instead of not at all) I don't understand the tests. E.g.
https://github.com/pdimov/describe/blob/eea288e04961374721020b5454707590815b2fcf/test/members_test2.cpp
Why are there conditions on C++11 and 14 if the macros are supposed to
work/compile in C++98?
Unless I have misunderstood something my proposal would be:
- 1 macro to enable the C++14 parts which do not require the ##
extension (e.g. the enum code)
- 1 macro to additionally enable the parts which require that extension
(and C++14 of course)
- specific names for that (i.e. not simply *_CXX14 because that
extension isn't 14 [some of that is actually in 20 IIRC])
- Use B2 to enable/disable tests