Subject: Re: [boost] [config] Variadic template macros in gcc header
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-11-22 18:26:38
On 11/22/2010 2:40 PM, Daniel James wrote:
> On 22 November 2010 14:33, Edward Diener<eldiener_at_[hidden]> wrote:
>> Is this also the intention of Boost in general, that an empty config.h means
>> a compiler that supports C++03 ?
> In general, an empty config.hpp means C++0x. That did seem to be the
> consensus decision, and I think everyone went into it understanding
> the consequences. It looks like the decision was made here (only the
> first few replies are relevant):
In that case Peter Dimov's assumption seems wrong. He is saying that he
did not want you to make the changes because an empty config.h should
mean the C++ standard, aka C++03.
> I also found some earlier discussion where I think the change was
> first proposed (only the first subthread):
> Interestingly, someone proposed that the C++0x BOOST_NO_ macros should
> be defined by default, and then undefined in the config headers.
> Personally, I don't have a strong opinion and will follow the consensus.
My persoanl opinion is:
1) It is confusing to have two different ways to define the lack or
presence of some C++ feature in Boost. I really think this is a bad
approach. It not only becomes a maintenance headache, since any Boost
library can use either of the two ways, but it is also confusing to new
library developers using or not using C++ features in Boost. I feel very
strongly that Boost should strive for a single configuration macro which
means a specific thing.
2) If no config.h means C++0x and not C++03 then you should be able to
make the change you had intended to do despite Peter's objection to it.
BTW my search shows now a few other instances where your change to get
rid of the BOOST_HAS_ versions regarding variadic templates and rvalue
references would need to be made if you revisit the change.
a) I can easily live with the BOOST_NO_ macros defined by default and
then #undef'ed in the appropriate cases if that solves a usage problem,
but others might find that backward. Even in that case config.h should
not be empty but would need to at least include whatever common header
file defined all the BOOST_NO_ macros by default. But I think the
current solution is fine as long as everyone agrees that a truly empty
config.h means a C++0x compliant compiler, as rare as that may actually
b) If on the other hand, because of the rarity of a C++0x compiler in
terms of Boost features, it is felt that an empty config.h really should
mean just current C++ standard compliance, aka C++03, then the system of
the way that BOOST_NO_ macros are defined seems wrong to me and at least
the BOOST_NO_ macros which refer strictly to C++0x features should be
defined by default, undef'ed as needed, and even an empty config.h must
include those definitions, very probably by including a header file
which makes them. This change would of course entail many changes in the
config header files regarding these macros.
Finally I am not arguing for or against what Peter objected to. Based on
his assumption he was perfectly correct.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk