Feature: support any allocator in offset_ptr_stl_allocator

[liss-h]

Support any stl-like allocator in offset_ptr_stl_allocator not just std::allocator

[bigerl]

Thx for PR. Looks good already, I would mainly sharpen the interface of offset_ptr_stl_allocator. With the requested changes, we could rename it to offset_ptr_allocator or offset_ptr_allocator_wrapper.

[bigerl]

only activate if upstream_allocator_type is copy constructible.

[liss-h]

Are there allocators that are not copy constructible? Would that work? I think all containers assume that they are copy constructible.

The only thing I'm aware of is allocators that are not assignable or swappable

[liss-h]

• There are only constants to customize assignment and swap behaviour
• There is also select_on_container_copy_construction which is required to create a new instance.
• all container ctors take allocator by const &

[bigerl]

about copy construction: you are right "(Note: Every Allocator also satisfies CopyConstructible.)" from https://en.cppreference.com/w/cpp/named_req/Allocator

[bigerl]

reviewing the link above I come to the conclusion that every allocator must have move/copy assignment and copy ctor. I couldn't find anything about move ctor but I think it is safe to assume that it will always be present if there is already a move assignment operator.

[liss-h]

You are wrong about assignment, there is nothing about assignment being required on that page you sent me. Only move+copy ctors.

copy ctor

move ctor

This can also be confirmed by looking at std::pmr::polymorphic_allocator as it does not have any operator=.

[liss-h]

But I've now defaulted the copy and move ctor, as it does not make sense to implement them manually