Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-06-19 21:08:30


> Yes, it helps!
> Still, I'm confused about the way you use the term "abstract".
>
> I'm glad it's fast; when can I use it!?

It is possible that something that uses the mechanism does know what depth it is
being used at. If you remember the 'returning_void' and 'returning_non_void'
examples that I sent you a while back, those files use multiple levels of
iteration, but the syntax for setting the next lower and upper bounds is exactly
the same for any supported level. The only thing that I cannot abstract in that
fashion is the filename because I have no mechanism to *evaluate* it. You have
no idea how much that irks me! So, if a file is going to be used in an abstract
place in a chain of iterations, it must do this for the filename:

#if BOOST_PP_DEPTH() == 0
    #define BOOST_PP_FILENAME_1 "filename.h"
#elif BOOST_PP_DEPTH() == 1
    #define BOOST_PP_FILENAME_2 "filename.h"
#elif BOOST_PP_DEPTH() == 2
    #define BOOST_PP_FILENAME_3 "filename.h"
#elif BOOST_PP_DEPTH() == 3
    #define BOOST_PP_FILENAME_4 "filename.h"
#else
    #define BOOST_PP_FILENAME_5 "filename.h"
#endif

The user is saved from this same type of thing by the BOUND/SET_BOUND mechanism
for the numeric values that I *can* evaluate without lazy-evaluation.

#define BOOST_PP_BOUND 15
#include BOOST_PP_SET_UBOUND()

is roughly equivalent to...

#if BOOST_PP_DEPTH() == 0
    #define BOOST_PP_UBOUND_1 15
#elif BOOST_PP_DEPTH() == 1
    #define BOOST_PP_UBOUND_2 15
#elif BOOST_PP_DEPTH() == 2
    #define BOOST_PP_UBOUND_3 15
#elif BOOST_PP_DEPTH() == 3
    #define BOOST_PP_UBOUND_4 15
#else
    #define BOOST_PP_UBOUND_5 15
#endif

That is what I mean by abstraction of the depth of the iteration. Let me change
some names, and I will post it immediately. However, please note that these
files are initial, and some things may change in incompatible ways in the near
future (i.e. next two weeks), but I'll try to avoid that.

Paul Mensonides


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk