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:
>>> 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.
>>>> 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk