Re: [boost] [unordered] Buffered functions?

Subject: Re: [boost] [unordered] Buffered functions?
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-11-26 11:34:10

Howard Hinnant wrote:
> On Nov 25, 2008, at 4:42 PM, David Abrahams wrote:
> 
>> on Mon Nov 24 2008, "Daniel James" <daniel_james-AT-fmail.co.uk> wrote:
>>
>>> 2008/11/24 Thorsten Ottosen <thorsten.ottosen_at_[hidden]>:
>>>>
>>>> 1. storing two functors had to do with implementing exception safety if
>>>> copying of the functors may throw. Was it swap() that was the problem?
>>>
>>> Here's the original post where I described the problem:
>>>
>>> http://lists.boost.org/Archives/boost/2005/02/80211.php
>>>
>>> I think it also applies to assignment.
>>
>> This looks like a bug in the standard.  Equality and hashing should be
>> required to be nothrow-swappable.  I've raised that issue on the
>> committee reflector.
> 
> Fwiw, I support nothrow-swappable and encourage others to express their 
> opinions on this issue.  This is a decision that will impact all of us.

I agree. This will simplify our lives. Now I would like to see a real 
case where the comparison function or the hash function throws.

Regards,

>>>> 2. the space optimization only gave little less space.
>>>
>>> The cost from not using EBO amounts to a few bytes - which can
>>> sometimes be offset due to alignment. Since 4 bytes is typically
>>> required per bucket it doesn't seem like a large amount.
>>
>> Some people really care about the space taken up by an empty container.

I was the review manager for the unordered library and I remember the 
issue was discussed in the review. My personal view was to avoid having 
buffered functions but unordered library took the refreshing approach of 
having stronger guarantees, something that I also like.

For example, unordered_multisets have an additional pointer to group 
equal values in a singly linked list so that bucket traversing is linear 
to the number of different values instead of the number of values in the 
bucket. It's a nice feature and useful in several scenarios (I even 
added that option to Intrusive unordered containers), but you have to 
pay for it ;-)

> I have high hopes that std::tuple will become the compressed_pair of the 
> future.  Technically, and especially with variadic template language 
> support, it is not that hard to do (tuple is a pain no matter what 
> without variadic template language support).  Standards-wise, the 
> current C++0X draft (N2798) does not outlaw, nor mandate, the empty 
> member optimization for tuple, and I hope to keep it that way.  Recent 
> straw polls on the LWG have been favorable to allowing the empty member 
> optimization for std::tuple.
> 
> -Howard

I hope EBO gets into tuple. Tuple seems quite lightweight for 
compilation times in C++0x but let's avoid using tuple to do some EBO in 
unordered because pushing all the preprocessor machinery to do simple 
EBO it's a bit of overkill.

Regards,

ion