How do their APIs compare?

These two projects aren't really comparable as "APIs" in the same sense — they operate at completely different layers and serve entirely different purposes.

gaoxiang12/slambook is not a library with a stable public API at all. It's a collection of standalone, chapter-by-chapter educational C++ example programs accompanying the book "14 Lectures on Visual SLAM." Each chapter (ch2–ch13, plus project) is essentially its own small executable demonstrating a SLAM concept:

• ch12 (loop closure) directly drives third-party libraries like OpenCV and DBoW3 in main()-style procedural code — e.g. detecting ORB features, building a DBoW3::BowVector, scoring image similarity, and querying a DBoW3::Database [ch12/loop_closure.cpp:L36-L75, L71-L77].
• ch7 (feature-based visual odometry) similarly calls OpenCV's Feature2D/BFMatcher APIs directly to detect and match ORB features [ch7/feature_extraction.cpp:L36-L75].
• ch10 bundles a vendored/modified copy of Google's Ceres Solver headers (e.g. autodiff.h, fixed_array.h, manual_constructor.h) used internally for bundle adjustment — these are Ceres's own APIs (like AutoDiff::Differentiate) rather than anything slambook defines itself [ch10/g2o_custombundle/ceres/autodiff.h:L1-L40, L71-L110; ch10/g2o_custombundle/ceres/fixed_array.h:L36-L75].
• There's no consistent "slambook API" — each .cpp is a standalone demo wiring together OpenCV, Ceres, g2o, Sophus, DBoW3, etc.

v8/v8, in contrast, is a production JS/WASM engine with a deliberately designed, versioned, header-based embedder API (include/v8*.h, implemented in src/api/api.cc and src/api/api-inl.h). This API is built around explicit safety and lifetime rules:

• Handle/scope management is strict and asserted, e.g. HandleScope::DoInitializeAsserts checks that the Locker was used correctly before entering the API [src/api/api.cc:L689-L701 region, "HandleScope::DoInitializeAsserts"], and internal scopes like EnterV8InternalScope wrap every API entry point with call-depth and runtime-call-stats tracking [src/api/api-inl.h:L246-L285].
• Public API surface like FunctionTemplate::New and FunctionTemplate::NewWithCFunctionOverloads enforce invariants at the API boundary — e.g. rejecting fast API (CFunction) callbacks combined with constructor behavior, and validating instance-type ranges via Utils::ApiCheck [src/api/api.cc:L1226-L1265, L1261-L1300].
• Failure modes are explicit and checked rather than silent: FromJustIsNothing() and ToLocalEmpty() are dedicated abort paths hit when embedders misuse Maybe/MaybeLocal [src/api/api.cc:L736-L746].
• Internally, V8's API layer also touches very low-level concerns like CPU feature detection via inline cpuid assembly [src/base/cpu/cpu-x86.cc:L36-L75], and typed-array/C++ buffer conversion helpers with strict type/length checks [src/api/api-inl.h:L456-L495].

Summary of the contrast:

• slambook has no formal API contract, no versioning, and no runtime safety checks — it's example code meant to be read, compiled once, and modified by learners.
• v8 has a hardened, checked, backward-compatibility-conscious C++ embedder API with runtime assertions (ApiCheck, DCHECK), scoped resource management, and explicit error/fallback paths designed for long-term external embedders (Chrome, Node.js, etc.) to depend on safely.

This asymmetry is also reflected in the RepoPilot verdict for slambook: WAIT — Stale, last commit 2 years ago, meaning even if you wanted to treat its patterns as an "API" to depend on, the project itself signals it isn't actively maintained (the README even redirects users to slambook2). No comparable sta