----- Original Message -----
From: "Jaakko Jarvi" <[EMAIL PROTECTED]>
> > Aleksey Gurtovoy wrote:
> > > David A. Greene wrote:
> > >
> > >>The fundamental problem is that it's inconvenient to iterate through a
> > >>tuple.
> > >
> > >
> > > 'tuple_ext' ("tuple extensions") make it easier -
> > > http://groups.yahoo.com/group/Boost-Users/message/704.
> >
> > Has any discussion taken place about incorporating something like
> > this into Boost? Seems like a useful bit of code.
> >
> There has been some out-of-list discussion about this, and some work is
> being done. There's a PP based tuple implementation (mostly written by
> Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR.
> (Note that the current Boost.Tuples is not one-to-one what was accepted
> into the TR. Most notably, the cons-list interface was not standardized.)
>
> The PP based tuples are not complete yet, and what the iteration interface
> will be is still undecided.
Yup, I've been itching to reply to the thread but opted to wait for Jaakko.
There's already a TR conformant tuple implementation in Spirit's CVS
in the PHOENIX_X branch. It is PP and MPL based. Compiles on all
relevant compilers. There is only one implementation, unlike boost tuples
which has a different implementation for MSVC which can easily get
out of sync (it is out of sync now in fact. e.g. the MSVC branch does
not convert a make_tuple(ref(x)) to tuple<X&>. And interestingly, some
code that does not compile on some compilers now compile with this
implementation. All of Jaakko's regression tests (except the cons related
stuff) plus some more new ones compile and run.
With the help of Jaakko, Aleksey et. al, I wish to implement a set of
tuple algorithms similar to STLs. The tricky part is that it should
work at compile time, run-time and half-run-compile time.
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
