On 11/22/2010 2:40 PM, Daniel James wrote:
On 22 November 2010 14:33, Edward Diener<eldiener@tropicsoft.com> 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):
http://thread.gmane.org/gmane.comp.lib.boost.devel/151193
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. 3) 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 be currently. 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.