[boost] Re: more empty_member fun

From: Darin Adler (darin_at_[hidden])
Date: 1999-11-30 21:08:07

> How about specializing empty_member so that the first member can be
> either a class or a pod?  We would need to use a type_traits class (or
> something) to determine if the first member is a pod or not.  For
> purposes of discussion, I've lumped this into call_traits because it was
> handy, but that's not where I think it should go.

I like the idea of specializing empty_member so the potentially-empty member
can be a function pointer instead of a class. It's quite likely that the
very members that are most likely to be empty are also likely to be
functor/function objects and in need of this optimization.

You're not really checking whether something is a POD, though. You want to
know if you can derive from it, so what you want to do is to check if it's a
class type or not. (The standard uses the name "class" to mean a class,
struct, or union.) The term POD means something else. For example, "struct S
{ }" is a POD type.

If we make this change, it makes sense to use private inheritance instead of
public inheritance, since you must use an accessor function for the case
where the potentially-empty object is not a base class.

Extending the possibly-empty optimization to the second object in the
template might be OK. The point of the optimization is to group
likely-to-be-empty members with not-likely-to-be-empty ones. If there are
any always-non-empty members, they should be grouped with the possibly-empty
ones. But you might have a class with few members, and have no choice but to
group two possibly-empty members together. Making the change does make the
class a bit easier to understand (first() and second() vs. "using the object
directly" and member).

    -- Darin