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@dezide.com>:
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