# Appendix B: coming from other languages

This appendix maps what you already know from C, Rust, Lisp, and Prolog onto the C++ you have now read. It is one page per language, and it uses the vocabulary of the chapter each idea belongs to.

## From C

| You know | In C++ this is |
|----------|----------------|
| `char*` strings with a NUL terminator | `std::string` when owned, `std::string_view` when borrowed (ch10) |
| Arrays that decay to pointers | `std::array`, `std::span`, `std::vector` (ch11) |
| `FILE*` and manual `fclose` | an RAII wrapper whose destructor releases the handle (ch05, ch28) |
| `errno` and sentinel returns | `std::expected` and exceptions (ch09, ch28) |
| `printf` with unchecked format strings | `std::format` and `std::println`, checked at compile time (ch10) |
| `qsort` with `void*` and a function pointer | `std::ranges::sort` with a comparator and projection (ch12) |
| Manual `malloc`/`free` | `std::unique_ptr`, `std::vector`, and the Rule of Zero (ch05, ch06) |

C code works in C++ through the boundary discipline of chapter 28: `extern "C"` for linkage, spans and string views for C data, and RAII wrappers for C resources.

C++ retains C calling conventions, adds ownership, and replaces manual resource handling and unchecked formatting with RAII and compile‑time checked formatting.

## From Rust

| You know | In C++ this is |
|----------|----------------|
| Value semantics | value semantics, move semantics, and copy elision (ch05, ch29) |
| Ownership | a name owns a value. Ownership transfers on move (ch05) |
| The borrow checker | the lifetime-safety profile, `std::span`, `std::string_view`, and `-Wlifetime-safety` (ch07) |
| `Option<T>` | `std::optional` (ch03) |
| `Result<T, E>` | `std::expected` (ch03, ch09) |
| Enums with data | `std::variant` plus `std::visit` (ch03) |
| Traits | concepts and `requires` clauses (ch17) |

Rust enforces ownership and lifetimes at compile time. C++ provides the same tools but relies on the lifetime‑safety analysis and disciplined APIs (see Chapter 7).

Both languages share the same mental model of ownership. The difference is where a violation is caught.

## From Lisp

| You know | In C++ this is |
|----------|----------------|
| Macros that expand source | templates, which rewrite type patterns and are instantiated at compile time (ch16) |
| Compile-time evaluation | `constexpr`, `consteval`, and the compile-time execution model (ch18) |
| A domain-specific language evaluated at compile time | the constexpr SQL capstone (ch22) |
| Functions as data | lambdas, `std::function`, and type erasure (ch14) |
| Recursive macros / term rewriting | template metaprogramming and pack expansion (ch16, ch21) |

C++ templates and constexpr supply compile‑time code generation analogous to Lisp macros.

Lisp rewrites source text. C++ rewrites type patterns and evaluates a restricted subset of the language at compile time.

## From Prolog

| You know | In C++ this is |
|----------|----------------|
| Unification | template argument deduction, which binds type parameters to concrete types (ch16) |
| Goal ordering / most specific rule | overload resolution and concept subsumption (ch17) |
| A term with a tag and arguments | `std::variant` plus `std::visit` (ch03) |
| Backtracking search | Not in the language. Express it explicitly with recursion or a search loop |

The strongest analogy is deduction: Prolog unifies a query against rules, and C++ unifies a call against template patterns and selects the most specific viable match. Chapter 17 frames concept subsumption in exactly these terms.

The difference is control. Prolog searches for a solution and can backtrack. C++ resolves a call once at compile time and does not search at runtime. The shared idea is pattern matching against a set of rules, with the most specific rule winning.