In most places where the C++ standard library allocates memory, the user is able to customise this by providing a class which meets the Allocator requirements. For example,
Not an exhaustive list.
<stdexcept>, which needs to allocate memory to store the message string.boyer_moore_searcher and boyer_moore_horspool_searcher.<algorithm> algorithms attempt to obtain additional memory (e.g., stable_partition, stable_sort) and all parallel algorithms (regardless of header) may need additional memory.path; that one used to use the default allocator internally, but looks like the newest draft removed that requirement, although it seems to be the intent still.directory_iterator and recursive_directory_iterator. paths .basic_regex.thread and async.packaged_task, allocator support removed in C++17.promise will need somewhere to put the shared state.error_code::message(), error_condition::message(), error_category::message(): these return a string, so default allocator only.bitset's stream insertion operator notionally calls to_string with the default allocator, though no high-quality implementation would do that in practice.to_string and to_wstring free functions return std::string/std::wstring respectively; no chance to specify your own allocator. Obviously the user-defined literals for string (e.g., "foo"s) also have no custom allocator support.<locale> that have member functions returning either std::string or std::basic_string<charT>, i.e., using the default allocator (e.g., numpunct), or accepting only basic_string<charT> (e.g., money_get).<random> uses a vector with the default allocator.If anybody knows, what are the reasons for not providing allocator support in
any, and removing it fromfunction?
any's allocator support is unimplementable. function's allocator support is poorly specified and plagued with issues.