Re: [boost] Re: Release schedule for 1.31.0

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-11-25 10:24:28

Tarjei Knapstad <tarjeik_at_[hidden]> wrote:
> 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

Nope. The limit is much higher than that: 50. And that's the limit of MPL's 
vector. Care for a 100 tuple element? That's doable thanks to the boost
preprocessor. If MPL can do it, so can Fusion.

<< I think you looked at the phoenix tuple implementation. Try the
sandbox >>

> 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?

The one used by Fusion is not the same as the one phoenix/spirit uses.
It is based on the TR1 tuple specification:
 http://www.osl.iu.edu/~jajarvi/publications/papers/tuple_proposal.pdf

Cheers,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net