[libstd++] current tuple ebco patch

[Chris Fairles]

On Dec 9, 2007 1:43 PM, Paolo Carlini <pcarlini@suse.de> wrote:
> Hi Chris,
> > My assignment should be processed any day now so I might as well get a few
> > patches looked at and fixed up.
> >
> > This one has modifications to tuple so that ebco is used where possible. It
> > also has an impl. of tuple_cat as well (i have an operator+ for tuple in
> > there as well, but just ignore it, its not std). This all works with
> > -std=c++0x but I haven't run the test suite with tr1's tuple (I'm sure it
> > will break something). I suppose I also need a test suite for c++0x tuple.
> >
> first, please remember to always post your libstdc++ patches to the
> libstdc++ mailing list too...
>
> Also, please keep us up to date about your assignment: normally the
> maintainers are *not* automatically kept up to date by FSF and we risk
> wasting a lot of time because of that.
>
> Anyway, the first important point about your work, is that we should
> make sure breakages of the TR1 version of these facilities cannot
> happen.That may mean splitting (almost ) completely the TR1 and the
> C++0x (in namespace std::) implementations, similarly to the type_traits
> code for example, that is, not just adding to namespace std additional
> free functions and similar stuff. In particular, not changing base
> classes in the TR1 implementation, for example. All in all, in the
> specific case of tuple I would suggest a complete split. Can you try
> that, while we are waiting for the assignment? And yes, testcases
> exercising the C++0x specific user visible (and not) features would be
> really appreciated...
>
> Paolo.
>

Ok, I can't recall how the tr1<->std namespace selection works.

With type_traits, tr1_impl/type_traits has the common elements,
std/type_traits has the c++0x additions only, tr1/type_traits
implements tr1-only (less the common stuff) and the
tr1_impl/type_traits's namespace is selected based on the -std flag?

Can the code in tr1 use variadic templates? If not, does that mean we
need a tuple impl w/o var-templates?

Chris