This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: c++0x vs. tr1 type_traits, round 1
Benjamin Kosnik wrote:
I'd like to help much more, but I'm in the middle of the
__is_convertible_to work + yesterday finally committed the last
tweaks to __has_nothrow_assign and right now I'm finally changing
tr1/type_traits to exploit it and the other already available
front-end traits...
Cool.
So, the testing issue is biting you too. What to do? Are you testing
both versions of the traits? I think this is probably the better way
to go, but more work.
At the moment, the implementation is fully conforming to tr1 + better
QOI than the minimal one for the type properties thanks to the front-end
support. Of course that means that some bits would not pass C++0x
testing, like is_base_of.
Anyway, I think we are on the same page, generally: those changes are
not minor and we have to figure out a strategy scaling well also to
cases of vastly different facilities (like random, even if, as
discussed privately, we can use the same underlying algorithms in both
cases, but that is another matter). About the details, at the moment I
lack a sufficiently accurate picture, I'd like to hear Doug again,
while I find the time to deepen my own understanding...
Hmm. OK.
Since we're both working on this, how should we stage this work?
Should I check what I have in, and then proceed immediately to the
testsuite revamp? Once that is done I can add testcases for the new
traits. I would like to work on parallel stuff if possible.
If you can wait until late today, I have ready the changes to use
front-end support, the last days was waiting for Mark to approve a few
front-end bits...
More generally, given that many names + semantics are going to be
different, I'd rather see an approach using separate files for C++0x and
TR1. Thus renounce to importing tr1/type_traits in the C++0x
implementation and not ifdefing stuff in and out, it's too much already,
and much more will be...
Paolo.