In C++ systems programming, all data lives in a flat, addressable virtual memory space managed by the Operating System ( with page tables, virtual-to-physical translation and protection rings). Every object occupies a contiguous region of bytes with a starting address. The compiler and runtime do not track „ownership“ or „lifetime“ automatically at the language level; that responsibility is yours. This is deliberate: it gives the performance and predictability required for real-time control loops, telemetry packet processing, satelite flight software and high-frequency trading kernels. The price is that the language will happily let you read or write arbitrary memory if you ask it to.

Pointers, references, arrays and strings are memory access and ownership primitives rather than surface syntax features. In C++ these constructs define how data is laid out, accessed and reasoned about under the hood.

Pointers

A pointer is a variable whose value is the address ( integral type large enough to hold any valid address on the platform ) of another object or function. It is not the object itself; it is an opaque handle to a location in memory!

Memory is a linear address space. A pointer is simply a value - typically 8 bytes on a 64-bit systems that holds an address.

The operator „*“ is used on pointers and gives us the ability to use the pointer as the value it is currently pointing at. It is called dereference – go to address – read value. When you dereference a pointer, the CPU takes that integer, puts it on the address bus and fetches the data at that location.

How it works internally

• On a 64 bit systems a pointer is 8 bytes.
• The compiler emits load/store instructions relative to that address.
• Pointer arithmetic is scaled by sizeof(T) : p + n + sizeof(T) in address space.
• Dereference ( *p ) is a memory indirection.

Raw pointers carry no lifetime, type or bounds metadata; the compiler trusts you completely.

Why it exists

Pointers provide the ability to manipulate memory directly without copying data. In high-performance systems ( like space telemetry processing – for example ), copying a large buffer of sensor data is an O(n) operation that wastes CPU cycles and power. Passing a pointer is O(1).

Pointers are the primitive for indirection, aliasing and dynamic lifetime management. Without them you cannot implement dynamic allocation, shared-memory IPC, hardware register access, intrusive data structure or zero-copy buffer passing – all fundamental to systems and real-time software.

Trade-offs

Cons: No lifetime tracking by the language. The compiler cannot prove validity, aliasing rules that inhabit optmizations and the possibility of every classic memory error. Raw pointers do not compose safely with exceptions or RAII unless wrapped.

We can summary by:

• Zero overhead abstractions ( maps directly to hardware ).
• Full control over memory.
• Enables complex structures.
• Unsafe ( dangling pointers, null reference ).
• No ownership semantics by default.
• Hard to reason about in large systems.
• Manual lifecycle management.
  

Real-world usage

In satellite flight software ( e.g. NASA cFS or ESA on-board software ) raw pointers are used for memory-mapped device registers and for passing telemetry buffers between tasks without copying. In high-frequency trading or real-time distributed control systems they enable lock-free ring buffers and zero-copy serialization across network or shared-memory transports. In the Linux kernel and many embedded hypervisors they are the only practical way to manage page tables and IOMMU mappings.

References

A reference ( T& or T&& ) is an alias for an existing object. It is not a separate object; it has no storage of its own in the generated code. It must always refer to a valid object. Once initialized, it cannot be changed to refer to a different object.

Every change and manipulation on the reference is a direct change and manipulation on the object the reference is alias of.

How it works internally

Under the hood, most compilers implement references as const pointers that are automacally dereferenced by the compiler. Unlike a pointer, a reference cannot be null and does not have its own address in the same way a pointer variable does. It shares the identity of the referent.

Why it exists

References provide the performance benefits of pointers with the syntactic sugar and safety of values. They prevent „pointer arithmetic“ mistakes and ensure that a function receives a valid object rather than a null address.

They are the foundation of modern C++ value-category system and move semantics.

Trade-offs

Pros: cannot be null, cannot be reseated, clearer intent for „out“ parameters, zero runtime cost when elided.

Cons: cannot represent „no object“, cannot be stored in arrays of standard containers without std::reference_wrapper, and reference members make classes non-movable by default unless std::move is use carefully

Failure cases

• Binding a reference to a temporary that is destroyed at the end of the full-expression.
• Reference to a member of a destroyed object when the containing object is stack-allocated and goes out of scope.
• Misunderstanding T&& as „always rvalue“ ( universal reference in templates is T&& but deduces to lvalue reference when T is an lvalue).

A reference is a guaranteed valid pointer that you do not see.

Arrays

An array is a contiguous block of memory holding multiple elements of the same type. A data structure that we access by position. They have fixed size and we cannot add elements to an array. In most value contexts an array decays to a pointer to its first element.

We cannot initialize an array as a copy of another array.

How it works internally

Because elements are contigious, the address of any element i is calculated via:

Address = BaseAddress + ( i x SizeOfEelemtn )

This allows for O(1) random access, which is critical for real-time control systems where latency must be deterministic. The key rule is arr[i] == * ( arr + i ).

Why it exists

Arrays are the most cache-friendly data structure. Because the CPU fetches memory in „cache lines“, accessing arr[0] often pulls arr[1] throught arr[7] into the L1 cache simultaneously, drastically reducing memory latency.

Trade-offs

Pros: Perfect spatial locality, no heap allocation, compile-time size knowledge when using std::array.

Cons: Fixed size at compile time ( C-style ), decay loses size information ( the single most commong source of buffer overruns ), cannot be returned or assigned by value.

Failure cases

• Off-by-one indexing ( undefined behaviour ).
• Decay causing loss of size information ( sizeof on parameter yields pointer size ).
• Stack overflow when declaring large automatic arrays.
• Passing array to function expecting pointer and forgetting bounds.

Let me give you the following declarations on a 64-bit system:

int arr [ 10 ];

int* ptr = arr;

I want to briefly explain the results of sizeof(arr) and sizeof(ptr). In the array example sizeof(arr) will show us the total size of the array. Or in the current example 40 since we multiple 10 by the size of int. When we perform sizeof(ptr) it will print the size of the pointer itself, ignoring the idea that the point is pointing to the array. So in this case 8 bytes.

Strings

A string is a sequence of characters. C++ provides two models:

• C-style: const char* or char[N] – null terminated sequence of char.
• Std::string ( and std::string_view since C++17 ): object owning or viewing a contiguous sequence plus an explici size.

C-style strings are not a type! The characters are storred in an array with the last character being a null character ( `\0` ). This character marks the end.

When we manipulate or care about strings we must remember that C-style strings are arrays and therefore working with them may give unexpected outcomes. For example – comparing strings.

How it works internally

Functions rely on this arrays to determine length.

Why it exists

In resource-constrained environment ( like onboard computer on a satelite ), you often avoid std::string because it performs non-deterministic heap allocations. Instead, you use fixed-size char buffers to ensure the system never runs out of memory unexpectedly.

Failure cases & pitfalls

• Buffer overflows: Writing to arr[10] when the array size is 10. In C++, the compiler will not stop you; you simply corrupt the adjacent memory.
• The „Decay“ problem: When you pass an array to a function, it „decays“ into a pointer. The function no longer knows how big the array is.
• Pointer aliasing: Two pointers pointing to the same memory. If you update one, the other changes. In high-performance math ( DSP ), this prevents the compiler from optimizing loops because it fears the data might change unexpectedly.