This is the mail archive of the
mailing list for the GCC project.
Re: [libstd++] current tuple ebco patch
- From: Paolo Carlini <pcarlini at suse dot de>
- To: Chris Fairles <chris dot fairles at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 09 Dec 2007 19:43:55 +0100
- Subject: Re: [libstd++] current tuple ebco patch
- References: <firstname.lastname@example.org>
> 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