Direct use of Allocator::allocate is deprecated in C++17

[uecasm]

format/include/boost/format/alt_sstream_impl.hpp

Lines 40 to 45 in 7f4131b

	#ifdef _RWSTD_NO_CLASS_PARTIAL_SPEC
	void *vd_ptr = alloc_.allocate(sz, is_allocated_? eback() : 0);
	Ch *new_ptr = static_cast<Ch *>(vd_ptr);
	#else
	Ch *new_ptr = alloc_.allocate(sz, is_allocated_? eback() : 0);
	#endif

Should use allocator_traits when at least C++11 is detected instead; the above code produces a deprecation warning in some compiler configurations.

There might be some other code that should be updated as well, but this was the only one that I noticed a warning being flagged on (when compiling with VS2017 in C++17 mode).

[bansan85]

Right. LibreOffice uses the following patch :

-newptr = alloc_.allocate(new_size, is_allocated_? oldptr : 0);
+newptr = std::allocator_traits<compat_allocator_type>::allocate(alloc_, new_size, is_allocated_? oldptr : 0);

[jwakely]

The issue title is misleading: only the two argument form of std::allocator<T>::allocate is deprecated (i.e. the form taking a 'hint' argument). And that form has not been required for user-defined allocators since C++11: allocators are only required to provide allocate(size_type n), so portable use of a hint has required going via allocator_traits<Alloc>::allocate for almost a decade.

Using allocator_traits directly is necessary to portably pass a hint, but it would also be possible to just stop passing a hint argument. Do any real allocators make use of the hint?

[uecasm]

While that's true, as noted in the original description at least MSVC's STL does generate a deprecation warning on direct calls to std::allocator::allocate, which is how I noticed this in the first place. Or it's that std::allocator<void> itself is entirely deprecated.

Related, there are also no calls to construct/destroy, which do have to go through allocator_traits. They're guaranteed no-ops for std::allocator and all standard char types, but might possibly be interesting for a non-standard allocator. Probably not a big deal though.

It also doesn't follow the allocator propagation rules and doesn't have a allocator instance constructor, which might be a bigger deal. As such it doesn't qualify as an AllocatorAwareContainer -- which it wouldn't anyway since it's not a Container, but it's almost one.

[jwakely]

Yeah, this code looks like it takes an allocator argument, but only actually works when that argument is std::allocator, so it might as well not bother pretending to support allocators at all. Oh well.

[glenfe]

Resolved in 5884c3d.