stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: Traits used by the implementation
Date Wed, 02 Jul 2008 15:26:15 GMT
Travis Vitek wrote:
> In an effort to better organize the type traits, I'm attempting to
> figure out what traits we expect to be using in the implementation.
> 
> I see that the tuple implementation is using __rw_remove_reference

Right.

> and
> that there are already some parts of the library that use __rw_is_same
> (from rw/_select.h) and __rw_select (which is similar to
> __rw_conditional<__rw_is_integral<T>::value>, void*, int).

Now that we have the real type traits I'd like us to switch to using
them and get rid of rw/_select.h and (probably) rewrite the container
member function templates using __rw_enable_if. It's very likely that
we'll still need __rw_is_integral, but there might be better ways to
implement the dispatch mechanism, possibly without relying on some
of the traits that it seems to be relying on now (or there may not).

> 
> It is my thinking that the above listed traits, the __rw_has_trivial_*,
> __rw_has_nothrow_*, __rw_is_pod, __rw_is_void, __rw_is_array,
> __rw_conditional, __rw_enable_if and __rw_disable_if traits would all be
> useful in the library implementation. So these traits, and their
> dependencies should probably be made available internally. 

Sounds about right to me. It might even possible to find smaller
subgroups within this larger group that will be useful in some
areas independently of one another.

> 
> That would mean that the following traits would be kept in namespace
> __rw (I've provided a list of traits and their dependencies near the end
> of this message).

Wow! I hadn't realized there were so many of them. But I agree that
they look like the likely candidates.

> 
> __rw_is_void
> __rw_is_array
> __rw_is_scalar
> __rw_is_arithmetic
> __rw_is_enum
> __rw_is_pointer
> __rw_is_member_pointer
> __rw_is_reference
> __rw_is_lvalue_reference
> __rw_is_rvalue_reference
> __rw_is_same
> __rw_is_const
> __rw_remove_cv
> __rw_is_trivial
> __rw_is_standard_layout
> __rw_is_pod
> __rw_remove_all_extents
> __rw_has_trivial_ctor
> __rw_has_trivial_copy
> __rw_has_trivial_dtor
> __rw_has_trivial_assign
> __rw_has_nothrow_ctor
> __rw_has_nothrow_copy
> __rw_has_nothrow_assign
> 
> Other traits would be removed from namespace __rw and their
> implementation moved to <type_traits>.

Would moving them but still leaving them in namespace __rw be
safer? We might find out that we need some of them later, and
if we don't, I'm wondering if sequestering the implementations
in our private namespace might better insulate them from
potential ABI breakage when we make changes to them.

> Are there any other traits that
> might be useful inside the library implementation?

__rw_remove_reference is missing from the list, although you
did mention it above.

If we're completely confident in the stability of the initial
list (I know I'm not), a possible approach, to save us the time
shuffling things around as we discover where various traits or
groups of them are needed, is to hold off on doing the reorg
until we've actually started using the traits in major portions
of the library (such as the containers).

> 
> Travis
> 
> 

Thanks for putting together the breakdown below! It's going to
be very useful. We might want to copy it to a page on the Wiki
for easy reference.

Martin

> 
> 
> 
> 
> 
> Traits with no dependencies
> 
> __rw_is_void
> __rw_is_integral
> __rw_is_floating_point
> __rw_is_array
> __rw_is_pointer
> __rw_is_lvalue_reference
> __rw_is_rvalue_reference
> __rw_is_union (**)
> __rw_is_class (**)
> __rw_is_member_pointer
> __rw_remove_pointer
> __rw_remove_reference
> __rw_remove_extent
> __rw_remove_all_extents
> __rw_remove_const
> __rw_remove_volatile
> __rw_is_same
> __rw_is_base_of (*)
> __rw_conditional
> __rw_enable_if
> __rw_disable_if
> __rw_aligned_storage
> __rw_is_signed
> __rw_is_unsigned
> __rw_rank
> __rw_extent
> __rw_alignment_of (*)
> 
>  * requires compiler support
> ** could be implemented without compiler support it if the other had it.
> 
> Traits and their dependencies
> 
> __rw_is_standard_layout (*)
> 	__rw_is_scalar
> 	__rw_remove_cv
> 	__rw_remove_all_extents
> 
> __rw_is_trivial (*)
> 	__rw_is_scalar
> 	__rw_remove_cv
> 	__rw_remove_all_extents
> 
> __rw_has_trivial_ctor (*)
> 	__rw_is_pod
> 	__rw_remove_all_extents
> 
> __rw_has_trivial_copy (*)
> 	__rw_is_pod
> 	__rw_is_reference
> 
> __rw_has_trivial_dtor (*)
> 	__rw_is_pod
> 	__rw_is_reference
> 	__rw_remove_all_extents
> 
> __rw_has_trivial_assign (*)
> 	__rw_is_pod
> 	__rw_is_const
> 	__rw_is_reference
> 
> __rw_has_nothrow_ctor (*)
> 	__rw_has_trivial_ctor
> 
> __rw_has_nothrow_copy (*)
> 	__rw_has_trivial_copy
> 
> __rw_has_nothrow_assign (*)
> 	__rw_has_trivial_assign
> 
> __rw_is_pod (*)
> 	__rw_remove_all_extents
> 	__rw_is_standard_layout
> 	__rw_is_trivial
> 	
> __rw_is_function (*)
> 	__rw_is_void
> 	__rw_is_array
> 	__rw_is_lvalue_reference
> 	__rw_is_rvalue_reference
> 
> __rw_is_member_object_pointer
> 	__rw_is_function
> 
> __rw_is_member_function_pointer
> 	__rw_is_function
> 
> __rw_is_reference
> 	__rw_is_lvalue_reference
> 	__rw_is_rvalue_reference
> 
> __rw_is_arithmetic
> 	__rw_is_integral
> 	__rw_is_floating_point
> 
> __rw_is_fundamental
> 	__rw_is_arithmetic
> 	__rw_is_void
> 
> __rw_is_object
> 	__rw_is_function
> 	__rw_is_reference
> 	__rw_is_void
> 
> __rw_is_scalar
> 	__rw_is_arithmetic
> 	__rw_is_enum
> 	__rw_is_pointer
> 	__rw_is_member_pointer
> 	[__rw_is_same, __rw_remove_cv]
> 	std::nullptr_t
> 
> __rw_is_compound
> 	__rw_is_array
> 	__rw_is_function
> 	__rw_is_pointer
> 	__rw_is_reference
> 	__rw_is_class
> 	__rw_is_union
> 	__rw_is_enum
> 	__rw_is_member_pointer
> 
> __rw_add_lvalue_reference
> 	__rw_is_void
> 	__rw_is_reference
> 	__rw_is_rvalue_reference
> 
> __rw_add_rvalue_reference
> 	__rw_is_object
> 	__rw_is_function
> 
> __rw_remove_cv
> 	__rw_remove_const
> 	__rw_remove_volatile
> 
> __rw_add_const:
> 	__rw_is_function
> 	__rw_is_reference
> 
> __rw_add_volatile:
> 	__rw_is_function
> 	__rw_is_reference
> 
> __rw_add_cv:
> 	__rw_add_const
> 	__rw_add_volatile
> 
> __rw_add_pointer
> 	__rw_remove_reference
> 
> __rw_is_convertible (*):
> 	__rw_is_array
> 	__rw_is_function
> 	__rw_remove_extent
> 	__rw_add_pointer
> 	__rw_add_lvalue_reference
> 	__rw_is_void
> 
> __rw_aligned_union:
> 	__rw_conditional
> 
> __rw_decay:
> 	__rw_remove_reference
> 	__rw_conditional
> 	__rw_is_function
> 	__rw_add_pointer
> 	__rw_remove_cv
> 	__rw_is_array
> 	__rw_remove_extent
> 
> __rw_make_signed, __rw_make_unsigned
> 	__rw_remove_cv
> 	__rw_conditional
> 	__rw_is_integral
> 	__rw_is_const
> 	__rw_add_const
> 	__rw_is_volatile
> 	__rw_add_volatile
> 
>  * only if necessary compiler support does not exist. If compiler
> support is provided and correct, then the implementation is trivial.
> 


Mime
View raw message