std::allocator_arg(3)

πŸ“¦ version 2024.07.05, in nixpkgs unstable, opensuse-leap 16.0

πŸ’– NAME πŸ’–

okay so bestie, this is the std::allocator_arg(3) page from the C++ Standard Libary manual β€” yes, that’s the manual name, folded right up here so we didn’t have to copy the header line, periodt. It’s all about std::allocator_arg, the tiny helper that keeps overloads from fighting πŸ’….


✨ Synopsis ✨

Defined in header <memory> β€” literally right there in the synopsis, put it in your notes πŸŽ€

Defined in header <memory>
struct allocator_arg_t { explicit allocator_arg_t() = default; };
(since C++11)
constexpr std::allocator_arg_t allocator_arg =
(since C++11)
std::allocator_arg_t();
(until C++17)
inline constexpr std::allocator_arg_t allocator_arg =
(since C++17)
std::allocator_arg_t();

std::allocator_arg_t is an empty class type, and its whole main-character job is to disambiguate the overloads of constructors and member functions of allocator-aware objects πŸ‘‘. That includes std::tuple, std::function, std::packaged_task, (until C++17) and std::promise β€” yes, the marker is sitting right there in the list, keep it exactly like that 😭. And std::allocator_arg is a constant of std::allocator_arg_t. Slay.


πŸ’… Defect reports πŸ’…

The following behavior-changing defect reports were applied retroactively to previously published C++ standards. Not me reading lore, but okay πŸ‘€

  • LWG 2510 β€” applied to C++11; behavior as published: the default constructor was non-explicit, which could lead to ambiguity; correct behavior: made explicit. Iconic fix, fr fr ✨

πŸ‘‘ See also πŸ‘‘

  • uses_allocator β€” checks if the specified type supports uses-allocator construction (C++11); it’s a class template πŸ¦‹

That’s the whole vibe, bestie. Source/version: http://cppreference.com, dated 2024.06.10, and this page is std::allocator_arg(3) β€” byeee πŸ’–πŸŒΈπŸ«Ά

πŸ“¦ where this page comes from