C++: Check if const Objects Are the Same at Compile-Time

struct Color {
  unsigned char r, g, b;

  // A standard, runtime operator==
  bool operator==(const Color& other) const {
    return r == other.r && g == other.g && b == other.b;
  }
};

const Color RED = {255, 0, 0};
const Color ALSO_RED = {255, 0, 0};

// static_assert(RED == ALSO_RED, "Colors must be the same!"); // ❌ Compilation Error!

This is the key. By making our operator== a constexpr function, we give the compiler permission to run it during compilation.

Building a Compile-Time Equality Checker: A Practical Example

Let's refactor our Color struct. The changes are minimal but incredibly powerful.

First, we need to ensure our type can be used in a constant expression. For a class type, this means it must be a "Literal Type". The rules are a bit detailed, but for a simple struct like ours, it's automatic as long as it has a constexpr constructor and all its non-static data members are public.

Since C++14, the rules for constexpr functions are much more relaxed, allowing for local variables, loops, and more. In C++20, it's even more powerful. For our purpose, the change is simple:

#include <cstdint>

struct Color {
  std::uint8_t r, g, b;

  // The magic ingredient: constexpr!
  constexpr bool operator==(const Color& other) const {
    return r == other.r && g == other.g && b == other.b;
  }
};

// Use constexpr for the objects to guarantee they are compile-time constants.
constexpr Color RED = {255, 0, 0};
constexpr Color ALSO_RED = {255, 0, 0};
constexpr Color BLUE = {0, 0, 255};

// Now this works!
static_assert(RED == ALSO_RED, "Red colors should be identical.");

// And this will correctly fail compilation, as intended.
// static_assert(RED == BLUE, "Red and Blue should not be identical.");

Success! The static_assert now compiles because the compiler can invoke the constexpr operator== with the constexpr objects RED and ALSO_RED, evaluate the result to true, and satisfy the assertion.

Handling More Complex Types

What about types that aren't as simple as Color? The main restriction for compile-time constants is that they cannot involve dynamic memory allocation in a way that persists past the constant evaluation.

This means types like std::string and std::vector, which use the heap, are generally off-limits for the members of your constexpr objects.

However, you can use their compile-time-friendly counterparts:

• Instead of std::string, use std::string_view (since C++17).
• Instead of std::vector, use std::array.

Let's look at a configuration struct using these types:

#include <string_view>
#include <array>
#include <algorithm> // for std::equal

struct DeviceConfig {
    std::string_view name;
    std::array<int, 4> pin_layout;

    constexpr bool operator==(const DeviceConfig& other) const {
        // std::string_view's operator== is already constexpr!
        // For std::array, we can use std::equal or a simple loop.
        return name == other.name && 
               std::equal(pin_layout.begin(), pin_layout.end(), other.pin_layout.begin());
    }
};

constexpr DeviceConfig SENSOR_A_CONFIG = {"temp_sensor", {1, 2, 3, 4}};
constexpr DeviceConfig SENSOR_A_DUPLICATE = {"temp_sensor", {1, 2, 3, 4}};
constexpr DeviceConfig SENSOR_B_CONFIG = {"humidity_sensor", {5, 6, 7, 8}};

static_assert(SENSOR_A_CONFIG == SENSOR_A_DUPLICATE, "Sensor A configs must match.");

Notice that std::string_view::operator== is already constexpr since C++17, and algorithms like std::equal are constexpr since C++20, making this kind of complex comparison increasingly straightforward.

C++20 and Beyond: consteval and std::is_constant_evaluated()

C++20 supercharged our compile-time capabilities with two new features:

1. consteval (Immediate Functions): If you mark a function as consteval instead of constexpr, you are guaranteeing that it must produce a compile-time constant. It can only be called during constant evaluation. This is a stronger contract than constexpr and can be useful for utility functions that only make sense at compile-time.
2. std::is_constant_evaluated(): This magical function returns true if it's being evaluated within a compile-time context and false otherwise. It lets you write a single constexpr function that can have different logic for compile-time and runtime execution. For instance, you could use a simple, efficient algorithm at compile-time and a more complex, optimized (e.g., SIMD) version at runtime.

// A function that MUST run at compile time.
consteval bool are_equal_immediate(const Color& c1, const Color& c2) {
    return c1 == c2;
}

// This is fine
static_assert(are_equal_immediate(RED, ALSO_RED));

// This would fail to compile because the call can't be evaluated at compile-time
// Color c1 = {1,1,1};
// bool result = are_equal_immediate(c1, RED); // ❌ Error!

Runtime vs. Compile-Time Checks: A Quick Comparison

To summarize the differences, here’s a handy table:

Feature	Runtime Check	Compile-Time Check
When it Executes	During program execution	During compilation
Error Detection	When the line of code is hit, possibly in production	Before the program is ever created; prevents bad builds
Performance Cost	Has a CPU cost (usually small, but non-zero)	Zero runtime cost; may increase compile times slightly
Applicable Data	Any data, including user input and dynamic values	Only `const`/`constexpr` data known at compile-time
Key C++ Features	if, assert(), standard operator==	static_assert, constexpr, consteval

Key Takeaways

Shifting correctness checks to the compiler is a hallmark of modern C++ development. For comparing const objects:

• Make your equality operator constexpr. This is the fundamental step that allows the compiler to perform the comparison.
• Ensure your objects are `constexpr`. The inputs to a compile-time evaluation must themselves be compile-time constants.
• Use compile-time friendly types like std::array and std::string_view for non-trivial members to avoid issues with dynamic memory.
• Use static_assert to enforce equality. This provides a hard guarantee that if the code compiles, the condition is met.
• Explore C++20's consteval for functions that should only ever run at compile-time.

By embracing these features, you can write code that is not only faster but also significantly safer and more robust, catching a whole class of bugs before they ever reach a user.