Relation between a Container and the Allocator

[Catfish666]

To my understanding, a Container should have an Allocator member data, which is used internally.

Question: what happens, for example, when we swap() two containers that use different allocators?
Must the allocators be swapped as well?
Must all elements of the container be reallocated when the allocator is changed?

Thank you.

[JLBorges]

> what happens, for example, when we swap() two containers that use different allocators?

See: http://en.cppreference.com/w/cpp/concept/AllocatorAwareContainer

[Catfish666]

@ JLBorges: thanks for the link.

Now I understand that replacing the allocator depends on:

std::allocator_traits<allocator_type>::propagate_on_container_XYZ::value == true

I assume that if the allocator is replaced, then the elements must be destroyed, deallocated and then allocated and constructed all over again.
Is this correct?

Also, regarding this:

cppreference wiki wrote:

Swap will replace the allocator only if std::allocator_traits<allocator_type>::propagate_on_container_swap::value is true. Specifically, it will exchange the allocator instances through an unqualified call to the non-member function swap, see Swappable.

Unqualified call? Why unqualified?

[JLBorges]

> I assume that if the allocator is replaced, then the elements must be destroyed, deallocated
> and then constructed and allocated all over again.
> Is this correct?

No. All standard containers are moveable (std::array<> implicitly so).
Internally swap would just swap pointers to the memory holding the values.

Before swap:

Container ONE                                     Container TWO

Allocator A1                                      Allocator A2
Pointer(s) to values allocated by A1              Pointer(s) to values allocated by A2 

After swap:

Container ONE                                     Container TWO

Allocator A2                                      Allocator A1
Pointer(s) to values allocated by A2              Pointer(s) to values allocated by A1 

> Why unqualified?

Facilitate ADL (argument dependent name lookup) for the swap() function.

[Catfish666]

Thanks JLBorges.

However I'm still a bit confused about the pointers to values.
http://www.cplusplus.com/forum/general/127466/#msg690093

Since the pointer types are dependent on the allocator type, couldn't there be compatibility issues?

[JLBorges]

> Since the pointer types are dependent on the allocator type, couldn't there be compatibility issues?

You have already seen how that would be handled:
http://www.cplusplus.com/forum/general/127625/#msg690623

With the_original_allocator and some_other_allocator involved in a (well defined) move assignment or swap:

the_original_allocator::pointer foo( some_other_allocator::pointer p ) // slightly simplified
{
     if( p2 != std::nullptr_t )
          return std::pointer_traits<the_original_allocator>::pointer_to( *p ) ;
          
     else return the_original_allocator::pointer{} ;     
}

[Catfish666]

So the pointer type remains the one given by the original allocator, and we convert the new pointers to it.

Three questions:
1) What does // slightly simplified mean; is there more to do?
2) Why did you use std::nullptr_t instead of nullptr?
3) Why exactly is using dumb pointers a bad approach?

[JLBorges]

> What does // slightly simplified mean; is there more to do?

For a list, typically there is nothing more to it.
For a sequence container with random access iterators, p == end() may require special handling.



> Why did you use std::nullptr_t instead of nullptr?

std::iterator_traits<some_allocator>::pointer must be a NullablePointer
http://en.cppreference.com/w/cpp/concept/NullablePointer



> Why exactly is using dumb pointers a bad approach?

It is not the most flexible approach. For instance, it would break when a conforming allocator that places objects into segmented storage is used.
http://www.cplusplus.com/forum/general/127466/#msg690093

Don't worry too much about this. One can be a very competent C++ programmer without ever knowing the gory details about the implementation of strictly conforming allocators and allocator aware containers.