Memory Management

RAII, ownership rules, no garbage collector, smart pointers, and lifetime patterns.

Core Principle: RAII

All resource management in sharp-runtime follows C++ RAII (Resource Acquisition Is Initialization): resources are acquired in constructors and released in destructors. When a value goes out of scope or a smart pointer's reference count drops to zero, its destructor runs automatically.

This differs fundamentally from .NET, where the garbage collector handles deallocation.

Ownership Rules

Immutable Collections

Immutable collection types use shared_ptr<const std::container<T>>:

// ImmutableArray<T> is backed by shared_ptr to const vector
auto arr = ImmutableArray<int>::Create({1, 2, 3});

No GC — Practical Consequences

• No cycles via naked pointers. Use std::weak_ptr to break ownership cycles.
• Object lifetime is deterministic. Destructors run immediately when scope exits.
• No finalizers. Use RAII destructors instead of ~Object() finalizers.
• IDisposable pattern: System::IDisposable exists but there is no using statement. Call Dispose() explicitly or use RAII wrappers.

Null Handling

C# references can be null; C++ pointers can be nullptr. In sharp-runtime code:

• Raw pointer parameters that can be null are typically const Object* — callers can pass nullptr.
• System::Nullable<T> (backed by std::optional) is used for nullable value types.
• Dereferencing a null pointer is undefined behaviour — no NullReferenceException is automatically thrown. Sharp-runtime may throw System::NullReferenceException where defensive checks exist.

Copy and Move Semantics

Most value types in sharp-runtime (structs, primitives) follow standard C++ copy/move semantics. Large types like System::Text::StringBuilder store an internal std::string buffer and support move construction and assignment.

Class types that inherit from System::Object typically have virtual destructors. They are generally heap-allocated and accessed via pointer or smart pointer.

Destructor and Cleanup Patterns

// Pattern 1: RAII — stack-allocated value type
{
    System::Text::StringBuilder sb;
    sb.Append("hello");
    // sb is destroyed when it goes out of scope
}

// Pattern 2: shared_ptr for heap-allocated Objects
auto stream = std::make_shared<System::IO::MemoryStream>();
stream->Write(buffer, 0, len);
// Destroyed when all shared_ptrs go out of scope

// Pattern 3: unique_ptr for exclusive ownership
auto reader = std::make_unique<System::IO::BinaryReader>(stream);
// Destroyed when reader goes out of scope

Differences from .NET / C# Behavior

Known Risks

• Dangling pointers when raw pointer observers outlive the owning object
• Double-free if ownership is transferred without clearing the source pointer
• Reference cycles via shared_ptr — use weak_ptr
• Use-after-free when passing raw this to background threads (fixed in Threading::Timer via shared_ptr<State>)