Re: [boost] Re: [preprocessor] vertical and horisontal repititions

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-11-07 22:31:48

----- Original Message -----
From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>

> > > Could somebody explain the difference and when which one should be
used.
> > >
> > > Also is there PP desing paper that explain how it is
> working/implemented?
> >
> > Vertical repetition is primarily for large scale repetition--such as
> > repetition or whole functions or class definitions.  Horizontal
repetition
> > is better (IMO) for small things like "class T0, class T1, class T2"
> (etc.).
>
> You don't really answer the quesion. Why should I bother how postprocessed
> code look like? Vertical or horizontal - in majority of the cases I don't
> look on the code produced and for compiler it should be indifferent.

Because postprocessed code is what gets debugged and vertical repetition is
significantly faster for large amounts of code.  I can't completely answer
your question because 1) I can't assume how much you know about the subject,
and 2) it depends a great deal on personal preference.

For example, if I was to generate this with the preprocessor:

template<template<class> class T0, template<class, class> class T1, ...> //
(etc.)

...I would generate all of it horizontally.  However, others prefer it to be
vertical.  Where this primarily comes into play is debuggability.  If a
hundred class definitions come from a single macro expansion, it will be a
real pain to debug anything that goes wrong--both with the preprocessor
code, any template metaprogramming code, or the regular runtime code.
Vertical repetition pulls things apart so it is easier to debug.  It has the
side effect of speed and greater range (on some preprocessors) as well.

> Gennadiy.
>
> P.S. One more remark: it seems like notion of state is used differently in
> different places of the documentation. In one place (BOOST_PP_WHILE or
FOR)
> state means what I expect it to mean state of the loop, while in others it
> used as "State Parameters" used to provide the means to reenter the
> respective construct

Yes.  In the "state of the loop," as you put it, it refers to any state the
user passes into the looping mechanism.  That state is modified by the user
in the "body" of the loop.  That is really the state of the looping process
as a whole, i.e. what you are accomplishing by looping.  The "state
parameters" are the actual physical state of the a construct itself, not of
the loop.  Because of the limitations of the preprocessor this is necessary
(although minimized with automatic-recursion).  The loop constructs don't
actually loop, nor do they recurse or iterate in any normal sense.  Rather,
they are just a series of nested macro calls that simulate a loop.

As far as the terminology is concerned, it's difficult because I have to
make it up as I go along.  Analogies to "normal" language idioms such as
"iteration" or "recursion" aren't really accurate.  I'm in no-man's-land
here, and in both cases above "state" actually *is* a state--just the state
of two different things. :(

> P.P.S. From what I view constructs that are used for looping are not
> substitutable, like one would expect from C++ expirience.

There is really only one looping construct:  BOOST_PP_WHILE.  BOOST_PP_FOR
is not a looping construct; it is a generalized repetition construct.  I
don't particular like the name FOR for this either, but it is a little late
to change now. :)

> Instead each has
> specific pattern of usage and area of application. BTW it would be great
to
> specifically show in which case which construct should be used in docs.

The only real ambiguity is what kind of repetition construct to use--not
looping.  That depends a great deal on what you want to do specifically.  I
tried to write about choosing a repetition construct before, but others
disagree on various "guidelines."  I plan on getting back to it sometime,
but tend things add up into huge discourses on preprocessor generative
programming and how to do it in general.  If such text was littered all over
the documentation, it would massively sharpen the already significant
learning curve, because most people that use it don't really care *how* it
works, just that it achieves the result that they want.

If you're interested in a far more detailed explanation, I'd be happy to
discuss it with you.

Paul Mensonides