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