Do rebound allocators have the same size_type and difference_type?

97 Views Asked by At

After reading a very in-depth article on fancy pointers, where it is also described their correlation with allocators, I had a doubt. The paper covers several aspects of fancy pointers, but does not specify whether two different specializations of a FancyPtr type require to have the same difference_type.

By extension, I have the following question: given an allocator A and two different specializations, std::allocator_traits<A>::rebind_alloc<T> and std::allocator_traits<A>::rebind_alloc<U>, are size_type and difference_type guaranteed to be the same?

2

There are 2 best solutions below

0
Alain Paulin Niyonkuru On BEST ANSWER

The C++ Standard Library provides the concept of allocators for memory management. The rebind mechanism is used to convert an allocator for one type to an allocator for another type, ensuring that the allocator's typedef members like size_type and difference_type are adapted to the new type.

In most cases, when you use rebind to adapt an allocator to a different type, the size_type and difference_type of the rebound allocator will remain the same as the original allocator. This is because these typedefs are often dependent on the allocator itself, rather than the types it allocates.

However, the C++ standard doesn't mandate that size_type and difference_type must be the same across all allocator specializations, even after rebinding. It's not guaranteed behavior. While it's common for size_type and difference_type to remain the same after rebinding, there might be specific scenarios or custom allocators where these types could differ.

If you want to ensure the behavior for a specific allocator or fancy pointer, you should refer to the documentation for that particular allocator or pointer type. Always rely on the documentation and specifications provided by the library or framework you are using, as there could be implementation-specific differences or variations.

0
user17732522 On

No, I don't see any such requirement in the standard.