Re: [boost] [unordered] Buffered functions?

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 <hinnant-AT-twcny.rr.com> 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:
>

<snip>

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
http://www.boostpro.com