From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-12-17 13:35:01
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). ;-)
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.
> 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). Traits such as is_empty rely on being able to
differentiate classes and unions because of this.
> but AFAIK it's not possible to do
> this automatically.
> It requires the user to tell us about all unions,
> which is dangerous if we rely on the detection of unions.
> Maybe we
> should go for this way:
> - is_class detects classes, structs and unions automatically
> - is_union detects unions with the help from the user
> If you really need a 'real class' or struct, you test for (is_class &&
> !is_union). Or we could create another helpers like is_non_union.
As the type traits library is currently a proposal before the standards
committee, imho we need to be *very* clear about the interface. And we
need to specify the interface that will be most beneficial to the
generations of C++ programmers to come, even if that interface is not
implementable in C++98. Already C++ compilers are coming to market in
which is_union *is* implementable via extensions (Metrowerks Pro 8 for
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk