Project 4: A @safe String Class with unittests

Your own version of a dynamic string/array class. The internal implementation will use low-level, unsafe pointer arithmetic and manual memory management (@system code). However, the public API you expose will be marked @safe, providing a guaranteed memory-safe interface.

Quick Reference

Attribute Value
Primary Language D
Alternative Languages N/A
Difficulty Level 3: Advanced
Time Estimate 1-2 weeks
Knowledge Area Memory Management / Language Safety
Tooling D’s safety system
Prerequisites Familiarity with pointers from C/C++.

What You Will Build

Your own version of a dynamic string/array class. The internal implementation will use low-level, unsafe pointer arithmetic and manual memory management (@system code). However, the public API you expose will be marked @safe, providing a guaranteed memory-safe interface.

Why It Matters

This project builds core skills that appear repeatedly in real-world systems and tooling.

Core Challenges

  • Writing @system code → maps to using raw pointers, malloc/free, and disabling the GC for this module
  • Writing a @safe public API → maps to designing functions that can’t be used to corrupt memory
  • Using @trusted correctly → maps to creating functions that bridge the safe/system gap, promising the compiler that your unsafe implementation is actually safe
  • Integrating unittests → maps to proving that your safe API works as intended and that your unsafe implementation is correct

Key Concepts

  • Memory Safety in D: Dlang.org documentation on @safe.
  • Interfacing with C: The techniques for manual memory management are similar to C (core.stdc.stdlib.malloc).
  • Structs vs Classes: D has both. A struct is a value type, a class is a reference type. A dynamic array is best implemented as a struct.

Real-World Outcome

Deliver a working demo with observable output that proves the feature is correct.

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: LEARN_D_PROGRAMMING_LANGUAGE.md
  • “D programming Language” by Andrei Alexandrescu