Date: 2001-10-23 11:28:05
--- In boost_at_y..., jaakko.jarvi_at_c... wrote:
> --- In boost_at_y..., williamkempf_at_h... wrote:
> > tuple<> t = make_tuple(1,2,3,4,5,6,7,8,9,10) + make_tuple(11);
> > Obviously there's some issues with the above example and some
> > decisions that would need to be hashed out here, but the concept
> > seems sound.
> The fixed limit of tuple size has bugged me as well, not that I
> have needed tuples larger than 10 elements, but still.
> The current tuples can be seen as a layer above the cons lists,
> providing a nicer syntax. The price for this is the size constrain.
> The tuple template has all the element types as distinct template
> arguments, so obviously an additional parameter for holding the
> remaining arguments is needed.
That's why I stated that the example code wasn't technically
accurate. The syntax is nice but will require some radical changes
to the current implementation. However, it can allow for some really
nice syntactic uses:
tuple<> t = foo(); // we don't have to specify the full type
t += bar(); // we extend t with the returns from bar
// this requires discarded temporaries, but is still nice
You get the general idea.
Remember, though, I'm brain storming. I've not thought about the
issues involved with implementation, nor fully thought out the
> I agree, the idea is sound. Most of the functions, operators and
> metafunctions operate on cons lists, rather than tuples, so
> I think something along the lines of your suggestion can be
> made to work.
> > One of the big things I see not being addressed by this
> > idea (though maybe the idea could be extended to handle it) is
> > handling of tiers.
> I can't come up with an immediate solution to this.
Again, just brain storming, but extend the same idea that was
employed for tuples.
tier<> t3 = t1.append(t2);
t3 = foo(); // ties all 11 returned arguments
The above is ugly code but the interface could be worked out to make
it nicer. Further, only the masochists that need to go beyond a
reasonable number of items would have to deal with the syntax, and
that seems a fair trade off.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk