Exactly my point. If they need a functioning allocator in their moved-from
state, shouldn't they be copying the allocator instead of moving it, rather
than imposing a (in my opinion) counter-intuitive requirement on allocators?

On Mon, Jun 3, 2019 at 10:38 PM Tony V E <tvaneerd_at_[hidden]> wrote:

>
>
> On Mon, Jun 3, 2019 at 10:52 AM Martin Sjogren via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> As a result of https://cplusplus.github.io/LWG/issue2593 after
>> move-constructing an allocator x from an allocator y the standard will
>> require that x and y compare equal. My understanding is that this is
>> because moving a container also moves the allocator, but (some?) moved-from
>> containers still need a functioning allocator.
>>
>> But doesn't this effectively mean that moving from an allocator is
>> impossible and in the vast majority of cases moving needs to be implemented
>> as copying?
>>
>> Wouldn't it make more sense for the containers that need an allocator in
>> their moved-from state to copy their allocator instead of moving?
>>
>
> All standard containers that have an allocator need an allocator in their
> moved-from state. A moved-from container is still a functioning container.
>
>
>> As-is, I feel like there's a big trap when implementing an allocator that
>> you have to take very special care with the move constructor (or in
>> practice just not have one)
>>
>> Would there be any interest in an issue report for this?
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> http://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
>
>
> --
> Be seeing you,
> Tony
>