stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: type_traits progress
Date Thu, 29 May 2008 23:35:10 GMT

>Martin Sebor wrote:
>Travis Vitek wrote:
>> If this is the case I may opt to merge the headers. i.e. _rw_has.h
>I'd get rid of the _rw prefix and abbreviate the names.

My example was flawed. None of the header names begin with the _rw

>E.g., use
>"ctor" instead of "constructor" etc. In fact, I wouldn't be at all
>upset if we abbreviated the names of some the private traits as
>well, e.g., truncate __rw_add_lvalue_reference to __rw_add_lval_ref
>or something similar). Not just to spare us the typing a few extra
>characters but also to reduce the sizes of symbol tables generated
>for specializations involving these critters (FYI: this was bad
>enough in C++ 98 that the IA64 ABI put in special cases for the
>most egregious symbols: std::string and std::wstring).

I'm all for cutting down the length of the names of the internal
classes. I'll do this in the next pass.

>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

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

    * __rw_add_const
    * __rw_add_volatile
    * __rw_add_cv
    * __rw_is_const
    * __rw_is_volatile
    * __rw_remove_const
    * __rw_remove_volatile
    * __rw_remove_cv

    * __rw_is_trivial
    * __rw_has_trivial_ctor
    * __rw_has_trivial_copy
    * __rw_has_trivial_assign
    * __rw_has_trivial_dtor

    * __rw_has_nothrow_ctor
    * __rw_has_nothrow_copy
    * __rw_has_nothrow_assign
    * __rw_has_nothrow_dtor

    * __rw_is_signed
    * __rw_is_unsigned
    * __rw_make_signed
    * __rw_make_unsigned

    * __rw_rank
    * __rw_extent
    * __rw_is_array
    * __rw_remove_extent
    * __rw_remove_all_extents

    * __rw_add_pointer
    * __rw_remove_pointer
    * __rw_is_pointer

    * __rw_is_lval_ref
    * __rw_is_rval_ref
    * __rw_is_ref
    * __rw_add_lval_ref
    * __rw_add_rval_ref

    * __rw_is_mem_ptr
    * __rw_is_mem_obj_ptr
    * __rw_is_mem_fun_ptr

    * __rw_aligned_storage
    * __rw_aligned_union

    * __rw_decay

    * __rw_enable_if
    * __rw_conditional

What do you think of this?

>>>  *  Do the trait member (e.g., _C_type, _C_value) need to be
>>>     privatized or would it make more sense to use the 
>>>     required names?
>> I'm not sure what you're saying here. The types in the 
>> public interface all have the required names [from the
>> base integral_constant template].
>> Everything else is an internal class, and I thought that we always
>> needed to use privatized names for internal classes exposed in the
>> headers. Using names consistent with those in the public interface
>> doesn't buy us anything significant that I can think of, and 
>> there is no requirement that I know of saying we should.


>One reason why I asked the question was that if we derived the
>standard traits from the implementation-defined ones we wouldn't
>need to re-declare these members. (I now see that we don't use

We're not allowed to. In all cases the public type is required to to
inherit 'directly or indirectly' from integral_constant<T,V>.

>Another, and probably far more important reason for keeping the
>names of the members the same, to make our implementation traits
>look and feel like standard traits, i.e., conform to the traits
>requirements. Otherwise the rest of our library won't be able
>to easily use the private traits.

But this should only be an issue if we are passing around traits as
template parameters, right?

All of the scenerios I can think of we would be using __rw_enable_if or
specialization on non-type template parameters. Can you think of any
case where the name of the member would be important?


View raw message