c++0x vs. tr1 type_traits, round 1
Benjamin Kosnik
bkoz@redhat.com
Thu Apr 26 11:26:00 GMT 2007
> Actually, definitely better clearing the situation about TR1 vs C++0x
> first, *before* I change the traits to use front-end support in more
> places.... The reason is that unfortunately I'm just noticing that the
> semantics is subtly incompatible in more places than I thought: for
> example in tr1 all the has_trivial_* are by and large unspecified *but*
> must return the same value after remove_extent; also all the
> has_trivial_* >= is_pod and that is also incompatible with C++0x, where,
> if the type is const or reference, the value of has_trivial_assign is
> false anyway, irrespective of PODness. A mess, in short.
Yeah.
> I think the only sane approach to this problem is keeping the
> implementations completely separate, use in the tr1 implementation the
> front-end support minimally, renounce to some QoI. Like it is now,
> basically. Therefore add a new file for C++0x, where I can use the
> front-end support anywhere it helps.
Yes.
FYI the "new file for C++0x" already exists.... see include/std/type_traits.
This is what I added decay, enable_if, etc to.
That part of my patch seems correct. The _GLIBCXX_SUPPRESS_TR1 bits seem
not to be.
I believe it is actively a danger to include both tr1/type_traits and
c++0x's type_traits. It should not be too much work to show ambiguity
between function template calls that include explicitly qualified tr1
arguments.
How do we prevent that if they are separate files? I suppose we could
just do a macros check for the TR1 macro guard and #error.
> One final note, to clarify what I mean by "the situation will become
> worse": PODness in C++0x is not the same that in C++03! Really if we
> don't want to get crazy, I think we should keep the tr1 implementation
> as-is, then add a separate file for the C++0x one, starting the same as
> the tr1 one, and then gradually improved to the finest details of C++0x.
Ok. Then, do you agree that a place to start in on this is to start
adding in the "requirements" bits to the current TR1 type_traits
testing? Then we should be able to do easier copies and such when we add
C++0x testing.
I'm just trying not to stomp on your work. If you'd like, I can try to
do this today so that we're both on the same page for tomorrow.
In the meantime, I will try to write up a more coherent compatibility
post, with the examples I've been using to think about this.
-benjamin
More information about the Libstdc++
mailing list