Re: [boost] File-Iteration Synopsis

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-06-20 18:22:28

> And how does "ITERATE" describe that any better than "REPEAT"?

It doesn't.  However, I like "ITERATE" better than "REPEAT" for several reasons:

1) I don't like the name being so close to something that is similar in
*concept* is totally different in interface.

2) When I see code like this:

    for (int i = 0; i < 10; ++i) {
        // ...
    }

    I think of it as 'iteration' (as opposed to recursion), but I never think of
it as 'repetition'.

3) Repetition does not imply an execution path, while iteration does, and that
is exactly what is happening here.  State (i.e. auxiliary parameters--i.e.
macros--defined by the user) can be modified or reassigned on each pass.
Repetition does not imply that possibility.  In fact, there is no way for the
BOOST_PP_REPEAT macro to do such a thing directly--you would have to use
BOOST_PP_FOR instead.

4) I see iteration as the logical alternative to recursion, and while the macro
parts of the library do not truly use recursion, they simulate it--even to the
degree of causing a huge *stack* of data.  This is the *primary* reason that the
EDG front-ends are so slow.  With the iteration mechanism, it is nearly
immaterial what your upper and lower boundaries are (of course, I may matter
with what you do with values inside, however).

> > This typically requires a manipulation of the
> > source order that makes it look more like the preprocessor is executing a
> small
> > program than preprocessing text.  Also, it isn't strictly necessary to
> generate
> > *text* with the mechanism.  I suppose you could make some other kind of
> > calculation.
>
> Not sure what you're getting at above.

Using complex file-iteration, the preprocessor translation of a file is a lot
like the execution path of a function.  There are if statements, branches, and
even looping (via the iteration mechanism).  This causes your file to longer be
just a straightforward top-down file, but rather a (possibly complex) *execution
path* that the preprocessor is taking through your file at different times and
in different ways.

> > Tip: for lists of small things, such as those
> arg_tuple_size_helper-things from
> > a while back, it is a preferrable to the use the simpler local iteration
> system.
> > Don' underestimate the usefulness of that facility even though it doesn't
> have
> > all the full-blown capabilities of the full-blown file-iteration.
>
> I would always use the mechanism with the simpler interface unless there
> was a good reason not to.

Any time that you have complex structures at all it would be better to use the
more complex mechanism.  Is has massive debugging advantages.  In the case of
'expansions' that are one or two lines and are fairly straight forward, it is
easier to use the more primitive, and less debugging friendly, mechanism.

Paul Mensonides