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
Paolo Carlini wrote:
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...
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.
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.
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.
Paolo.