关于前提条件memcmp产生与成员方面的比较相同的结果==，虽然这个前提在实践中经常得到满足，但有点brittle.
理论上，更改编译器或编译器选项可以打破该前提条件。更值得关注的是，代码维护（所有编程工作的 80% 都是维护，IIRC）可以通过添加或删除成员、使类多态、添加自定义来破坏它==正如评论之一中提到的，前提条件可以适用于静态变量，但不适用于自动变量，然后创建非静态对象的维护工作可以做坏事™。
以及关于是否使用的问题memcmp或会员方面==实施一项==对于类的运算符，首先，这是一个错误的二分法，因为那些不是唯一的选择。
例如，它可以减少工作量并且使用起来更易于维护自动生成关系运算符重载，就compare功能。这std::string::comparefunction 是此类函数的一个示例。
其次，选择哪种实现的答案在很大程度上取决于您认为重要的内容，例如：
是否应该寻求最大化运行时效率, or
人们是否应该寻求创造最清晰的代码, or
如果人们寻求最简洁的，写得最快代码，或
应该努力让班级成为最safe使用，或
也许是别的什么？
生成关系运算符。
您可能听说过 CRTP，奇怪的重复模板模式。我记得它是为了满足生成关系运算符重载的要求而发明的。不过，我可能会把它与其他东西混为一谈，但无论如何：
template< class Derived >
struct Relops_from_compare
{
friend
auto operator!=( const Derived& a, const Derived& b )
-> bool
{ return compare( a, b ) != 0; }
friend
auto operator<( const Derived& a, const Derived& b )
-> bool
{ return compare( a, b ) < 0; }
friend
auto operator<=( const Derived& a, const Derived& b )
-> bool
{ return compare( a, b ) <= 0; }
friend
auto operator==( const Derived& a, const Derived& b )
-> bool
{ return compare( a, b ) == 0; }
friend
auto operator>=( const Derived& a, const Derived& b )
-> bool
{ return compare( a, b ) >= 0; }
friend
auto operator>( const Derived& a, const Derived& b )
-> bool
{ return compare( a, b ) > 0; }
};
鉴于上述支持，我们可以调查您的问题可用的选项。
实现A：减法比较。
这是一个提供全套关系运算符的类，但不使用任何一个memcmp or ==:
struct Vector
: Relops_from_compare< Vector >
{
int x, y, z;
// This implementation assumes no overflow occurs.
friend
auto compare( const Vector& a, const Vector& b )
-> int
{
if( const auto r = a.x - b.x ) { return r; }
if( const auto r = a.y - b.y ) { return r; }
return a.z - b.z;
}
Vector( const int _x, const int _y, const int _z )
: x( _x ), y( _y ), z( _z )
{}
};
实施B：比较通过memcmp.
这是使用相同的类实现的memcmp;我想您会同意这段代码的扩展性更好并且更简单：
struct Vector
: Relops_from_compare< Vector >
{
int x, y, z;
// This implementation requires that there is no padding.
// Also, it doesn't deal with negative numbers for < or >.
friend
auto compare( const Vector& a, const Vector& b )
-> int
{
static_assert( sizeof( Vector ) == 3*sizeof( x ), "!" );
return memcmp( &a, &b, sizeof( Vector ) );
}
Vector( const int _x, const int _y, const int _z )
: x( _x ), y( _y ), z( _z )
{}
};
实施C：逐个成员进行比较。
这是使用成员比较的实现。它没有强加任何特殊要求或假设。但它更多的是源代码。
struct Vector
: Relops_from_compare< Vector >
{
int x, y, z;
friend
auto compare( const Vector& a, const Vector& b )
-> int
{
if( a.x < b.x ) { return -1; }
if( a.x > b.x ) { return +1; }
if( a.y < b.y ) { return -1; }
if( a.y > b.y ) { return +1; }
if( a.z < b.z ) { return -1; }
if( a.z > b.z ) { return +1; }
return 0;
}
Vector( const int _x, const int _y, const int _z )
: x( _x ), y( _y ), z( _z )
{}
};
实施D：compare就关系运算符而言。
这是一种颠倒事物自然顺序的实现，通过实现compare按照< and ==，直接提供并根据std::tuple比较（使用std::tie).
struct Vector
{
int x, y, z;
friend
auto operator<( const Vector& a, const Vector& b )
-> bool
{
using std::tie;
return tie( a.x, a.y, a.z ) < tie( b.x, b.y, b.z );
}
friend
auto operator==( const Vector& a, const Vector& b )
-> bool
{
using std::tie;
return tie( a.x, a.y, a.z ) == tie( b.x, b.y, b.z );
}
friend
auto compare( const Vector& a, const Vector& b )
-> int
{
return (a < b? -1 : a == b? 0 : +1);
}
Vector( const int _x, const int _y, const int _z )
: x( _x ), y( _y ), z( _z )
{}
};
如所给出的，客户端代码使用例如>需要一个using namespace std::rel_ops;.
替代方案包括将所有其他运算符添加到上面（更多代码），或者使用 CRTP 运算符生成方案来实现其他运算符：< and =（可能效率低下）。
实施E：手动使用的比较< and ==.
这个实现是不应用任何抽象的结果，只是敲击键盘并直接写出机器应该做什么：
struct Vector
{
int x, y, z;
friend
auto operator<( const Vector& a, const Vector& b )
-> bool
{
return (
a.x < b.x ||
a.x == b.x && (
a.y < b.y ||
a.y == b.y && (
a.z < b.z
)
)
);
}
friend
auto operator==( const Vector& a, const Vector& b )
-> bool
{
return
a.x == b.x &&
a.y == b.y &&
a.z == b.z;
}
friend
auto compare( const Vector& a, const Vector& b )
-> int
{
return (a < b? -1 : a == b? 0 : +1);
}
Vector( const int _x, const int _y, const int _z )
: x( _x ), y( _y ), z( _z )
{}
};
选择什么。
考虑最有价值的可能方面的列表，例如安全性、清晰度、效率、简短性，评估上述每种方法。
然后选择对您来说明显最好的一种方法，或者看起来同样最好的方法之一。
指导：为了安全起见，您不希望选择方法 A（减法），因为它依赖于对值的假设。请注意，还有选项 B，memcmp，作为一般情况的实现是不安全的，但可以很好地实现== and !=。为了效率你应该更好MEASURE，以及相关的编译器选项和环境，并记住 Donald Knuth 的格言：“过早的优化是万恶之源”（即花时间在这可能会适得其反）。
