Compatibility with std::uses_allocator
Closed this issue · 3 comments
Minor query regarding behaviour of putting std::uses_allocator-conforming types into an any. Just been fighting my way through a lot of confusing compiler errors and in the end I got things working and the errors were down to my misunderstandings. However one part of the code that I was looking at as part of this looks a little off (albeit very much an edge case).
In emplace_in_empty, you have an optimization based on checking std::is_nothrow_constructible_v<T, Args&&...>. It seems like technically this should maybe rather be based on noexcept(alloc_traits::construct(...)) though from the standard that would always be false, so perhaps you're enabling this based on surrounding context. However even if so it looks to me like there's an issue here in that alloc_traits::construct may not actually call the Args&&... constructor overload at all. When the type being inserted is uses_allocator compatible with the any's allocator, the default allocator_traits will invoke a different overload taking an additional allocator, and there's no guarantee that that overload will be noexcept even if an Args&&... one exists and is noexcept. As I said, corner case, but thought was worth pointing out.
Yes, if nothrow_constructible<T, Args...> is true and alloc_traits::construct invokes other constructor, which throws, then memory leak possible.
Its because allocator_traits::construct has no 'noexcept' specifier by standard. I just hope, that semantic of X(Args...) is same as X(additional alloc args, Args...), so throw specifiers will be same (almost 100% it will have no noexcept specifier, because it uses allocator and should allocate, in this case problem not exist).
So, worst case is one small memory leak (memory leaks are safe code)))) in very specific case and its fixable only by removing optimization, i think its just tradeof and hope it will never happen
Just been fighting my way through a lot of confusing compiler errors
It may be caused by SFINAE friendly Methods (for example created by macros like anyany_method), diagnostics really worse with with sfinae
It may be caused by SFINAE friendly Methods (for example created by macros like anyany_method)
Honestly it was mostly just typical C++/STL errors, not anything too specific to anyany implementation.
almost 100% it will have no noexcept specifier, because it uses allocator and should allocate
If I understand right, I don't think this is the case because most such constructors will just store off the allocator and not actually use it immediately, and allocator copy-construction is assumed noexcept (see for example std::vector::vector(alloc) noexcept). That said, I agree with you that chances of noexcept differing from no-allocator overload are close to zero. So yeah if you're aware and happy to make that trade-off, no worries. Feel free to close the issue.