On Tue, Aug 3, 2010 at 4:57 PM, Edward Diener <eldiener@tropicsoft.com> 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