Orthodox Cpp

1. C-first readability.

   • Start from clear C-like design and add C++ features only when they reduce complexity.
   • Keep code understandable to engineers comfortable with C and systems-level debugging.

2. Explicit runtime and memory costs.

   • Make allocation, ownership, and lifetime visible in APIs.
   • Avoid abstractions that hide control flow or heap behavior.

3. Portability and toolchain pragmatism.

   • Prefer mature, widely supported language features.
   • Follow selective adoption discipline for new standards (+5-year maturity bias).

4. Exceptions and RTTI are out of scope.

   • Avoid exception-based control flow and RTTI-driven architecture.
   • Keep error handling explicit and local in call signatures/results.

5. Template use must stay practical.

   • Use templates when they remove duplication with obvious generated behavior.
   • Avoid metaprogramming complexity that harms compile times and debuggability.

6. Prefer simple composition over deep hierarchy.

   • Use plain structs/classes and free functions where possible.
   • Avoid inheritance trees and polymorphism without clear measurable value.

Language-Specific Patterns

C++

• Prefer straightforward value types and explicit ownership boundaries.
• Prefer C headers and plain runtime APIs when they improve portability and integration (<stdio.h> style is acceptable in this skill context).
• Prefer explicit error channels (status codes, result objects, expected-like wrappers) over thrown exceptions.
• Keep RAII focused on narrow, obvious scope-bound resource cleanup.
• Restrict STL usage in hot paths when allocator behavior is not explicitly controlled.
• Avoid iostream-heavy formatting in performance-sensitive paths; use simpler explicit formatting/output paths.
• Isolate platform/compiler-specific code behind thin boundary modules.

Mandatory Rules for the Agent

• Keep language usage within a conservative, portable subset unless a newer feature has a clear, documented benefit and mature toolchain support.
• Do not introduce exceptions for ordinary flow or expected failures.
• Do not introduce RTTI-driven behavior (dynamic_cast, typeid) in core design.
• Keep allocation and ownership explicit at module boundaries.
• Keep template usage simple, local, and reviewable.
• Keep constructors/destructors free from hidden heavy work and non-obvious side effects.
• Keep dependency surfaces small with minimal includes and explicit boundaries.
• Keep global mutable state and singleton patterns out of core logic unless unavoidable and documented.
• Keep portability constraints explicit whenever compiler/platform-specific behavior is required.

Anti-Patterns (Must Avoid)

• Resume-driven feature adoption (using new C++ features only for trend alignment).
• Exception-heavy architecture for expected failure paths.
• RTTI-based dispatch as the default polymorphism strategy.
• Deep inheritance trees replacing clear composition.
• Template metaprogramming that obscures behavior and slows iteration.
• Hidden allocations in critical loops without ownership/performance justification.
• Framework-style abstractions that hide runtime control flow and data movement.
• Overuse of heavyweight STL containers where allocator/control requirements are strict.

Execution Workflow

1. Confirm module constraints: platform targets, compiler matrix, runtime budget, and debug requirements.
2. Define the allowed C++ subset for the module and record any non-default allowances.
3. Design data layout and ownership boundaries before implementation.
4. Implement explicit error flow and keep control flow branch-visible.
5. Add C++ features selectively only when they reduce complexity and remain toolchain-portable.
6. Review templates, allocation points, and polymorphism for simplicity and runtime transparency.
7. Validate portability assumptions across supported compilers/platforms.
8. Add tests for success/failure paths and boundary behavior.
9. Document any deviations from Orthodox C++ rules with measurable rationale.

PR/Review Checklist

• Is the implementation readable to C-familiar engineers without hidden language tricks?
• Are allocation, ownership, and lifetime decisions explicit and reviewable?
• Are exceptions and RTTI absent from normal architecture flow?
• Is template usage minimal and understandable?
• Are constructors/destructors free of hidden heavy work?
• Are portability and compiler assumptions explicit and justified?
• Are abstraction layers justified by measurable complexity reduction?
• Are deviations from conservative subset rules documented with trade-offs?

Output Format Expectations for the Agent

When proposing or implementing changes, include:

1. Module constraints (platforms, compilers, runtime goals)
2. Allowed C++ subset decisions for this change
3. Error-handling strategy (explicit, non-exception flow)
4. Ownership/allocation model and key lifetimes
5. Template/polymorphism usage rationale
6. Portability assumptions and validation notes
7. Any Orthodox-rule deviations and measurable justification

Source Orientation

This skill is aligned with Orthodox C++ (C+) direction popularized by Branimir Karadzic (bgfx), emphasizing simplicity, portability, and explicit costs over novelty-driven language usage.