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 this patch really necessary ? If it isn't, is usage of
pointer_traits<>::pointer_to really necessary ?
Yes. Just because our _Pointer_adapter allows implicit conversions
from raw pointers doesn't mean all fancy pointers allow that.
Note that I also found a bug in the
__gnu_test::CustomPointerAlloc::allocate, the signature with hint is
wrong.
Yes, that's a bug, thanks.
* include/ext/throw_allocator.h
(annotate_base::insert(void*, size_t)): Use insert result to check for
double insert attempt.
(annotate_base::insert_construct(void*)): Likewise.
(annotate_base::check_allocated(void*, size_t)): Return found iterator.
(annotate_base::erase(void*, size_t)): Use latter method returned
iterator.
(annotate_base::check_constructed(void*, size_t)): Return found
iterator.
(annotate_base::erase_construct(void*)): Use latter method returned
iterator.
This looks like the wrong ChangeLog.
* libstdc++-v3/testsuite/util/testsuite_allocator.h
(CustomPointerAlloc<>::allocate(size_t, pointer)): Replace by...
(CustomPointerAlloc<>::allocate(size_t, const_void_pointer)): ...this.
* testsuite/23_containers/unordered_set/allocator/ext_ptr.cc: Add
check.
