77 lines
3.4 KiB
Plaintext
77 lines
3.4 KiB
Plaintext
[/
|
|
(C) Copyright Edward Diener 2011-2015
|
|
Distributed under the Boost Software License, Version 1.0.
|
|
(See accompanying file LICENSE_1_0.txt or copy at
|
|
http://www.boost.org/LICENSE_1_0.txt).
|
|
]
|
|
|
|
[section:vmd_identifying Identifying data types]
|
|
|
|
[heading 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.
|
|
The general name I will use in this documentation for these
|
|
specific macros is "identifying macros." The identifying macros
|
|
also share with BOOST_VMD_IS_EMPTY the inherent flaw
|
|
mentioned when discussing BOOST_VMD_IS_EMPTY, 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.
|
|
* even if the function-like macro takes one parameter, passing
|
|
emptiness to that macro could cause a preprocessing error.
|
|
|
|
The obvious way to avoid the BOOST_VMD_IS_EMPTY problem with 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 has 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.
|
|
|
|
[heading 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, but 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 entirely.
|
|
|
|
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.
|
|
|
|
[endsect]
|