stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject fallback support for traits
Date Thu, 17 Jul 2008 16:59:49 GMT

I've already implemented fallback support for many traits. Here is a
list of those that I can think of off of the top of my head...

	__rw_is_class
	__rw_is_union
	__rw_is_empty
	__rw_is_polymorphic
	__rw_is_abstract
	__rw_is_convertible
	__rw_is_base_of
      __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

All of the fallbacks are supposed to provide a correct result where
possible, otherwise they should return a pessimistic result. I.e. The
fallback __rw_has_trivial_ctor<T>::value will be true for all (possibly
cv-qualified) scalar types, but will evaluate to false for class types
(struct, union or class).

Now I have to figure out what to do for a few more traits. Specifically
__rw_alignment_of<> and __rw_aligned_storage<>. As it stands now, these
traits require definition of _RWSTD_TT_ALIGN_OF() and
_RWSTD_TT_ALIGNED_POD() to be defined. If the macros are not provided,
we will see a compile failure.

As I see it, my options are...

	1. put code that will prevent instantiation in the the type
declaration (i.e. static_assert)
	2. provide a suitable default that is not correct, but can be
used to detect the failure
	3. disable traits entirely by defining _RWSTD_NO_EXT_CXX_0X if
the macros have not been defined
	4. disable the affected traits (and their tests) if the macros
have not been defined

As I see it, option 4 is probably best. Especially given the recent
discussion of removing all three alignment traits in favor of the new
alignof and alignas keywords and non-trivial unions.

Input anyone?

Travis

Mime
View raw message