Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: type_traits progress
Date: Thu, 29 May 2008 17:35:10 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA86C@exchmail01.Blue.Roguewave.Com>
Thread-Topic: type_traits progress
Thread-Index: AcjANDstlAUuks2GS7GM/9qvYfKHIgBp6+Dg
References: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA862@exchmail01.Blue.Roguewave.Com>
 <483B79A1.4070808@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA864@exchmail01.Blue.Roguewave.Com>
 <483C67BA.6070209@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

>Martin Sebor wrote:
>
>Travis Vitek wrote:
>> =20
>>=20
>>=20
>> 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?

>
>>=20
>>=20
>>>  *  Do the trait member (e.g., _C_type, _C_value) need to be
>>>     privatized or would it make more sense to use the=20
>>>     required names?
>>=20
>> I'm not sure what you're saying here. The types in the=20
>> public interface all have the required names [from the
>> base integral_constant template].
>>=20
>> 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=20
>> 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