Yesterday on the cpplang Slack,
someone asked the purpose of std::has_unique_object_representations_v<T>,
and someone else pointed to an example given in
Steve Dewhurst’s “Back to Basics: Class Layout” (2020).
Sadly, that example is incorrect. Let’s take a look.

Authored by Arthur O'Dwyer, Quuxplusone offers  explorations of C++ programming language features, standard library design, and modern C++ development practices. Readers can delve into advanced topics such as template metaprogramming, design patterns, and effective use of language features. Additionally, they can learn about best practices for writing efficient and maintainable C++ code, optimizing performance, and leveraging the latest language standards.

Arthur O'Dwyer

The C++ type trait `has_unique_object_representations` is fundamentally flawed and shouldn't be used to determine if a type is trivially equality-comparable. While it correctly rejects types with padding or non-trivial representations, it produces false positives (like `optional<char>` and `polymorphic_allocator`) by ignoring comparison semantics, and false negatives (like `exception_ptr`) by requiring trivial copyability. The compiler intrinsic `__is_trivially_equality_comparable` is the correct tool for this purpose. Defaulting comparison operators is always preferable to hand-written memcmp implementations, as it enables better compiler optimizations and type-trait detection.

has_unique_object_representations versus __is_trivially_equality_comparable

Okay, but has_unique_object_representations …?

1. libc++’s optional<char> (false positive)

3. pmr::polymorphic_allocator<int> (false positive)

5. libstdc++’s exception_ptr (false negative)