Re: [boost] [unordered] Buffered functions?

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

> On Dec 28, 2008, at 4:55 PM, David Abrahams wrote:
>
>> on Sun Dec 28 2008, Howard Hinnant <hinnant-AT-twcny.rr.com> 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
problems.

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

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