我正在尝试从 C++0x 草案中实现原子库。具体来说，我正在实施第 29.6/8 节，即store方法：
template <typename T>
void atomic<T>::store(T pDesired, memory_order pOrder = memory_order_seq_cst);
该要求指出：
order 参数不应是 memory_order_consume、memory_order_acquire 或 memory_order_acq_rel。
如果是其中之一，我不确定该怎么做。我应该什么都不做，抛出异常，获得未定义的行为，还是做其他事情？
PS：“C++0X”看起来有点像死鱼：3
做你想做的。没关系。
当 ISO 声明您“不应做某事”时，这样做是未定义的行为。如果用户这样做，他们就违反了与实施的合同，实施在其权利范围内为所欲为。
你决定做什么完全取决于你。我会选择任何让你的实现“更好”的东西（在你看来，更快、更易读、遵循最小惊讶原则等等）。
我自己，我会追求可读性（因为我必须保持这个东西），速度紧随其后。
我更喜欢编译时错误。如果不是这样，那么 assert() 失败。
Assert 很好，因为它是从发布版本编译出来的，不会影响性能。
编译时错误甚至更好，因为它们可以提供更即时的反馈，而无需等待软件发现错误。编译时错误检查是我喜欢 C++ 代码胜过 Python、Ruby、Perl 代码的地方。
我宁愿做出一些疯狂的模糊理智的行为。
好吧，作为您的库的潜在消费者，这就是我想要的：如果记录的使用没有性能成本，那么看看其中一个 memory_order 值是否提供了其他值的功能超集，特别是与调用者对应的东西可能会天真地期望不受支持的模式去做（如果可以形成任何合理的期望）。调用者可能会获得最慢、最安全的模式，但这总比功能错误要好。您可以最大限度地减少客户端代码对使所有内容都适合您的代码的依赖。与断言/异常相比，此问题的问题在于它在测试环境中可能被忽视，因此还考虑编写对 std::cerr 的解释，使用静态变量将消息限制为每个进程运行一个。这是一个非常有用的诊断。
异常、致命断言等可能会在非常不方便的时刻关闭客户端应用程序.... 似乎有点严厉，并不是我特别欣赏的东西。另一种选择是让环境变量控制这种行为。
（对于甚至不在您当前枚举中的值，可能存在类似的问题。）