Statement unrolling with P99_FOR

Specifying code that does same or equivalent things to a list of variables, tokens, items or so is an important source of annoyance. It can easily make code unreadable and difficult to maintain. E.g consider the following

 
if ((b == a) && (c == a) && (d == a) && (e == a) && (f == a)) {
  /* all are equal, do something special */
} else {
  /* handle the base case */
}

Understanding what that expression does is difficult in one glance and updating it is error prone. Adding another variable, say g, to be tested may be simple but withdrawing a is a major operation.

With code unrolling as P99 provides it we may implement a macro P99_ALLEQ

 
if (P99_ALLEQ(a, b, c, d, e, f)) {
  /* all are equal, do something special */
} else {
  /* handle the base case */
}

Here, adding another variable to the list or deleting any of them is not a big deal.

In fact, the implementation of such a macro with P99 is as simple as this:

 
#define P00_ISIT(WHAT, X, I) (X) WHAT
#define P99_ALLEQ(FIRST, ...) P99_FOR(== (FIRST), P99_NARG(__VA_ARGS__), P00_AND, P00_ISIT, __VA_ARGS__)

This uses P99_FOR to do a macro iteration. That iterative evaluation will produce code for each element that is passed in the __VA_ARGS__ list, `b, c, d, e, f‘ in our example.

Each of these elements is given to the P00_ISIT macro as a second argument, the first being the first argument to P99_FOR. Here that first argument is == (FIRST), in our example this leads to `== (a)‘. So when processing the b in the list that leads to `(b) == (a)‘, for c that is `(c) == (a)‘ and so on.

The other macro that is in the arguments of P99_FOR is P00_AND. As you expect this is what is responsible for the && operators between these individual expansions for each list item. In fact it does a bit more than given above in that it adds a lot more parenthesis. The real expansion done by the preprocessor is

 
if ((((((((((b) == (a)) && ((c) == (a)))) && ((d) == (a)))) && ((e) == (a)))) && ((f) == (a)))) {
  /* all are equal, do something special */
} else {
  /* handle the base case */
}

After we withdraw a from the list of arguments the new macro expansion would read

 
if ((((((((c) == (b)) && ((d) == (b)))) && ((e) == (b)))) && ((f) == (b)))) {
  /* all are equal, do something special */
} else {
  /* handle the base case */
}

In the same way as P99_ALLEQ we may define a whole bunch of other macros that work in the same spirit.

 
#define P99_MINOF(FIRST, ...) P99_FOR(>= (FIRST), P99_NARG(__VA_ARGS__), P00_AND, P00_ISIT, __VA_ARGS__)
#define P99_INFOF(FIRST, ...) P99_FOR(> (FIRST), P99_NARG(__VA_ARGS__), P00_AND, P00_ISIT, __VA_ARGS__)
#define P99_MAXOF(FIRST, ...) P99_FOR(<= (FIRST), P99_NARG(__VA_ARGS__), P00_AND, P00_ISIT, __VA_ARGS__)
#define P99_SUPOF(FIRST, ...) P99_FOR(< (FIRST), P99_NARG(__VA_ARGS__), P00_AND, P00_ISIT, __VA_ARGS__)
#define P99_ONEOF(FIRST, ...) P99_FOR(== (FIRST), P99_NARG(__VA_ARGS__), P00_OR, P00_ISIT, __VA_ARGS__)

Here the first use the same macro P00_AND as before, only P99_ONEOF, the last, uses P00_OR to combine the different parts.

P99_FOR can also be used to build expressions that are a more complicated.

P99_ORDERED(<=, a, b, c, d) 

should expand to

((a) <= (b)) && ((b) <= (c)) && ((c) <= (d))

Here you see that in the expanded expression b and c each appear two times. So a simple generalization of the tricks above would not work. We have to go in steps to generate that. First, we define a macro that expands to the inner part of the expression:

(b)) && ((b) <= (c)) && ((c)

You might already see the pattern. We have parts per list item that look similar to `(b)) && ((b)‘ and the separation is done with the operator `<=‘. This is done by these two macros:

#define P00_ORDERED_AND(_0, X, _2) (X)) && ((X)
#define P00_ORDERED_OP(OP, _1, X, Y) X OP Y

Observe the unbalanced parentheses in P00_ORDERED_AND. These two are combined in

#define P00_ORDERED_MID(OP, N, ...)                                        \
P99_FOR(OP, N, P00_ORDERED_OP, P00_ORDERED_AND, P99_SUB(1, N, __VA_ARGS__))

it supposes that it obtains the desired length N as second argument. It also uses another generic P99 macro, P99_SUB, to compute the sublist of the arguments that starts at position 1 and has length N. E.g P00_ORDERED_MID(<=, 2, r, s, t) will expand to

(s)) && ((s) <= (t)) && ((t)

Now this is not yet a valid C expression, only the middle part of what we want, but the following cascade of four defines does the trick.

#define P99_ORDERED(OP, ...) P00_ORDERED(OP, P99_NARG(__VA_ARGS__), __VA_ARGS__)
#define P00_ORDERED(OP, N, ...)                 \
P99_IF_LT(N, 3)                                 \
(P00_ORDERED2(OP,__VA_ARGS__))                  \
(P00_ORDERED3(OP, P99_PRED(N), __VA_ARGS__))
#define P00_ORDERED2(OP, X, Y) (X) OP (Y)
#define P00_ORDERED3(OP, N, ...)                        \
((P99_SUB(0, 1, __VA_ARGS__))                           \
 OP P00_ORDERED_MID(OP, P99_PRED(N), __VA_ARGS__)       \
 OP (P99_SUB(N, 1, __VA_ARGS__)))

First P99_IF_LT is used to find if the number of arguments is less than 3. In the case it is less a special case P00_ORDERED_2 is chosen, namely the one that need no middle part. If there are more arguments macro P00_ORDERED3 prefixes the middle part with the first element of the list and the operator, and appends the analog for the last element. The result of

P99_ORDERED(<=, a, b, c, d)
P99_ORDERED(>, 4, 5)

are what we’d expect:

((a) <= (b)) && ((b) <= (c)) && ((c) <= (d))
(4) > (5)

About these ads