Re: [boost] [type_traits] Modularization proposal

17 Sep 2014

      Andrey Semashev wrote:
...
What is the reason of having type_traits.hpp in the first place? If it's 
an "include all" header to simplify user's life then "all" means all, 
including common_type, IMHO.
I consider common_type a separate mini-library, and as such, it seems 
defensible to me for type_traits.hpp to not include it. Stated differently, 
I don't consider it part of "all".
...
I think such libraries should be fixed instead (by replacing 
type_traits.hpp inclusion with more specific headers).
If we consider use of type_traits.hpp a defect to be fixed, it doesn't make 
much sense to have it.

Either way, here's the list.

Inclusion report for  (in module type_traits):

    from convert:

    from detail:

    from geometry:

    from gil:

from graph:

from icl:

from iterator:

from msm:

from multi_array:

from numeric~odeint:

from numeric~ublas:

from property_map:

from python:

from signals:

from tr1:

Re: [boost] [type_traits] Modularization proposal

Peter Dimov