Travis Vitek wrote:
Martin Sebor wrote:
Eric Lemings wrote:
-----Original Message-----
From: Travis Vitek
Sent: Thursday, June 12, 2008 4:18 PM
To: Eric Lemings
Subject: RE: remove_reference
Eric Lemings
...
I think you sorta missed my point. My point is that if
the internal
type traits do not provide any real added value, why bother with
them? Say you have an internal class __rw_foo and a public class
foo which derives from __rw_foo but is virtual identical, why have
__rw_foo at all? Why not move everything in __rw_foo directly into
foo?
Sorry, I understood what you were getting at, I just didn't
come right out and provide the answer you were looking for.
Yes, we intend to use traits in the library implementation
where we can take advantage of them for performance
improvements. The example I provided above is just one of
many situations that we may do so.
Performance improvements...such as taking advantage of
built-in compiler
type traits? If that were the case, I could see the
rationale for using
internal type traits as a proxy for such optimization. So I
guess there
is SOME value after all. :)
The original idea, IIRC, was to expose the implementation
of the traits in the form of _RWSTD_XXX() macros to be used
by the rest of our code, including the standard type traits
template. Each macro would expand into either the compiler
built-in for compilers that supported them or to our own
__rw_xxx trait otherwise. The reason for this was to avoid
paying a penalty in terms of increased compile times and
keep the <type_traits> header free of unnecessary clutter
when using the compiler-provided traits, as well as to avoid
namespace pollution when using the traits.
So I've managed to diverge from the original idea. This is almost funny
considering all of the discussion that we had about the need for
internal traits to inherit from __rw_integral_constant<>.
Yes. We both forgot what we had discussed. We need to write these
things down.
Well, now that I've finally got the traits in subversion, I could go
back and 'fix' this to compile out the implementation types when the
necessary compiler support is not available. Something more like my
original implementation.
#ifndef _RWSTD_IS_POD
template <class _TypeT>
struct __rw_is_pod
{
enum { _C_value = _RWSTD_IS_TRIVIAL(_Type)
&& _RWSTD_IS_STANDARD_LAYOUT(_Type)
};
};
# define _RWSTD_IS_POD(T) _RW::__rw_is_pod<T>::type
#endif
FWIW, it might be worth waiting until it's been ported to other
compilers besides MSVC to see if it still makes sense and/or if
there is a better way to do it.
Martin
