This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

use of type_traits


There are currently three type_traits implementations in the libstdc++ sources, of various designs and capabilities.

include/bits/cpp_type_traits.h
include/bits/type_traits.h
include/tr1/type_traits

I think everybody will agree that people should be using tr1/type_traits for their own code.

Indeed, in terms of functionality, bits/type_traits.h is used in one
place, and that use could be replaced with tr1/type_traits easily.

Large parts of cpp_type_traits.h usage could also be switched to tr1/type_traits.

So, my question is: what is the long-term plan WRT these three files? I
would like to see us consolidate down to tr1::type_traits, with
extensions being in __gnu_cxx::type_traits. I think this makes the most
sense. Other ideas? 

Long term, is this what others had in mind as well?

I'm not quite sure, exactly, why tr1/type_traits isn't being used in the
library proper. We're going to have to use either extensions or TR1, and
to me, TR1 is superior. Are we just worried about namespace pollution?
If that's the only objection, is there a way to configure tr1 for
internal library use, with uglified names (and is that too gross of a
solution? I believe this is possible, but may end up being too gross.) Hmmm.

Sorry if this has been discussed already. 

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]