实现原子<t> :: store </t>

Question

我正在尝试从C ++ 0x草案中实现原子库。具体来说，我正在实施§29.6/ 8，商店方法：

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。

如果是其中之一，我不知道该怎么做。我应该什么都不做，抛出异常，获取未定义的行为，或做其他事情？

_{P.S。：“C ++ 0X”看起来有点像死鱼：3}

Answer 1

做你想做的。没关系。

当ISO声明您“不应该做某事”时，这样做是未定义的行为。如果用户这样做，他们违反了与实施的合同，并且实施权利随意进行。

你决定做什么完全取决于你。我会选择任何使你的实现“更好”的东西（在你看来，更快，更可读，受最不惊讶的原则，等等）。

我自己，为了便于阅读（因为我必须保持这个东西），速度快一点。

Answer 2

我宁愿得到模糊的理智行为，这是疯狂的事情。

好吧，作为您图书馆的潜在消费者，这就是我想要的：如果记录的用法没有性能成本，那么看看其中一个memory_order值是否提供了其他值的功能超集，特别是对应于调用者可能天真地期望不支持的模式可以做什么（如果可以形成任何合理的期望）。调用者可能会获得最慢，最安全的模式，但这比功能错误更好。您可以最大限度地减少客户端代码对于使代码完美无缺的依赖性。与断言/异常相比，它的问题在于它可以在测试环境中被忽视，因此还要考虑向std :: cerr写一个解释，使用静态变量将消息限制为每个进程运行一个。这是一个非常有用的诊断。

异常，致命的断言等可能会在一个非常不方便的时刻打倒客户端应用程序......看起来有点严苛，而不是我特别欣赏的东西。另一种选择是让环境变量控制这种行为。

（对于那些在您当前的枚举中甚至没有的值，可能存在类似的问题。）

Answer 3

我更喜欢编译时错误。如果不是这样，那么断言（）失败。

断言很好，因为它会从发布版本中编译出来，不会影响性能。

编译时间错误甚至更好，因为它们可以提供更直接的反馈，而无需等待软件跳过错误。编译时错误检查是我喜欢的关于Python，Ruby，Perl代码的C ++代码。