Boost logo

Boost :

Subject: Re: [boost] [unordered] Buffered functions?
From: David Abrahams (dave_at_[hidden])
Date: 2008-12-28 14:41:56

on Sun Dec 28 2008, Howard Hinnant <> wrote:

> On Dec 28, 2008, at 1:25 AM, David Abrahams wrote:
>> The conundrum here is that if we use that technique for tuple, then a
>> tuple of empty types can never be empty itself. I'm starting to get ill
>> just thinking about a generic framework for composing "logically empty"
>> types that undoes this "EBO erasure" effect when necessary.
> Perhaps I'm misunderstanding. Reverting from English to C++ in the hopes of
> clarification. :-) The C++0X program and its output below look quite reasonable to
> me:


Reasonable, but unless I'm missing something, impossible, unless the
tuple itself is derived from all those empty bases. A class containing
an empty member is not itself empty, IIUC.

> I currently favor the "shallow hierarchy" design Doug outlined in c+
> +std-lib-18989. Though EMO isn't shown in that description, it is pretty simple to
> add to that design.

/me rummages through his committee message archive...

As far as I can tell from that thread, your solution and Doug's shallow
refinement show exactly the problem you were trying to warn about: any
empty element types become (private) bases of the tuple type itself,
leading to unintended namespace associations. As far as I can tell this
is no different in spirit from

  namespace std {

  template <class T, class A>
  class vector
     : private A

  } // std

  Such an implementation of "EMO" is error prone as it associates the namespace of the
  client-supplied A with that of the vector

And, BTW, this is all way too hard; at its limit it leads to building
every generic class template out of tuples instead of ordinary members.
We probably should have an EMO in the core language after all.

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at