[config] Variadic template macros in gcc header
Why is there two mutually exclusive macros indicating variadic template support for gcc ? There is the established BOOST_NO_VARIADIC_TEMPLATES which says that any compiler does not have variadic template support. Then I find that for gcc there is also BOOST_HAS_VARIADIC_TMPL which evidently says that the compiler does have variadic template support, and is in no other compiler header file than the gcc one. Since the two config macros are mutually exclusive in the gcc header file, why is there any need for BOOST_HAS_VARIADIC_TMPL ?
Why is there two mutually exclusive macros indicating variadic template support for gcc ?
There is the established BOOST_NO_VARIADIC_TEMPLATES which says that any compiler does not have variadic template support. Then I find that for gcc there is also BOOST_HAS_VARIADIC_TMPL which evidently says that the compiler does have variadic template support, and is in no other compiler header file than the gcc one. Since the two config macros are mutually exclusive in the gcc header file, why is there any need for BOOST_HAS_VARIADIC_TMPL ?
Historical baggage - the BOOST_HAS_ one is deprecated and no longer documented, new code should always be using the BOOST_NO_ version, the other is present for backwards compatibility. BTW I've just committed a fix to Trunk to make sure that the two versions are normalized with respect to each other. If someone wants to take on the task of getting the release branch free of the BOOST_HAS_ version, then they can also remove it from Boost.Config ;-) HTH, John.
On 21 November 2010 09:40, John Maddock <boost.regex@virgin.net> wrote:
Historical baggage - the BOOST_HAS_ one is deprecated and no longer documented, new code should always be using the BOOST_NO_ version, the other is present for backwards compatibility. BTW I've just committed a fix to Trunk to make sure that the two versions are normalized with respect to each other. If someone wants to take on the task of getting the release branch free of the BOOST_HAS_ version, then they can also remove it from Boost.Config ;-)
I tried a while ago but there was some resistance as code using BOOST_HAS_ will work on a compliant C++03 compiler with an empty config file. Daniel
On 11/21/2010 4:51 AM, Daniel James wrote:
On 21 November 2010 09:40, John Maddock<boost.regex@virgin.net> wrote:
Historical baggage - the BOOST_HAS_ one is deprecated and no longer documented, new code should always be using the BOOST_NO_ version, the other is present for backwards compatibility. BTW I've just committed a fix to Trunk to make sure that the two versions are normalized with respect to each other. If someone wants to take on the task of getting the release branch free of the BOOST_HAS_ version, then they can also remove it from Boost.Config ;-)
I tried a while ago but there was some resistance as code using BOOST_HAS_ will work on a compliant C++03 compiler with an empty config file.
I don't understand your remark. As far as I can see BOOST_HAS_VARIADIC_TMPL needs to be defined or not to use it in code that depends on it so an empty compiler config file does not do anything to promote use of variadic templates depending on that macro. In fact an empty compiler config file will not have BOOST_NO_VARIADIC_TEMPLATES defined so anyone using that instead to decide whether or not variadic templates are supported will assume they are for a compiler whose config file is empty. But I have the feeling you mean something else.
On 21 November 2010 15:35, Edward Diener <eldiener@tropicsoft.com> wrote:
On 11/21/2010 4:51 AM, Daniel James wrote:
On 21 November 2010 09:40, John Maddock<boost.regex@virgin.net> wrote:
If someone wants to take on the task of getting the release branch free of the BOOST_HAS_ version, then they can also remove it from Boost.Config ;-)
I tried a while ago but there was some resistance as code using BOOST_HAS_ will work on a compliant C++03 compiler with an empty config file.
I don't understand your remark.
Take a look at: https://svn.boost.org/trac/boost/ticket/3986
On 11/21/2010 11:15 AM, Daniel James wrote:
On 21 November 2010 15:35, Edward Diener<eldiener@tropicsoft.com> wrote:
On 11/21/2010 4:51 AM, Daniel James wrote:
On 21 November 2010 09:40, John Maddock<boost.regex@virgin.net> wrote:
If someone wants to take on the task of getting the release branch free of the BOOST_HAS_ version, then they can also remove it from Boost.Config ;-)
I tried a while ago but there was some resistance as code using BOOST_HAS_ will work on a compliant C++03 compiler with an empty config file.
I don't understand your remark.
Take a look at:
"On a standard-compliant compiler, shared_ptr supports compilation with an empty config.hpp. This will no longer be the case after this patch. " Evidently with an empty config.h using the old BOOST_HAS_ macros neither BOOST_HAS_VARIADIC_TMPL nor BOOST_HAS_RVALUE_REFS will be defined therefore causing shared_ptr not to use them. Similarly with an empty config.h both BOOST_NO_VARIADIC_TEMPLATES and BOOST_NO_RVALUE_REFERENCES will not be defined causing shared_ptr to use both features even if the compiler does not support them. That seems to be what Peter Dimov is saying. But that looks like a problem with all the BOOST_NO_ macros since an empty config.h will never have any of those macros defined. But that brings up the question of what is meant by a "standard-compliant" compiler. If Boost really supposed to be compiled by a standard-compliant compiler which essentially has an empty config.h than "standard-compliant" should mean one that supports all the latest C++0x features in which case variadic templates and rvalue references are supported and the BOOST_NO_ macro system is entirely correct. But if "standard-compliant" just means the C++03 standard, then clearly any compiler needs a config.h and its own compiler header file with the proper BOOST_NO_ features defined. Or else the BOOST_NO_ system has to be changed to reflect only C++03 standard features and not the C++0x features it currently also encompasses.
On 21 November 2010 17:49, Edward Diener <eldiener@tropicsoft.com> wrote:
"On a standard-compliant compiler, shared_ptr supports compilation with an empty config.hpp. This will no longer be the case after this patch. "
Evidently with an empty config.h using the old BOOST_HAS_ macros neither BOOST_HAS_VARIADIC_TMPL nor BOOST_HAS_RVALUE_REFS will be defined therefore causing shared_ptr not to use them. Similarly with an empty config.h both BOOST_NO_VARIADIC_TEMPLATES and BOOST_NO_RVALUE_REFERENCES will not be defined causing shared_ptr to use both features even if the compiler does not support them. That seems to be what Peter Dimov is saying.
Yes, I thought it was pretty clear.
But that looks like a problem with all the BOOST_NO_ macros since an empty config.h will never have any of those macros defined.
Boost used to only use BOOST_NO_ macros for C++03 features for this reason. The decision was made to target C++0x compilers a while back, which is why the old macros for C++0x features were deprecated and replaced with the new macros. But Peter wants to target C++03 compilers, so he still uses the old deprecated macros.
But that brings up the question of what is meant by a "standard-compliant" compiler.
He meant the current standard at the time of writing, ie. C++03 (but that doesn't mean he'll necessarily change as soon as C++0x is fully standardised).
If Boost really supposed to be compiled by a standard-compliant compiler
Peter was only writing about his own libraries. He hasn't tried to influence the rest of boost. I find his position understandable since, for a lot of people, his libraries are essential building blocks for C++ development, so reliability and ease of use is more important than using the latest C++ features. I seem to have become his proxy in this. That's not a good idea as I'll end up misrepresenting him in some way (or maybe have already). If you want to take this further, I'd suggest starting a new thread with his libraries in the subject line. Daniel
On 11/22/2010 8:36 AM, Daniel James wrote:
On 21 November 2010 17:49, Edward Diener<eldiener@tropicsoft.com> wrote:
"On a standard-compliant compiler, shared_ptr supports compilation with an empty config.hpp. This will no longer be the case after this patch. "
Evidently with an empty config.h using the old BOOST_HAS_ macros neither BOOST_HAS_VARIADIC_TMPL nor BOOST_HAS_RVALUE_REFS will be defined therefore causing shared_ptr not to use them. Similarly with an empty config.h both BOOST_NO_VARIADIC_TEMPLATES and BOOST_NO_RVALUE_REFERENCES will not be defined causing shared_ptr to use both features even if the compiler does not support them. That seems to be what Peter Dimov is saying.
Yes, I thought it was pretty clear.
But that looks like a problem with all the BOOST_NO_ macros since an empty config.h will never have any of those macros defined.
Boost used to only use BOOST_NO_ macros for C++03 features for this reason. The decision was made to target C++0x compilers a while back, which is why the old macros for C++0x features were deprecated and replaced with the new macros. But Peter wants to target C++03 compilers, so he still uses the old deprecated macros.
The issue still remains, whether anyone really wants to address it or not, that with the BOOST_NO_ form of the macros an empty config.h implies a compiler supporting not just C++03 but also Boost C++0x features. Yet Peter's response very reasonably says that he wants to support the idea that his library should work with an empty config.h and a compiler that supports just C++03 in the process. Is this also the intention of Boost in general, that an empty config.h means a compiler that supports C++03 ? If so, then I personally think that the BOOST_NO_ macros encompassing C++0x features are a mistake and only the equivalent BOOST_HAS_ macros for those features should exist. If not, and therefore an empty config.h means support for all C++0x features in Boost or an empty config.h is not to be considered at all, then Peter's objection and the way he uses the BOOST_HAS_ equivalents for his library is a mistake in my opinion.
But that brings up the question of what is meant by a "standard-compliant" compiler.
He meant the current standard at the time of writing, ie. C++03 (but that doesn't mean he'll necessarily change as soon as C++0x is fully standardised).
If Boost really supposed to be compiled by a standard-compliant compiler
Peter was only writing about his own libraries. He hasn't tried to influence the rest of boost. I find his position understandable since, for a lot of people, his libraries are essential building blocks for C++ development, so reliability and ease of use is more important than using the latest C++ features.
The problem is that if some library, or Boost in general, views an empty config.h as valid and as supporting C++03, then BOOST_HAS_ macro versions of C++0x features, which are inversely equivalent to their corresponding BOOST_NO_ features, must always remain and can never be removed. Furthermore it is possible that more of these inversely corresponding BOOST_HAS_ macros to their C++0x BOOST_NO_ equivalents, will need to be added. That's fine with me, but I am wondering if it is fine with John Maddock, since he appears to be the major "developer" involved with maintaining 'config', or if it is fine with you and other Boost developers.
I seem to have become his proxy in this. That's not a good idea as I'll end up misrepresenting him in some way (or maybe have already). If you want to take this further, I'd suggest starting a new thread with his libraries in the subject line.
I have no personal axe to grind other than pointing out what the general issue appears to be as I see it. As long as I understand the reason for the inversely equivalent BOOST_NO_ and BOOST_HAS_ macros I can live with it. But from a design point of view I feel that there is confusion which Boost might do well to try to straighten out.
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): http://thread.gmane.org/gmane.comp.lib.boost.devel/175638 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. Daniel
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.
Edward Diener wrote:
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.
No, I'm not saying that it _should_ mean C++03, I'm saying that it does mean C++03, and has meant C++03 for years. A previously valid (but admittedly rare) use case - using shared_ptr with an empty config.hpp - will be rendered invalid. This is not an assumption, it is a fact. It will be OK to make the change when most compilers we care about are reasonably C++0x compliant in their default mode, but this is not the case today.
On 11/24/2010 9:00 AM, Peter Dimov wrote:
Edward Diener wrote:
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.
No, I'm not saying that it _should_ mean C++03, I'm saying that it does mean C++03, and has meant C++03 for years.
Then you obviously disagree with what Daniel James says in his comment above, that an empty config.h means C++0x and that seems to be the consensus decision.
A previously valid (but admittedly rare) use case - using shared_ptr with an empty config.hpp - will be rendered invalid. This is not an assumption, it is a fact.
I am glad it is a fact. In which case the design of the BOOST_NO_ macros which pertain to C++0x seems wrong to me, since an empty config.h would not define any of those macros, thus implying that a compiler with an empty config.h supports these C++0x features.
On 11/21/2010 4:40 AM, John Maddock wrote:
Why is there two mutually exclusive macros indicating variadic template support for gcc ?
There is the established BOOST_NO_VARIADIC_TEMPLATES which says that any compiler does not have variadic template support. Then I find that for gcc there is also BOOST_HAS_VARIADIC_TMPL which evidently says that the compiler does have variadic template support, and is in no other compiler header file than the gcc one. Since the two config macros are mutually exclusive in the gcc header file, why is there any need for BOOST_HAS_VARIADIC_TMPL ?
Historical baggage - the BOOST_HAS_ one is deprecated and no longer documented, new code should always be using the BOOST_NO_ version, the other is present for backwards compatibility. BTW I've just committed a fix to Trunk to make sure that the two versions are normalized with respect to each other. If someone wants to take on the task of getting the release branch free of the BOOST_HAS_ version, then they can also remove it from Boost.Config ;-)
I only found the BOOST_HAS_VARIADIC_TMPL defined in the gcc.hpp file. There are also tests for it in config, as well as tests for the absence of BOOST_NO_VARIADIC_TEMPLATES, and the tests are exactly the same ( created by Doug Gregor ). As I remember your system of generating tests for config, once the .ipp file is removed everything works properly after that. The only place I found it is used outside of config is in Peter Dimov's make_shared and some files connected to that. It does seem as if changing his use of '#if defined( BOOST_HAS_VARIADIC_TMPL )' to '#if !defined( BOOST_NO_VARIADIC_TEMPLATES )' in his file and test is straightforward. I can take on that task but I do not believe I have write access to Boost trunk unless my access to the Boost sandbox gives me that. I can of course send you many svn patches if you like. I'd have to look at shared_ptr regressions test, as well as config regression tests, to make sure there is no unexpected failures once the changes are made.
participants (4)
-
Daniel James -
Edward Diener -
John Maddock -
Peter Dimov