BOOST_MPL_LIMIT_SET_SIZE
I just run into the basic limitation of 20. This has direct consequences on one of our products. Currently the highest number I've seen is 31, but our customers are likely to create higher numbers. (We generate C++ code in one of our products). It would be ok to limit it to 50 -- which is what boost provides. But what would it take to increase this limit? The matching files in boost/mpl are kind of unreadable for the uninitiated. Or is there a given limit for any compiler? Anybody any clue? Thanks Peter "The first point (using an init() function in preference to a constructor) is bogus. Using constructors and exception handling is a more general and systematic way of dealing with resource acquisition and initialization errors. This style is a relic of pre-exception C++." -- Stroustrup
AMDG peter_foelsche@agilent.com wrote:
I just run into the basic limitation of 20.
This has direct consequences on one of our products.
Currently the highest number I've seen is 31, but our customers are likely to create higher numbers.
(We generate C++ code in one of our products).
It would be ok to limit it to 50 -- which is what boost provides.
But what would it take to increase this limit?
The matching files in boost/mpl are kind of unreadable for the uninitiated.
Or is there a given limit for any compiler?
Anybody any clue?
For set, the limit of 20 should only affect the unnumbered form set<int_<1>, int_<2>, ..., int_<20> >. If you use the numbered form and include the correct headers you can go up to 50. However, this limitation only applies to the interface for creating sets. You can always insert more elements in a set, so ignoring compiler limits, something like the following should always work. typedef set0<> s0; typedef insert<s0, x0>::type s1; typedef insert<s1, x1>::type s2; ... typedef insert<sn-1, xn-1>::type sn; In Christ, Steven Watanabe
participants (2)
-
peter_foelsche＠agilent.com -
Steven Watanabe