stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: type_traits progress
Date Sat, 31 May 2008 22:57:35 GMT
Travis Vitek wrote:
> Martin Sebor wrote:
>> Travis Vitek wrote:
>> [...]
>>>> On a related note, I wonder if it would make sense to consolidate
>>>> some of the implementation headers that we don't expect to be useful
>>>> in the rest of the library on their own (e.g., all the ctor
>>>> headers/traits).
>>> I think it would. I'd like to consolidate these a little further. I'd
>>> like to either put them in headers by category, something like this
>>> [those not mentioned would go into their own header].
>> My initial thought was to group them based on how they are
>> likely to be used in the rest of the library. Another option
>> would be to follow the breakdown used by the standard. Your
>> organization doesn't seem to fall into either of these two
>> categories. What was your rationale for it?
> I'm just grouping closely related traits.
>>>   rw/_meta_arr.h
>>>     * __rw_rank
>>>     * __rw_extent
>>>     * __rw_is_array
>>>     * __rw_remove_extent
>>>     * __rw_remove_all_extents
> As an example, the array traits above are all closely related and their
> implementations are similar. There are five traits, and those traits
> span three sections of the standard.
> I'm open to doing some type of grouping, we just need to understand how
> we want to group them and then how we want to name the files.

Like I said, the most useful grouping I see is keeping together
those traits that are likely to be used together in the rest of
the library. I expect us to make heavy use of type traits in
containers and their supporting algorithms to optimize away
unnecessary initialization, explicit destruction, and exception

 From this POV, containers will most likely need the is/has_trivial
family of traits, along with has_nothrow_xxx, and __rw_enable_if
and maybe also __rw_conditional. I'd like us to be able to bring
these into scope without dragging in all the others. The ones
that we won't use in the rest of the library might just as well
be in the same header (such as <type_traits>) as far as I'm


View raw message