The Modern C++ Solution: Non-Type Template Parameters

The magic key to unlocking compile-time identity verification is a feature enhanced in C++20: passing references to global objects as non-type template parameters (NTTPs).

Before C++20, you could only use pointers and references to objects with external linkage as NTTPs. C++20 relaxed this, allowing references to objects with internal linkage as well, which makes `inline` variables fair game.

Here's how it works. We can create a template that accepts the objects themselves by reference:

#include <type_traits>

// The magic happens here!
template<const auto& Lhs, const auto& Rhs>
consteval bool is_same_object() {
    // This comparison is done by the compiler.
    return &Lhs == &Rhs;
}

// Let's define two constants
namespace Constants {
    inline const int Alpha = 1;
    inline const int Beta = 2;
}

The template parameter `const auto& Lhs` captures a reference to a specific, unique object at compile-time. Because the function is `consteval`, it *must* be evaluated by the compiler. Inside, we can take the addresses of the referenced objects and compare them.

We can then use `static_assert` to enforce our identity contracts:

// This will compile successfully
static_assert(is_same_object<Constants::Alpha, Constants::Alpha>(), "Error: Expected the same object.");

// This will trigger a compile-time error, as intended!
// static_assert(is_same_object<Constants::Alpha, Constants::Beta>(), "Error: Expected the same object.");
// Compiler output: 
// error: static assertion failed: Error: Expected the same object.

This is incredibly powerful. We've moved a check from runtime to compile-time, eliminating a class of bugs entirely.

A Practical Example: A Type-Safe State Machine

Let's apply this to a more realistic scenario. Imagine a simple state machine where transitions are controlled by functions. We want to ensure that only the predefined state objects can be used.

// states.h
#include <string>

struct State {
    int id;
    std::string name;

    // States must be non-movable and non-copyable to have a stable identity
    State(const State&) = delete;
    State& operator=(const State&) = delete;
};

namespace States {
    inline const State IDLE{0, "Idle"};
    inline const State RUNNING{1, "Running"};
    inline const State STOPPED{2, "Stopped"};
}

// Our verification helper from before
template<const auto& Lhs, const auto& Rhs>
consteval bool is_same_object() { return &Lhs == &Rhs; }

Now, we can create a template function that performs an action, but only if it's being used with a specific, known state object.

#include "states.h"
#include <iostream>

// A generic function to enter a state
template<const auto& TargetState>
void enter_state() {
    // Enforce that we can only enter the RUNNING state with this function
    static_assert(is_same_object<TargetState, States::RUNNING>(),
                  "This function can only be used to enter the RUNNING state.");

    std::cout << "Entering state: " << TargetState.name << std::endl;
}

int main() {
    // This is valid and will compile
    enter_state<States::RUNNING>();

    // This will cause a compile-time error!
    // enter_state<States::IDLE>();
    /*
    * Compiler error:
    * error: static assertion failed: "This function can only be used to enter the RUNNING state."
    * static_assert(is_same_object<TargetState, States::RUNNING>(), ...
    */
}

Without this compile-time check, we would need a runtime `if` or `switch` inside `enter_state` to validate the state, adding overhead and clutter. The `static_assert` makes the function's contract part of the compilation process.

Method Comparison: Runtime vs. Compile-Time

Here's a quick breakdown of the different approaches:

Putting It All Together: A Reusable Verification Helper

Our `is_same_object()` function is great, but for a library, we can make it even more idiomatic using a `std::bool_constant` wrapper. This makes it play nicely with other template metaprogramming utilities.

#include <type_traits>

// C++20 struct-based helper
template<const auto& Lhs, const auto& Rhs>
struct is_same_instance : std::bool_constant<&Lhs == &Rhs> {};

// C++20 variable template for convenience
template<const auto& Lhs, const auto& Rhs>
inlined constexpr bool is_same_instance_v = is_same_instance<Lhs, Rhs>::value;

This is clean, reusable, and follows standard library conventions. Your `static_assert`s become even more readable:

static_assert(is_same_instance_v<States::RUNNING, States::RUNNING>);

static_assert(!is_same_instance_v<States::RUNNING, States::IDLE>);

Limitations and Considerations

While powerful, this technique has a few key requirements:

1. Static Storage Duration: The objects you pass as template arguments must have static storage duration (e.g., global variables, `static` member variables) or thread-local storage duration. You cannot pass a reference to a local variable on the stack.
2. Linkage: The objects must have external or internal linkage. `inline` variables work perfectly.
3. Linker Shenanigans: Be aware that linkers can sometimes merge identical constants to save space (COMDAT folding). This could, in theory, cause `&obj1 == &obj2` to be true for two `inline` variables defined in different translation units that you intended to be different. However, the `static_assert` using NTTPs is about enforcing which *variable name* you're allowed to use in the source code, which generally protects you from this ambiguity in practice.

Key Takeaways

Moving checks from runtime to compile-time is a hallmark of modern C++ development. For verifying object identity, remember:

• Value is not Identity: `a == b` doesn't mean `&a == &b`. Relying on value equality when identity is required is a source of bugs.
• Use C++20 NTTPs: Passing object references via `const auto&` template parameters is the key to performing identity checks at compile-time.
• Enforce Contracts with `static_assert`: Use `static_assert` to make identity requirements a non-negotiable part of your API, providing immediate feedback to developers.
• Build Safer Systems: This technique is perfect for state machines, configuration management, and any system using canonical objects where correctness is critical.

Next time you find yourself writing a runtime pointer comparison for a global constant, ask yourself: can the compiler do this for me? With modern C++, the answer is very likely yes.