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