Subject: Re: [boost] [config] Variadic template macros in gcc header
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-11-21 10:29:19
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.