On 07/25/2012 04:55 PM, Jonathan Wakely wrote:
Yes, I think so, it's a regression from 4.6.
Thanks for dealing with it so quickly.
Thanks indeed.
However, looks like we have another issue, unrelated to reserve, pure
performance not correctness, with the sheer number of rehashes when the
map
Attached patch applied on 4.7 branch.
Tested under Linux x86_64.
I will fix this small english issue in trunk ChangeLog.
François
On 07/26/2012 11:11 AM, Jonathan Wakely wrote:
On 25 July 2012 21:29, François Dumont wrote:
(_Hashtable<>::rehash): Likewise. Set _M_prev_resize to 0 t
On 25 July 2012 21:29, François Dumont wrote:
> (_Hashtable<>::rehash): Likewise. Set _M_prev_resize to 0 to avoid
> the hashtable to be shrinking on next insertion.
Not "to be shrinking" just "shrinking", but nevermind.
Attached patch applied to trunk. I am building 4.7 branch to also apply
the patch to this branch.
2012-07-25 François Dumont
PR libstdc++/54075
* include/bits/hashtable.h
(_Hashtable<>::_Hashtable(_InputIterator, _InputIterator,
size_type, ...): Remove std::ma
(CC gcc-patches)
On 25 July 2012 10:26, François Dumont wrote:
> Hi
>
> Here is a patch proposal for PR 54075. I also took the occasion to fix
> something that has been delay so far which is usage of std::max to get the
> number of buckets to use. The problem of using std::max when using the h
