[boost] Re: Re: type_traits / is_compound

From: Daniel Frey (d.frey_at_[hidden])
Date: 2002-12-17 16:06:30

On Tue, 17 Dec 2002 19:35:01 +0100, Howard Hinnant wrote:

> On Tuesday, December 17, 2002, at 11:54  AM, Daniel Frey wrote:
> 
>> It might be useful to distinguish classes into unions and non-unions,
>> but the standard clearly says that a union *is* a class (9/1).
> 
> The standard also "clearly" says that unions and classes are different
> categories of types (3.9.2/1). ;-)

Clearly. :o)

> I think it is most clear that the standard authors did not anticipate
> the type traits library, or if they did, simply had much bigger issues
> to work on at the time.

Indeed.

>> It seems
>> that it makes sense to detect unions,
> 
> Yes, very much so.  You can derive from classes, but you can not derive
> from unions (9.5/1).

I know. I even tried to create a real detector, but it doesn't work. I
tried to start by:

class A {};

union U {};

namespace detail
{
    namespace is_union
    {
        template< typename T > struct derived : T {};
        typedef char yes_t;
        template< typename T >
        static yes_t test( void (derived< T >::*)() );
        struct no_t { char dummy[ 2 ]; };
        template< typename > static no_t test( ... );
    }
}

template< typename T > struct is_union {
    enum { value = ( sizeof( detail::is_union::test< T >( 0 ) ) ==
                     sizeof( typename detail::is_union::yes_t ) ) };
};

int main()
{
   cout << is_union< A >::value << endl;
   cout << is_union< U >::value << endl;
}

But the result was not what I hoped for, so even the "easy" cases don't
work :(

(Yes, I am aware of the fact that the above is by no means a complete
implementation.)

> I strongly feel that is_class answers yes to classes and structs and no
> to unions.  And is_union should answer yes only to unions.  This is the
> best interface and is consistent with section 3.9 of the standard (which
> was used to design the type traits library).  The fact that it can not
> currently be portably implemented is simply an unfortunate circumstance
> that will (hopefully) become less true in the near future.

I agree to that, although we are currently bound to existing compilers. To
create an is_class which also accepts unions is IMHO not a big problems as
unions are very rare in most projects (AFAIKT). It also allowes an easy
implementation of is_enum and is_enum is a real helper sometimes, so it's
"more important" to me. YMMV.

Regards, Daniel