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]

Re: use of type_traits


Benjamin Kosnik <bkoz@redhat.com> writes:

| 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?

include/bits/type_traits.h is a legacy from the old days and I think
it is redundant with include/tr1/type_traits, except for the namespace
issue.  Only if and when we have mechanism to protect ourselves from
evil macro and namespace pollution, can we switch completly to the
tr1 solutions (or we decide to implement C++0x and they got into the
WP, but I would not advise that for the time being).

The rationale for include/bits/cpp_type_traits.h is explained in that
file.  That is partly addressed by TR1 but again, we have the
namespace issue.

| 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?

yes, mostly.

| 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.

If we end up with uglifying names from include/tr1/type_traits, then
we might just keep include/bits/type_traits.h.

-- Gaby


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