Re: [boost] [config] Variadic template macros in gcc header

Subject: Re: [boost] [config] Variadic template macros in gcc header
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-11-22 09:33:04

On 11/22/2010 8:36 AM, Daniel James wrote:
> On 21 November 2010 17:49, Edward Diener<eldiener_at_[hidden]>  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.