Re: [boost] [mpl] has_xxx.hpp potential problem

Subject: Re: [boost] [mpl] has_xxx.hpp potential problem
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-08-03 17:27:46

On Tue, Aug 3, 2010 at 4:57 PM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 8/3/2010 2:48 PM, Edward Diener wrote:
>>
>> I am looking at the trunk version of has_xxx.hpp.
>>
>> The macros BOOST_MPL_HAS_MEMBER_TEMPLATE_SUBSTITUTE_PARAMETER and
>> BOOST_MPL_HAS_MEMBER_TEMPLATE_ACCESS appear to be not defined anywhere.
>>
>> This is OK for the first because it is actually not used anywhere to
>> generate code, although it is being passed around to other macros. If it
>> serves no purpose, perhaps it should be removed as it then only serves
>> to obfuscate the code, unless of course there are future plans to define
>> it.
>>
>> The second, however, is being used to generate code in one instance
>> dependent on some version of a compiler, so it needs to be defined
>> somewhere or else an error will occur.
>>
>> Please check this out if this is going into 1.44.
>
> My apologies. This is a false alarm as the macro which eventually uses
> BOOST_MPL_HAS_MEMBER_TEMPLATE_ACCESS can never be called.

Correct but thanks for you're comments. I think you probably found a
dead branch of code that is never actually generated (around line
381). That code should have been deleted for clarities sake. Sorry for
the confusion. But you're also right that the two access macros could
be refactored out of the implementation. Here's some background info.

Historically, in the pre-release version, those two macros were used
to specify the syntax for accessing the member template for a given
number of arguments, since different compilers accepted different
syntax. But now, in the first release version, has_xxx_template
detects member templates for any number of arguments, and this change
in semantics allowed the implementation to be unified (somewhat)
across compilers. The user-end macro, HAS_XXX_TEMPLATE_DEF, only
generates two variations of the has_xxx_template metafunction for
different compilers: one uses template-based SFINAE on old versions of
msvc (pre 8) and the other uses function-based SFINAE on all other
platforms.

The design of the macros is aiming at an abstraction of the syntactic
components of SFINAE (e.g. a substitution component, a test component,
etc.). Since older compilers did not support SFINAE in every context,
different implementations of these components could be brought
together on different platforms to build an operable has_xxx_template
metafunction. But I think there's room for improvement, as you point
out, if only to make the implementation clearer.

Daniel Walker