From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-04-14 08:42:48
"David Abrahams" <dave_at_[hidden]> wrote
> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:
> >> parse the actual typeof expression. Unfortunately it completely blows
> >> the parser (probably an internal limit is exceeded) and doesn't leave
> >> with much error reporting.
> >> Is there a configuration option to scale down the size of the
> >> used for the encoding ?
> > BOOST_TYPEOF_LIMIT_SIZE
> > By default it's 50 -- try to set it to 15 -- should be enough to compile
> > main.cpp (but not test_compliant.cpp).
> I don't understand all the issues, but I get the impression that
> BOOST_TYPEOF_LIMIT_SIZE isn't a good analogue for
> BOOST_MPL_LIMIT_XXX_SIZE because most of the time you're not supposed
> to change the latter. Should we be changing one of these names, or
> maybe do something to clearly advertise any differences?
Well, it's not exactly an analogue. Typeof uses only numbered (or what is
the correct name for it?) versions of the mpl::vector. Setting
BOOST_TYPEOF_LIMIT_SIZE to, e.g., 15 means that vector15 is used to store
the encoded type, and numbered versions up to vector15 are used to build it,
regardless what the value of BOOST_MPL_LIMIT_VECTOR_SIZE is. If typeof
limit happens to exceed the mpl limit, additional numbered MPL vector
definitions are built with PP lib, as suggested by Aleksey some time ago.
To add a little to the confusion, by default I don't use mpl::vector.
Instead I use my own very simple MPL-compatible vector definition, which
allows me to avoid the gcc-mpl::vector performance problem discussed some
time ago. To really use MPL, BOOST_TYPEOF_USE_MPL_VECTOR has to be defined.
This may be reconsidered after the MPL problem is fixed.
Most of the time you wouldn't have to change BOOST_TYPEOF_LIMIT_SIZE either.
I would use BOOST_MPL_LIMIT_VECTOR_SIZE as a convenient default, but I think
it's currently 10 (?) and too low for typeof...
Do you have a better name in mind or is it enough to just put the above
description somewhere in the document?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk