Hi! Maybe I overlooked this portion of the docs, so could you please give me a hint, whether and how one can set the maximum number of tuple elements. regards, Markus
Markus Werle wrote:
Hi!
Maybe I overlooked this portion of the docs, so could you please give me a hint, whether and how one can set the maximum number of tuple elements.
Ah... what the TR says is "The maximum number of elements in one tuple type (clause 6.1) is implementation defined. This limit should be at least 10." So you can't change it, or portably store more than 10 elements. Of course if you just happen to be using the Boost implementation then all the Boost.Fusion macros and extensions kick in, but you can't guarentee that: to take one example VC9+sp1 supplies it's own TR1 tuple so that's what Boost.TR1 pulls in (out of necessity). HTH, John.
John Maddock
Markus Werle wrote:
Hi!
Maybe I overlooked this portion of the docs, so could you please give me a hint, whether and how one can set the maximum number of tuple elements.
Ah... what the TR says is "The maximum number of elements in one tuple type (clause 6.1) is implementation defined. This limit should be at least 10."
Then it would be very nice if the standard defined a MACRO allowing me to determine the maximum number of tuple elements. Otherwise this renders tr1::tuple completely useless for any template code.
So you can't change it, or portably store more than 10 elements. Of course if you just happen to be using the Boost implementation then all the Boost.Fusion macros and extensions kick in, but you can't guarentee that: to take one example VC9+sp1 supplies it's own TR1 tuple so that's what Boost.TR1 pulls in (out of necessity).
Yes. I was aiming at getting std::portable ... These "implementation defined" clauses suck (not only IMHO). It is like those "maximum nesting level of 18 in templates" that hinders portability for RealWorld apps. Thinking about variadic template arguments while releasing a TR that clings to fixed numbers seems odd to me ... regards, Markus
Markus Werle wrote:
Then it would be very nice if the standard defined a MACRO allowing me to determine the maximum number of tuple elements. Otherwise this renders tr1::tuple completely useless for any template code.
Really? I've never actually needed more than about 3 elements myself. In any case the next std will have variadic template support which will allow for an infinite (ish) number of arguments to std::tuple.
So you can't change it, or portably store more than 10 elements. Of course if you just happen to be using the Boost implementation then all the Boost.Fusion macros and extensions kick in, but you can't guarentee that: to take one example VC9+sp1 supplies it's own TR1 tuple so that's what Boost.TR1 pulls in (out of necessity).
Yes. I was aiming at getting std::portable ... These "implementation defined" clauses suck (not only IMHO). It is like those "maximum nesting level of 18 in templates" that hinders portability for RealWorld apps.
Thinking about variadic template arguments while releasing a TR that clings to fixed numbers seems odd to me ...
The TR is aimed at *existing* compilers, it introduces no language changes, the next std will have a tuple with variadic argument support. HTH, John.
participants (2)
-
John Maddock -
Markus Werle