All Uninitialized-Memory Helpers

Construction into raw storage

• std::construct_at
• std::uninitialized_default_construct
• std::uninitialized_default_construct_n
• std::uninitialized_value_construct
• std::uninitialized_value_construct_n
• std::uninitialized_fill
• std::uninitialized_fill_n
• std::uninitialized_copy
• std::uninitialized_copy_n
• std::uninitialized_move
• std::uninitialized_move_n

Destruction helpers

• std::destroy_at
• std::destroy
• std::destroy_n

Allocation-adjacent helpers

• std::allocator_traits
• std::to_address
• placement new from <new>
• std::launder

Practical rules

• These utilities are mainly for container, allocator, and low-level library implementations.
• Prefer ordinary object construction unless you are deliberately managing raw storage.
• Keep exception safety explicit when partially constructed ranges are possible.

Small worked example

#include <memory>
#include <new>

int main() {
	alignas(int) unsigned char storage[sizeof(int)];
	int* value = std::construct_at(reinterpret_cast<int*>(storage), 42);
	int result = *value;
	std::destroy_at(value);
	return result;
}

This is the core raw-storage pattern: create an object in already allocated storage, use it, then destroy it explicitly. That is useful in container internals, allocator-backed buffers, and other low-level code that separates allocation from construction.

Decision guide

• use ordinary construction unless you are deliberately managing raw storage
• use construct_at and destroy_at for single-object lifetime management in preallocated memory
• use the uninitialized-copy, move, fill, and value/default-construct algorithms when building or relocating ranges in raw storage
• treat partial construction and rollback as a required part of the design, not an afterthought

Related pages

• Header reference: <memory>
• Header reference: <new>
• All allocator and PMR facilities