[boost] Re: more empty_member fun

From: scleary_at_[hidden]
Date: 1999-12-01 10:19:19

> > 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.
>
> ...
>
> 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).

I agree with allowing empty_member to be able to hold function pointers (or
any other non-class type).  I also agree with allowing either class to be
the possibly empty class (I have had to check the header several times to
remind myself which one is first).

I have a problem with doing it through traits, because we would have to
specialize, not only for every possible scalar and member pointer type, but
every possible function pointer and member function pointer type.  Is this
even possible?

I've toyed around with developing another form of solution, but to no avail.
Any sort of automatic test for emptyness or non-emptyness requires that the
template argument be a class, so we're in a catch-22 as far as doing it
automatically.

So the conclusion is: we either 1) say that only classes may be possibly
empty -- this will force all classes that use empty_member (such as
StoredVec) to have the same restriction, requiring users to use
pointer_to_unary_function or pointer_to_binary_function; or 2) try to do the
traits method as well as possible (but we cannot specialize for _every_ kind
of function pointer).

Neither of these solutions are perfect; but in this case a perfect solution
may not be possible due to language restrictions.  Are there any other
ideas?

        -Steve