Identifying data types

Identifying macros and BOOST_VMD_IS_EMPTY

The various macros for identifying VMD data types complement the ability to identify emptiness using BOOST_VMD_IS_EMPTY. They also share with BOOST_VMD_IS_EMPTY the inherent flaw mentioned when discussing this macro, since they themselves use BOOST_VMD_IS_EMPTY to determine that the input has ended.

To recapitulate the flaw with BOOST_VMD_IS_EMPTY:

using a standard C++ compiler if the input ends with the name of a function-like macro, and that macro takes two or more parameters, a preprocessing error will occur.
using the VC++ compiler if the input consists of the name of a function-like macro, and that macro when invoked with no parameters returns a tuple, the macro erroneously returns 1, meaning that the input is empty.

For the macros which identify Boost PP data types the use of BOOST_VMD_IS_EMPTY occurs only after these macros recognize the beginning tuple in the input. So if the input begins with the situation above that causes BOOST_VMD_IS_EMPTY to work incorrectly, the Boost PP data type identifying macros will still work correctly. It is only if, when a beginning tuple has been found, that if the situation above occurs that induces the flaw with BOOST_VMD_IS_EMPTY with the rest of the input that we will have the same problem as BOOST_VMD_IS_EMPTY.

For the macros which identify v-identifiers and v-numbers the use of BOOST_VMD_IS_EMPTY occurs not only with the beginning input but with any input still remaining after the possible beginning v-identifier or v-number. So the same problem of BOOST_VMD_IS_EMPTY will occur with these identifying macros.

The obvious way to avoid the BOOST_VMD_IS_EMPTY problem wih the identifying macros is to design input so that the name of a function-like macro is never passed as a parameter. This can be done, if one uses VMD and does design situations where the input could contain a function-like macro name, by having that function-like macro name placed within a Boost PP data type, such as a tuple, without attempting to identify the type of the tuple element using VMD. In other word if the input is:

( SOME_FUNCTION_MACRO_NAME )

and we have the macro definition:

#define SOME_FUNCTION_MACRO_NAME(x,y) some_output

VMD can still parse the input as a tuple, if desired, using BOOST_VMD_IS_TUPLE without encountering the BOOST_VMD_IS_EMPTY problem. However if the input is:

SOME_FUNCTION_MACRO_NAME

either directly or through accessing the above tuple's first element, and the programmer attempts to use BOOST_VMD_IS_IDENTIFIER with this input, the BOOST_VMD_IS_EMPTY problem will occur.

Identifying macros and programming flexibility

The VMD identifying macros give the preprocessor metaprogrammer a great amount of flexibility when designing macros. It is not merely the flexibility of allowing direct parameters to a macro to be different data types, and having the macro work differently depending on the type of data passed to it, it is also the flexibility of allowing individual elements of the higher level Boost PP data types to be different data types and have the macro work correctly depending on the type of data type passed as part of those elements.

With this flexibility also comes a greater amount of responsibility. For the macro designer this responsibility is twofold:

To carefully document the possible combinations of acceptable data and what they mean.
To balance flexibility with ease of use so that the macro does not become so hard to understand that the programmer invoking the macro gives up using it intelligently.

For the programmer invoking a macro the responsibility is to understand the documentation and not attempt to pass to the macro data which may cause incorrect results or preprocessing errors.