stdcxx-dev mailing list archives

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

We currently have the _RWSTD_TT_* macros (referred to below as _TT_
macros). The original intent was to define them to the compiler built-in
for the named type trait. I.e., _RWSTD_TT_IS_POD(T) would expand to
__is_pod(T) on those systems that supply the __is_pod() built-in.

While porting the traits, I wrote code to augment the definition of
several of these macros. For instance, on eccp-3.10, the
__has_trivial_constructor() built-in evaluates to false for scalar types
and arrays of such types, but it does correctly detect class types that
have a trivial default constructor. So I do something like this for such
a platform...

  template <class _TypeT>
  struct __has_trivial_ctor_impl
  {
      typedef typename
      __rw_remove_all_extents<_TypeT>::type _TypeU;

      enum { value =    __rw_is_scalar<_TypeU>::value
                     || _RWSTD_TT_HAS_TRIVIAL_CTOR(_TypeU) };
  };

  #undef _RWSTD_TT_HAS_TRIVIAL_CTOR
  #define _RWSTD_TT_HAS_TRIVIAL_CTOR(T) \
      _RW::__rw_has_trivial_ctor_impl<T>::value

Now I have a macro that evaluates to true under the right conditions,
but it isn't defined to be the same as one of the built-ins as
originally intended. It was suggested that I not do this, and instead
only define the macros to the built-ins that are provided.

The problem is that I don't really see the macros as being very useful
when they are not as accurate as they could be. Another issue is that in
some cases, my fallback (which uses little or no compiler support) is
more accurate than the provided trait. In these cases, I don't define
the _TT_ macro, and I just use the fallback implementation. So now I'm
ignoring the compiler support in some cases. The advantage of doing this
is that I don't need to add a bunch of conditional code to the internal
headers to avoid using broken built-ins.

So, my question is, what is the right way? Should I always define the
_TT_ macros to the native traits only, even if they're broken and then
just work around the issues at the definition of the trait template? Is
it acceptable to not define the _TT_ macro when the internal trait is
available, but is broken?

Travis

Mime
View raw message