C ++标准库中是否有任何函数或类可以保证不执行动态内存分配？

Question

There are contexts in which we want our C++ code to not perform dynamic memory allocation ('on the heap'), specifically in some embedded development use cases.

There are standard library classes which can be implemented without dynamic memory allocation: optional, array, tuple, variant to name a few. The same is true for standard library free functions.

Are there any such classes or functions which are guaranteed by the standard to not allocate memory dynamically? The only functions I could find with such a guarantee are the placement new() functions.

Answer 1

There are very few cases if any where the C++ standard makes any direct guarantee about not using dynamic memory.

On systems where dynamic memory allocation is signal-unsafe, you can be certain that all functions listed as signal-safe are non-allocating. The standard mentions

_Exit
abort
forward
initializer_list functions
memcpy
memmove
move
move_if_noexcept
numeric_limits members
quick_exit
signal
type traits
plain lock-free atomic operations

If you can assume conformance to another standard, POSIX, then it lists more functions that are async-signal-safe . Some of these functions listed by POSIX are provided by C++ (and C) standards as well (such as strcat ), and therefore those standard C++ functions will be signal safe on all POSIX systems.

There are a few functions in [new.delete.placement], which are non-allocating by definition.

---

Another question separate from guarantees is, whether a reasonable implementation of a function or a type would not allocate. Many, many things such as std::tuple and std::array (with non-allocating type arguments naturally) fall into this category.

It would be reasonable that functions which are declared noexcept , and do not have any failure path (like setting error code, returning error indicating value, or terminating the process) shouldn't allocate, since allocation may throw.

Conversely, there are functions that in a reasonable implementation do allocate dynamic memory. Obviously those that involve allocators, as well as those listed in the SO post that you linked. One non-obvious one that often bites people writing signal handlers is missing from the list: It is not at all reasonable to expect printf or any of its related functions to not allocate.