On 12/21/18 9:29 PM, Jonathan Wakely wrote:
On 16/12/18 14:16 +0100, François Dumont wrote:
Gentle reminder, we still have this issue pending.
* include/bits/hashtable_policy.h
(_Hashtable_alloc<>::_M_deallocate_node_ptr(__node_type*)): New.
(_Hashtable_alloc<>::_M_deallocate_node(__node_ty
On 16/12/18 14:16 +0100, François Dumont wrote:
Gentle reminder, we still have this issue pending.
* include/bits/hashtable_policy.h
(_Hashtable_alloc<>::_M_deallocate_node_ptr(__node_type*)): New.
(_Hashtable_alloc<>::_M_deallocate_node(__node_type*)): Use latter.
(_ReuseOrAllocNode<>::
Still waiting for this (I hope) last fix before gcc 9 release...
We could perhaps make:
_Pointer_adapter(element_type* __arg = 0)
explicit to find out if there are other places where we miss to properly
call pointer_traits<>::pointer_to. But I aren't sure we can do it in
this extension a
Gentle reminder, we still have this issue pending.
* include/bits/hashtable_policy.h
(_Hashtable_alloc<>::_M_deallocate_node_ptr(__node_type*)): New.
(_Hashtable_alloc<>::_M_deallocate_node(__node_type*)): Use latter.
(_ReuseOrAllocNode<>::operator<_Arg>()(_Arg&&)): Likewise.
* libstd
I am unclear about this patch, is it accepted ?
On 11/19/18 10:19 PM, François Dumont wrote:
On 11/19/18 1:34 PM, Jonathan Wakely wrote:
On 10/11/18 22:40 +0100, François Dumont wrote:
While working on a hashtable enhancement I noticed that we are not
using the correct method to deallocate no
On 11/19/18 1:34 PM, Jonathan Wakely wrote:
On 10/11/18 22:40 +0100, François Dumont wrote:
While working on a hashtable enhancement I noticed that we are not
using the correct method to deallocate node if the constructor throws
in _ReuseOrAllocNode operator(). I had to introduce a new
_M_deal
On 17/11/18 22:01 +0100, François Dumont wrote:
Here is the same patch but this time with a test change which is
supposed to show the problem.
However it doesn't because of:
_Pointer_adapter(element_type* __arg = 0)
{ _Storage_policy::set(__arg); }
which is not explicit.
So is thi
On 10/11/18 22:40 +0100, François Dumont wrote:
While working on a hashtable enhancement I noticed that we are not
using the correct method to deallocate node if the constructor throws
in _ReuseOrAllocNode operator(). I had to introduce a new
_M_deallocate_node_ptr for that as node value shall
Here is the same patch but this time with a test change which is
supposed to show the problem.
However it doesn't because of:
_Pointer_adapter(element_type* __arg = 0)
{ _Storage_policy::set(__arg); }
which is not explicit.
So is this patch really necessary ? If it isn't, is usage
While working on a hashtable enhancement I noticed that we are not using
the correct method to deallocate node if the constructor throws in
_ReuseOrAllocNode operator(). I had to introduce a new
_M_deallocate_node_ptr for that as node value shall not be destroy again.
I also check other places
10 matches
Mail list logo
