On 21/10/2024 06:56, François Dumont wrote:
On 17/10/2024 23:11, Jonathan Wakely wrote:
On Thu, 17 Oct 2024 at 21:39, Jonathan Wakely <jwakely....@gmail.com>
wrote:
On Thu, 17 Oct 2024 at 20:52, François Dumont
<frs.dum...@gmail.com> wrote:
Here is an updated version that compiles, I think, all your
feedbacks. It's much cleaner indeed.
Thanks, I'll take a look tomorrow.
It's also tested in C++98/17/23.
I'm surprised that we do not need to consider potential
allocator::const_pointer.
Do you mean consider the case where Alloc::const_pointer is not
the same type as rebinding 'pointer' to a const element type?
Yes, exactly.
We don't need to consider that because we never get a
'const_pointer' from the allocator, and we never need to pass a
'const_pointer' to the allocator. The allocator's 'allocate' and
'deallocate' members both work with the 'pointer' type, so we
only need to use that type when interacting with the allocator.
For all the other uses, such as _Const_Node_ptr, what we need is
a pointer-to-const that's compatible with the allocator's pointer
type. It doesn't actually matter if it's the same type as
allocator_traits<Alloc>::const_pointer, because we don't need
Sorry, I sent the email before finishing that thought!
... we don't need to pass a const_pointer to anything, we only need
it for the container's own purposes.
But thinking about it some more, do we even need a const-pointer for
the container? Currently the const_iterator stores a const-pointer,
and some members like _M_root() and _M_leftmost() return a
const-pointer. But they don't need to. The nodes are all pointed to
by a non-const _Base_ptr, none of the storage managed by the
container is const.
Except _M_impl._M_header in a const context.
Using const_cast would result in a similar UB that you fixed on
_GLIBCXX_DEBUG containers, no ?
I can provide a version with the const_cast but I'm not sure it worth it.
François
