12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576 |
- [/
- (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]
|