>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
prefix.
>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
>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].
rw/_meta_cv.h
* __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/_meta_trivial.h
* __rw_is_trivial
* __rw_has_trivial_ctor
* __rw_has_trivial_copy
* __rw_has_trivial_assign
* __rw_has_trivial_dtor
rw/_meta_nothrow.h
* __rw_has_nothrow_ctor
* __rw_has_nothrow_copy
* __rw_has_nothrow_assign
* __rw_has_nothrow_dtor
rw/_meta_sign.h
* __rw_is_signed
* __rw_is_unsigned
* __rw_make_signed
* __rw_make_unsigned
rw/_meta_arr.h
* __rw_rank
* __rw_extent
* __rw_is_array
* __rw_remove_extent
* __rw_remove_all_extents
rw/_meta_ptr.h
* __rw_add_pointer
* __rw_remove_pointer
* __rw_is_pointer
rw/_meta_ref.h
* __rw_is_lval_ref
* __rw_is_rval_ref
* __rw_is_ref
* __rw_add_lval_ref
* __rw_add_rval_ref
rw/_meta_member.h
* __rw_is_mem_ptr
* __rw_is_mem_obj_ptr
* __rw_is_mem_fun_ptr
rw/_meta_align.h
* __rw_aligned_storage
* __rw_aligned_union
rw/_meta_decay.h
* __rw_decay
rw/_meta_other.h
* __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.
>
[snip]
>
>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
>derivation).
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?
Travis
