Boost logo

Boost :

Subject: Re: [boost] [unordered] Buffered functions?
From: David Abrahams (dave_at_[hidden])
Date: 2008-12-29 01:59:56

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

> On Dec 28, 2008, at 4:55 PM, David Abrahams wrote:
>> on Sun Dec 28 2008, Howard Hinnant <> wrote:
>>>> 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.
>>> This conclusion would be an option for class template designers, not a
>>> requirement. And it would be easier than constantly reinventing EMO.
>> Yes, but, why should we have to worry about that?
> <practical>
> Because language supported EMO isn't a realistic possibility in C++0X but allowing
> (not requiring) EMO emulation in tuple is a realistic possibility (N2800 arguably
> already allows the latter).
> </practical>
> That being said, if you can get an easier to use solution into C++0X,
> then you're the man! :-)

"Even I" can't slip that feature in without anyone noticing at this late date.

>> Hmm,
>> int f(void*);
>> char* f(some_empty_type*);
>> int x = f(tuple_containing_some_empty_type); // compilation error.
> Excellent test case, thanks!
> Ok, I've made a slight tweak to my example implementation, and to the test case. The
> tuple still does space compression, but not to the extent as shown previously.
> Still, I believe it equals the performance of boost::compressed_pair:

I think I'd choose the space compression over the overloading protection
in this case. Apart from the fact that it's too darned easy, there's no
particular reason anyone *has* to make unqualified calls on raw tuples,
and it should be possible to explicitly qualify your way out of any such

> Note that as you asserted previously, a tuple is never empty.
> However, for this tuple it is possible that the sum of the sizeof its
> elements is less than the sizeof the tuple. This means that (for
> example), one could write create a smart pointer like so:
> template <class T, class D = default_delete<T>>
> class unique_ptr
> {
> tuple<T*, D> data_;
> public:
> ...
> };
> And not have to worry about whether D is a function pointer or empty policy class, and
> still get sizeof(unique_ptr) == sizeof(T*) when D / is/ an empty policy class.

If tuple is to be an all-purpose space compression utility, it should at
least compose efficiently. You can always do the above when you want to
present a higher-level interface that doesn't create unintended base

>> It's not just a matter of what namespaces are associated, but also which
>> functions in those namespaces will match.
> <nod> Thanks for the good test case. Please come up with more! :-)

How about this one:

    struct empty1 {};
    struct empty2 {};
    struct empty3 {};

    struct A { empty1 x1; empty2 x2; };
    struct B { A x3; empty3 x4; };
    assert(sizeof(A) == 1 && sizeof(B) == 1);



Dave Abrahams
BoostPro Computing

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