This issue aims to standardise comparison logic across the ULTRA codebase by adhering to C++ Core Guideline C.86. We need to move away from member-function comparisons and ensure all such operations are explicitly marked noexcept.
Why noexcept Matters
- Container compatibility. Many STL algorithms and containers provide stronger exception guarantees (or are simply more efficient) when the underlying type's move constructors and comparison operators are
noexcept.
- Logic predictability. A comparison is a fundamental query. If
a == b can throw, the program state becomes difficult to reason about during stack unwinding.
- Performance. The compiler can often generate more optimized instruction sequences for
noexcept functions as it doesn't need to maintain the exception handling personality table for that scope.
The Requirements
To satisfy C.86, every comparison operator (==, !=, <, >, <=, >=) must be:
- symmetric → defined as a non-member (usually a
friend inside the class) so that implicit conversions apply to both sides.
- non-throwing → explicitly marked with the
noexcept specifier.
This issue aims to standardise comparison logic across the ULTRA codebase by adhering to C++ Core Guideline C.86. We need to move away from member-function comparisons and ensure all such operations are explicitly marked
noexcept.Why noexcept Matters
noexcept.a == bcan throw, the program state becomes difficult to reason about during stack unwinding.noexceptfunctions as it doesn't need to maintain the exception handling personality table for that scope.The Requirements
To satisfy C.86, every comparison operator (
==,!=,<,>,<=,>=) must be:friendinside the class) so that implicit conversions apply to both sides.noexceptspecifier.