|
Boost : |
From: Tarjei Knapstad (tarjeik_at_[hidden])
Date: 2003-11-25 09:40:37
On Sat, 2003-11-22 at 06:23, Joel de Guzman wrote:
> David Abrahams <dave_at_[hidden]> wrote:
> > David Abrahams <dave_at_[hidden]> writes:
>
> >> I had hoped we'd get the new tuples into CVS by then as well.
> >
> > I'm still wondering about that part. Are we intentionally putting off
> > replacing the old, relatively inefficient, somewhat non-portable
> > tuples with Joel's revision (I wonder if you can detect my bias here
> > ;->), or is that just not happening through inertia?
>
> The TR tuples part (minus the algorithms) of Fusion is ready for prime
> time. I can add the deprecated names for backward compatibility if
> needed. There were some name changes in the TR. WRT time and inertia,
> I am relatively ok now. The Spirit 1.8.0 code base has been stable for quite
> some time now. I'm just doing some arranging here and there (tests and
> samples) plus documentation. Of course, I await for Jaakko, Gary and
> Doug's approval.
>
I just briefly browsed the code, and AFAICS this implementation limits
the number of elements in a tuple to 15 (correct me if I'm wrong
though). I previously made a post to the boost-users list about the
current limit of 10 elements, to which Jaakko responded that this limit
would be raised quite a lot in a future implementation
(http://tinyurl.com/wh15).
Is support for large numbers of elements a goal that has been dropped?
(to allow for a more efficient implementation?) I'm currently using some
wrapping macros/classes to easily use tuples of tuples (allowing tuples
of up to 100 elements), but to be honest it would be nice to get rid of
this.
In any case, is there some short writeup somewhere about the significant
differences between the current tuple implementation and the one in
Spirit? I assume the compile time constants used in the Spirit tuple
implementation to limit the maximum number of elements are there for
efficiency reasons. Are there any other major changes?
Thanks,
-- Tarjei
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk