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.
