Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
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.
But only for the unusual specializations where the alignment
isn't the same as one of the fundamental types, right?
I can't see how to implement aligned_storage<S,A> even for alignments
that are equal to the alignments of fundamental types if I have no way
to get the alignment a a fundamental type as an integral constant value.
Isn't sizeof(T) a good enough guess? I mean, do we know of
a platform where sizeof(T) isn't the same as the alignment
of T for all fundamental types?
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.
We still need to write up the issue...
Yeah.
As for providing the traits only conditionally, I'm not sure
that's the best approach. If we feel it likely that some of
them will end up getting yanked from the working paper we
should probably avoid providing them at all, otherwise we
might be stuck maintaining them for a long time. Providing
them only for some platforms would also make them difficult
to use portably (we'd have to expose some kind of config
macro for users to check whether the trait is defined or
not).
Why would we need to support them? If we disabled them by default and
told users the functionality is experimental and depends on the
direction of the standard, then it seems that we should be free to yank
them. Of course that requires that the functionality be disabled by
default (which we're currently talking about changing).
That's one way to interpret it. I guess I never thought
of it as including the removal of new features, only
(hopefully fairly small) changes.
So my preference would be either (2) or (5), with option 5
being to disable the aligned traits unconditionally until
we know for certain that they aren't going away.
I would be okay with that also.
Okay, then I suggest we go with the more conservative one
of the two (i.e., 5). That way we don't have to worry about
removing features after they've been released and potentially
used by customers. You can leave the code in place but #ifdef
it out by some internal macro. If you want to continue to test
the traits so they don't get broken by something, have the
tests #define the macro before including <type_traits>.
Out of curiosity, what do other implementations do?
Ah, here is the answer. I had written code to try to detect alignment,
and it worked on msvc-7.1 and msvc-8.0, but failed to compile on gcc-4.3
and eccp-3.10. As it turns out the Boost library is using a very similar
trick that appears to work on both compilers.
So this gets me an implementation of __rw_alignment_of<>. With that I
should be able to provide a fallback implementation of
__rw_aligned_storage<> that works with fundamental alignments.
Thank you for nudging me to look back at the reference implementation.
Travis
Martin
Input anyone?
Travis
