|
|
A.4. Preprocessor Library AbstractionsIn this section we'll discuss the basic abstractions of the Preprocessor library and give some simple examples of each. A.4.1. RepetitionThe repeated generation of class T0, class T1,... class Tn that we achieved using BOOST_PP_ENUM_PARAMS was a specific case of the general concept of horizontal repetition. The library also has a concept of vertical repetition, which we'll get to in a moment. Horizontal repetition macros are all found in the library's repetition/ subdirectory. A.4.1.1 Horizontal RepetitionTo generate the tiny_size specializations using horizontal repetition, we might write the following:
#include <boost/preprocessor/repetition.hpp>
#include <boost/preprocessor/arithmetic/sub.hpp>
#include <boost/preprocessor/punctuation/comma_if.hpp>
#define TINY_print(z, n, data) data
#define TINY_size(z, n, unused) \
template <BOOST_PP_ENUM_PARAMS(n, class T)> \
struct tiny_size< \
BOOST_PP_ENUM_PARAMS(n,T) \
BOOST_PP_COMMA_IF(n) \
BOOST_PP_ENUM( \
BOOST_PP_SUB(TINY_MAX_SIZE,n), TINY_print, none) \
> \
: mpl::int_<n> {};
BOOST_PP_REPEAT(TINY_MAX_SIZE, TINY_size, ~)
#undef TINY_size
#undef TINY_print
The code generation process is kicked off by calling BOOST_PP_REPEAT, a higher-order macro that repeatedly invokes the macro named by its second argument (TINY_size). The first argument specifies the number of repeated invocations, and the third one can be any data; it is passed on unchanged to the macro being invoked. In this case, TINY_size doesn't use that data, so the choice to pass ~ was arbitrary.[5]
Each time the TINY_size macro is invoked by BOOST_PP_REPEAT, it generates a different specialization of tiny_size. The macro accepts three parameters.
Because its replacement-list covers several lines, all but the last line of TINY_size is continued with a trailing backslash. The first few of those lines just invoke BOOST_PP_ENUM_PARAMS (which we already used in the primary template) to generate comma-separated lists, so each invocation of TINY_size produces something equivalent to:[6]
template <class T0, class T1, ... class Tn-1> struct tiny_size< T0, T1, ... Tn-1 ...more... > : mpl::int_<n> {}; BOOST_PP_COMMA_IF generates a comma if its numeric argument is not 0. When n is 0, the list generated by the preceding line will be empty, and a leading comma directly following the < character would be ill-formed. The next line uses BOOST_PP_ENUM to generate TINY_MAX_SIZE-n comma-separated copies of none. BOOST_PP_ENUM is just like BOOST_PP_REPEAT except that it generates commas between repetitions, so its second argument (TINY_print, here) must have the same signature as TINY_size. In this case, TINY_print ignores its repetition index n, and simply yields its third argument, none. BOOST_PP_SUB implements token subtraction. It's crucial to understand that although the preprocessor itself can evaluate ordinary arithmetic expressions: #define X 3 ... #if X - 1 > 0 // OK whatever #endif preprocessor metaprograms can only operate on tokens. Normally, when a macro in the Preprocessor library expects a numeric argument, it must be passed as a single token. If we had written TINY_MAX_SIZE-n instead of BOOST_PP_SUB(TINY_MAX_SIZE,n) above, the first argument to BOOST_PP_ENUM would have contained three tokens at each invocation: first 3-0, then 3-1, and finally 3-2. BOOST_PP_SUB, though, generates single-token results: first 3, then 2, and finally 1, in successive repetitions.
A.4.1.2 Vertical RepetitionIf you send the previous example through your preprocessor, you'll see one long line containing something like this:
template <> struct tiny_size< none , none , none > : mpl::int_<0>
{}; template < class T0> struct tiny_size< T0 , none , none > :
mpl::int_<1> {}; template < class T0 , class T1> struct tiny_size
< T0 , T1 , none > : mpl::int_<2> {};The distinguishing feature of horizontal repetition is that all instances of the repeated pattern are generated on the same line of preprocessed output. For some jobs, like generating the primary tiny_size template, that's perfectly appropriate. In this case, however, there are at least two disadvantages.
The solution to these problems, naturally, is vertical repetition, which generates instances of a pattern across multiple lines. The Preprocessor library provides two means of vertical repetition: local iteration and file iteration. Local IterationThe most expedient way to demonstrate local iteration in our example is to replace the invocation of BOOST_PP_REPEAT with the following: #include <boost/preprocessor/iteration/local.hpp> #define BOOST_PP_LOCAL_MACRO(n) TINY_size(~, n, ~) #define BOOST_PP_LOCAL_LIMITS (0, TINY_MAX_SIZE - 1) #include BOOST_PP_LOCAL_ITERATE() Local iteration repeatedly invokes the user-defined macro with the special name BOOST_PP_LOCAL_MACRO, whose argument will be an iteration index. Since we already had TINY_size lying around, we've just defined BOOST_PP_LOCAL_MACRO to invoke it. The range of iteration indices are given by another user-defined macro, BOOST_PP_LOCAL_LIMITS, which must expand to a parenthesized pair of integer values representing the inclusive range of index values passed to BOOST_PP_LOCAL_MACRO. Note that this is one of the rare places where the library expects a numeric argument that can be an expression consisting of multiple tokens. Finally, the repetition is initiated by #include-ing the result of invoking BOOST_PP_LOCAL_ITERATE, which will ultimately be a file in the Preprocessor library itself. You may find it surprising that many preprocessors can handle repeated file inclusion more quickly than nested horizontal repetition, but that is in fact the case. If we throw the new example at our preprocessor, we'll see the following, on three separate lines in the output:
template <> struct tiny_size< none , none , none > : mpl::int_<0>
{};
template < class T0> struct tiny_size< T0 , none , none > : mpl::
int_<1> {};
template < class T0 , class T1> struct tiny_size< T0 , T1 , none
> : mpl::int_<2> {};
That represents a great improvement in verifiability, but it's still not ideal. As TINY_MAX_SIZE grows, it gets harder and harder to see that the pattern is generating what we'd like. If we could get some more line breaks into the output it would retain a more recognizable form. Both repetition methods we've used so far have another drawback, though it doesn't show up in this example. Consider what would happen if tiny_size had a member function that we wanted to debug. If you've ever tried to use a debugger to step through a function generated by a preprocessor macro, you know that it's a frustrating experience at best: The debugger shows you the line from which the macro was ultimately invoked, which usually looks nothing at all like the code that was generated. Worse, as far as the debugger is concerned, every statement in that generated function occupies that same line. File IterationClearly, debuggability depends on preserving the association between generated code and the lines in the source file that describe the code pattern. File iteration generates pattern instances by repeatedly #include-ing the same source file. The effect of file iteration on debuggability is similar to that of templates: Although separate instances appear to occupy the same source lines in the debugger, we do have the experience of stepping through the function's source code. To apply file iteration in our example, we can replace our earlier local iteration code and the definition of TINY_size, with: #include <boost/preprocessor/iteration/iterate.hpp> #define BOOST_PP_ITERATION_LIMITS (0, TINY_MAX_SIZE - 1) #define BOOST_PP_FILENAME_1 "tiny_size_spec.hpp" #include BOOST_PP_ITERATE() BOOST_PP_ITERATION_LIMITS follows the same pattern as BOOST_PP_LOCAL_LIMITS did, allowing us to specify an inclusive range of iteration indices. BOOST_PP_FILENAME_1 specifies the name of the file to repeatedly #include (we'll show you that file in a moment). The trailing 1 indicates that this is the first nesting level of file iterationshould we need to invoke file iteration again from within tiny_size_spec.hpp, we'd need to use BOOST_PP_FILENAME_2 instead. The contents of tiny_size_spec.hpp should look familiar to you; most of it is the same as TINY_size's replacement-list, without the backslashes:
#define n BOOST_PP_ITERATION()
template <BOOST_PP_ENUM_PARAMS(n, class T)>
struct tiny_size<
BOOST_PP_ENUM_PARAMS(n,T)
BOOST_PP_COMMA_IF(n)
BOOST_PP_ENUM(BOOST_PP_SUB(TINY_MAX_SIZE,n), TINY_print, none)
>
: mpl::int_<n> {};
#undef n
The library transmits the iteration index to us in the result of BOOST_PP_ITERATION(); n is nothing more than a convenient local macro used to reduce syntactic noise. Note that we didn't use #include guards because we need tiny_size_spec.hpp to be processed multiple times. The preprocessed result should now preserve the line structure of the pattern and be more verifiable for larger values of TINY_MAX_SIZE. For instance, when TINY_MAX_SIZE is 8, the following excerpt appears in the output of GCC's preprocessing phase:
...
template < class T0 , class T1 , class T2 , class T3>
struct tiny_size<
T0 , T1 , T2 , T3
,
none , none , none , none
>
: mpl::int_<4> {};
template < class T0 , class T1 , class T2 , class T3 , class T4>
struct tiny_size<
T0 , T1 , T2 , T3 , T4
,
none , none , none
>
: mpl::int_<5> {};
...etc.
Self-IterationCreating an entirely new file like tiny_size_spec.hpp each time we want to express a trivial code pattern for file repetition can be inconvenient. Fortunately, the library provides a macro that allows us to place the pattern right in the file that invokes the iteration. BOOST_PP_IS_ITERATING is defined to a nonzero value whenever we're inside an iteration. We can use that value to select between the part of a file that invokes the iteration and the part that provides the repeated pattern. Here's a complete tiny_size.hpp file that demonstrates self-iteration. Note in particular the placement and use of the #include guard TINY_SIZE_HPP_INCLUDED: #ifndef BOOST_PP_IS_ITERATING # ifndef TINY_SIZE_HPP_INCLUDED # define TINY_SIZE_HPP_INCLUDED # include <boost/preprocessor/repetition.hpp> # include <boost/preprocessor/arithmetic/sub.hpp> # include <boost/preprocessor/punctuation/comma_if.hpp> # include <boost/preprocessor/iteration/iterate.hpp> # ifndef TINY_MAX_SIZE # define TINY_MAX_SIZE 3 // default maximum size is 3 # endif // primary template template <BOOST_PP_ENUM_PARAMS(TINY_MAX_SIZE, class T)> struct tiny_size : mpl::int_<TINY_MAX_SIZE> {}; // generate specializations # define BOOST_PP_ITERATION_LIMITS (0, TINY_MAX_SIZE - 1) # define BOOST_PP_FILENAME_1 "tiny_size.hpp" // this file # include BOOST_PP_ITERATE() # endif // TINY_SIZE_HPP_INCLUDED #else // BOOST_PP_IS_ITERATING # define n BOOST_PP_ITERATION() # define TINY_print(z, n, data) data // specialization pattern template <BOOST_PP_ENUM_PARAMS(n, class T)> struct tiny_size< BOOST_PP_ENUM_PARAMS(n,T) BOOST_PP_COMMA_IF(n) BOOST_PP_ENUM(BOOST_PP_SUB(TINY_MAX_SIZE,n), TINY_print, none) > : mpl::int_<n> {}; # undef TINY_print # undef n #endif // BOOST_PP_IS_ITERATING MoreThere's a good deal more to file iteration than what we've been able to show you here. For more details, we encourage you to delve into the library's electronic documentation of BOOST_PP_ITERATE and friends. Also, it's important to note that no single technique for repetition is superior to any other: Your choice may depend on convenience, verifiability, debuggability, compilation speed, and your own sense of "logical coherence." A.4.2. Arithmetic, Logical, and Comparison OperationsAs we mentioned earlier, many of the Preprocessor library interfaces require single-token numeric arguments, and when those numbers need to be computed arithmetically, straightforward arithmetic expressions are inappropriate. We used BOOST_PP_SUB to subtract two numeric tokens in our tiny_size examples. The library contains a suite of operations for non-negative integral token arithmetic in its arithmetic/ subdirectory, as shown in Table A.1
The logical/ subdirectory contains the convenient Boolean token operations shown in Table A.2 and the more efficient operations shown in Table A.3, which require that their operands are either 0 or 1 (a single bit).
Finally, the comparison/ subdirectory provides the token integral comparison operations shown in Table A.4.
Because it's common to have a choice among several workable comparison operators, it may be useful to know that BOOST_PP_EQUAL and BOOST_PP_NOT_EQUAL are likely to be O(1) while the other comparison operators are generally slower. A.4.3. Control StructuresIn its control/ directory, the Preprocessor library supplies a macro BOOST_PP_IF(c,t,f) that fulfills a similar role to the one filled by mpl::if_. To explore the "control" group, we'll generate code for a framework of generic function objects: the Boost Function library.[8] boost::function is partially specialized to match function type arguments of each arity up to the maximum supported by the library:
template <class Signature> struct function; // primary template
template <class R> // arity = 0
struct function<R()>
definition not shown...
template <class R, class A0> // arity = 1
struct function<R(A0)>
definition not shown...
template <class R, class A0, class A1> // arity = 2
struct function<R(A0,A1)>
definition not shown...
template <class R, class A0, class A1, class A2> // arity = 3
struct function<R(A0,A1,A2)>
definition not shown...
etc.
We've already covered a few strategies that can be used to generate the pattern above, so we won't belabor that part of the problem; the file iteration approach we used for tiny_size would be fine: #ifndef BOOST_PP_IS_ITERATING # ifndef BOOST_FUNCTION_HPP_INCLUDED # define BOOST_FUNCTION_HPP_INCLUDED # include <boost/preprocessor/repetition.hpp> # include <boost/preprocessor/iteration/iterate.hpp> # ifndef FUNCTION_MAX_ARITY # define FUNCTION_MAX_ARITY 15 # endif template <class Signature> struct function; // primary template // generate specializations # define BOOST_PP_ITERATION_LIMITS (0, FUNCTION_MAX_ARITY) # define BOOST_PP_FILENAME_1 "boost/function.hpp" // this file # include BOOST_PP_ITERATE() # endif // BOOST_FUNCTION_HPP_INCLUDED #else // BOOST_PP_IS_ITERATING # define n BOOST_PP_ITERATION() // specialization pattern template <class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class A)> struct function<R ( BOOST_PP_ENUM_PARAMS(n,A) )> definition not shown... # undef n #endif // BOOST_PP_IS_ITERATING BOOST_PP_ENUM_TRAILING_PARAMS, used above, is just like BOOST_PP_ENUM_PARAMS except that when its first argument is not 0, it generates a leading comma. A.4.3.1 Argument SelectionFor the sake of interoperability with C++ standard library algorithms, it might be nice if functions of one or two arguments were derived from appropriate specializations of std::unary_function or std::binary_function, respectively.[9] BOOST_PP_IF is a great tool for dealing with special cases:
# include <boost/preprocessor/control/if.hpp>
# include <boost/preprocessor/comparison/equal.hpp>
// specialization pattern
template <class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class A)>
struct function<R ( BOOST_PP_ENUM_PARAMS(n,A) )>
BOOST_PP_IF(
BOOST_PP_EQUAL(n,2), : std::binary_function<A0, A1, R>
, BOOST_PP_IF(
BOOST_PP_EQUAL(n,1), : std::unary_function<A0, R>
, ...empty argument...
)
)
{ ...class body omitted... };
Well, our first attempt has run into several problems. First off, you're not allowed to pass an empty argument to the preprocessor (see footnote 3, page 285). Secondly, because angle brackets don't get special treatment, the commas in the std::unary_function and std::binary_function specializations above are treated as macro argument separators, and the preprocessor will complain that we've passed the wrong number of arguments to BOOST_PP_IF in two places. Because it captures all of the issues, let's focus on the inner BOOST_PP_IF invocation for a moment. The strategy that mpl::eval_if uses, of selecting a nullary function to invoke, could work nicely here. The preprocessor doesn't have a direct analogue for mpl::eval_if, but it doesn't really need one: We can get the right effect by adding a second set of parentheses to BOOST_PP_IF.
#define BOOST_FUNCTION_unary() : std::unary_function<A0,R>
#define BOOST_FUNCTION_empty() // nothing
...
, BOOST_PP_IF(
BOOST_PP_EQUAL(n,1), BOOST_FUNCTION_unary
, BOOST_FUNCTION_empty
)()
#undef BOOST_FUNCTION_empty
#undef BOOST_FUNCTION_unary
A nullary macro that generates nothing is so commonly needed that the library's "facilities" group provides one: BOOST_PP_EMPTY. To complete the example we'll need to delay evaluation all the way to the outer BOOST_PP_IF invocation, because std::binary_function<A0,A1,R> also has a "comma problem": # include <boost/preprocessor/facilities/empty.hpp> # define BOOST_FUNCTION_binary() : std::binary_function<A0,A1,R> # define BOOST_FUNCTION_unary() : std::unary_function<A0,R> // specialization pattern template <class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class A)> struct function<R ( BOOST_PP_ENUM_PARAMS(n,A) )> BOOST_PP_IF( BOOST_PP_EQUAL(n,2), BOOST_FUNCTION_binary , BOOST_PP_IF( BOOST_PP_EQUAL(n,1), BOOST_FUNCTION_unary , BOOST_PP_EMPTY ) )() { ...class body omitted... }; # undef BOOST_FUNCTION_unary # undef BOOST_FUNCTION_binary # undef n Note that because we happened to be using file iteration, we could have also used #if on n's value directly: template <class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class A)> struct function<R ( BOOST_PP_ENUM_PARAMS(n,A) )> #if n == 2 : std::binary_function<A0, A1, R> #elif n == 1 : std::unary_function<A0, R> #endif BOOST_PP_IF has the advantage of enabling us to encapsulate the logic in a reusable macro, parameterized on n, that is compatible with all repetition constructs:
#define BOOST_FUNCTION_BASE(n) \
BOOST_PP_IF(BOOST_PP_EQUAL(n,2), BOOST_FUNCTION_binary \
, BOOST_PP_IF(BOOST_PP_EQUAL(n,1), BOOST_FUNCTION_unary \
, BOOST_PP_EMPTY \
) \
)()
A.4.3.2 Other Selection ConstructsBOOST_PP_IDENTITY, also in the "facilities" group, is an interesting cousin of BOOST_PP_EMPTY: #define BOOST_PP_IDENTITY(tokens) tokens BOOST_PP_EMPTY You can think of it as creating a nullary macro that returns tokens: When empty parentheses are appended, the trailing BOOST_PP_EMPTY is expanded leaving just tokens behind. If we had wanted inheritance from mpl::empty_base when function's arity is not one or two, we could have used BOOST_PP_IDENTITY:
// specialization pattern
template <class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class A)>
struct function<R ( BOOST_PP_ENUM_PARAMS(n,A) )>
BOOST_PP_IF(
BOOST_PP_EQUAL(n,2), BOOST_FUNCTION_binary
, BOOST_PP_IF(
BOOST_PP_EQUAL(n,1), BOOST_FUNCTION_unary
, BOOST_PP_IDENTITY(: mpl::empty_base)
)
)()
{
...class body omitted...
};
It's also worth knowing about BOOST_PP_EXPR_IF, which generates its second argument or nothing, depending on the Boolean value of its first:
#define BOOST_PP_EXPR_IF(c,tokens) \
BOOST_PP_IF(c,BOOST_PP_IDENTITY(tokens),BOOST_PP_EMPTY)()
So BOOST_PP_EXPR_IF(1,foo) expands to foo, while BOOST_PP_EXPR_IF(0,foo) expands to nothing. A.4.4. Token PastingIt would be nice if there were a generic way to access the return and parameter types of all function objects, rather than just the unary and binary ones. A metafunction returning the signature as an MPL sequence would do the trick. We could just specialize signature for each function arity:
template <class F> struct signature; // primary template
// partial specializations for boost::function
template <class R>
struct signature<function<R()> >
: mpl::vector1<R> {};
template <class R, class A0>
struct signature<function<R(A0)> >
: mpl::vector2<R,A0> {};
template <class R, class A0, class A1>
struct signature<function<R(A0,A1)> >
: mpl::vector3<R,A0,A1> {};
...
To generate these specializations, we might add the following to our pattern:
template <class R, BOOST_PP_ENUM_TRAILING_PARAMS(n, class A)>
struct signature<function<R( BOOST_PP_ENUM_PARAMS(n,A) )> >
: mpl::BOOST_PP_CAT(vector,n)<
R, BOOST_PP_ENUM_TRAILING_PARAMS(n,A)
> {};
BOOST_PP_CAT implements token pasting; its two arguments are "glued" together into a single token. Since this is a general-purpose macro, it sits in cat.hpp at the top level of the library's directory tree. Although the preprocessor has a built-in token-pasting operator, ##, it only works within a macro definition. If we'd used it here, it wouldn't have taken effect at all:
template <class R>
struct signature<function<R()> >
: mpl::vector##1<R> {};
template <class R, class A0>
struct signature<function<R(A0)> >
: mpl::vector##2<R,A0> {};
template <class R, class A0, class A1>
struct signature<function<R(A0,A1)> >
: mpl::vector##3<R,A0,A1> {};
...
Also, ## often yields surprising results by taking effect before its arguments have been expanded: #define N 10 #define VEC(i) vector##i VEC(N) // vectorN By contrast, BOOST_PP_CAT delays concatenation until after its arguments have been fully evaluated: #define N 10 #define VEC(i) BOOST_PP_CAT(vector,i) VEC(N) // vector10 A.4.5. Data TypesThe Preprocessor library also provides data types, which you can think of as being analogous to MPL type sequences. Preprocessor data types store macro arguments instead of C++ types. A.4.5.1 SequencesA sequence (or seq for short) is any string of nonempty parenthesized macro arguments. For instance, here's a three-element sequence: #define MY_SEQ (f(12))(a + 1)(foo) Here's how we might use a sequence to generate specializations of the is_integral template from the Boost Type Traits library (see Chapter 2):
# include <boost/preprocessor/seq.hpp>
template <class T>
struct is_integral : mpl::false_ {};
// a seq of integral types with unsigned counterparts
#define BOOST_TT_basic_ints (char)(short)(int)(long)
// generate a seq containing "signed t" and "unsigned t"
#define BOOST_TT_int_pair(r,data,t) (signed t)(unsigned t)
// a seq of all the integral types
#define BOOST_TT_ints \
(bool)(char) \
BOOST_PP_SEQ_FOR_EACH(BOOST_TT_int_pair, ~, BOOST_TT_basic_ints)
// generate an is_integral specialization for type t
#define BOOST_TT_is_integral_spec(r,data,t) \
template <> \
struct is_integral<t> : mpl::true_ {};
BOOST_PP_SEQ_FOR_EACH(BOOST_TT_is_integral_spec, ~, BOOST_TT_ints)
#undef BOOST_TT_is_integral_spec
#undef BOOST_TT_ints
#undef BOOST_TT_int_pair
#undef BOOST_TT_basic_ints
BOOST_PP_SEQ_FOR_EACH is a higher-order macro, similar to BOOST_PP_REPEAT, that invokes its first argument on each element of its third argument. Sequences are the most efficient, most flexible, and easiest-to-use of the library's data structures, provided that you never need to make an empty one: An empty sequence would contain no tokens, and so couldn't be passed as a macro argument. The other data structures covered here all have an empty representation. The facilities for manipulating sequences are all in the library's seq/ subdirectory. They are summarized in Table A.5 where t is the sequence (t0)(t1)...(tk). Where s, r, and d appear they have a similar purpose to the z parameters we discussed earlier (and suggested you ignore for now).
It's worth noting that while there is no upper limit on the length of a sequence, operations such as BOOST_PP_SEQ_ELEM that take numeric arguments will only work with values up to 256. A.4.5.2 TuplesA tuple is a very simple data structure for which the library provides random access and a few other basic operations. A tuple takes the form of a parenthesized, comma-separated list of macro arguments. For example, this is a three-element tuple: #define TUPLE3 (f(12), a + 1, foo) The operations in the library's tuple/ subdirectory can handle tuples of up to 25 elements. For example, a tuple's Nth element can be accessed via BOOST_PP_TUPLE_ELEM, as follows:
// length index tuple
BOOST_PP_TUPLE_ELEM( 3 , 1 , TUPLE3) // a + 1
Notice we had to pass the tuple's length as the second argument to BOOST_PP_TUPLE_ELEM; in fact, all tuple operations require explicit specification of the tuple's length. We're not going to summarize the other four operations in the "tuple" group hereyou can consult the Preprocessor library's electronic documentation for more details. We note, however, that sequences can be transformed into tuples with BOOST_PP_SEQ_TO_TUPLE, and nonempty tuples can be transformed back into sequences with BOOST_PP_TUPLE_TO_SEQ. The greatest strength of tuples is that they conveniently take the same representation as a macro argument list:
#define FIRST_OF_THREE(a1,a2,a3) a1
#define SECOND_OF_THREE(a1,a2,a3) a2
#define THIRD_OF_THREE(a1,a2,a3) a3
// uses tuple as an argument list
# define SELECT(selector, tuple) selector tuple
SELECT(THIRD_OF_THREE, TUPLE3) // foo
A.4.5.3 ArraysAn array is just a tuple containing a non-negative integer and a tuple of that length: #define ARRAY3 ( 3, TUPLE3 ) Because an array carries its length around with it, the library's interface for operating on arrays is much more convenient than the one used for tuples: BOOST_PP_ARRAY_ELEM(1, ARRAY3) // a + 1 The facilities for manipulating arrays of up to 25 elements are all in the library's array/ subdirectory. They are summarized in Table A.6, where a is the array (k, (a0,a1, ...ak-1)).
A.4.5.4 ListsA list is a two-element tuple whose first element is the first element of the list, and whose second element is a list of the remaining elements, or BOOST_PP_NIL if there are no remaining elements. Lists have access characteristics similar to those of a runtime linked list. Here is a three-element list: #define LIST3 (f(12), (a + 1, (foo, BOOST_PP_NIL))) The facilities for manipulating lists are all in the library's list/ subdirectory. Because the operations are a subset of those provided for sequences, we're not going to summarize them hereit should be easy to understand the list operations by reading the documentation on the basis of our coverage of sequences. Like sequences, lists have no fixed upper length bound. Unlike sequences, lists can also be empty. It's rare to need more than 25 elements in a preprocessor data structure, and lists tend to be slower to manipulate and harder to read than any of the other structures, so they should normally be used only as a last resort. |
|
|