Implementing atomic<T>::store

I'm attempting to implement the atomic library from the C++0x draft. Specifically, I'm implementing §29.6/8, the store method:

template <typename T>
void atomic<T>::store(T pDesired, memory_order pOrder = memory_order_seq_cst);

The requirement states:

The order argument shall not be memory_order_consume, memory_order_acquire, nor memory_order_acq_rel.

I'm not sure what to do if it is one of these. Should I do nothing, throw an exception, get undefined behavior, or do something else?

_{P.S.:开发者_如何学运维 "C++0X" looks kinda like a dead fish :3}

Do what you want. It doesn't matter.

When ISO state that you "shall not do something", doing it is undefined behaviour. If a user does that, they have violated the contract with the implementation, and the implementation is within its rights to do as it pleases.

What you decide to do is entirely up to you. I would opt for whatever makes your implementation "better" (in your eyes, be that faster, more readable, subject to the principle of least astonishment, and so forth).

Myself, I'd go for readability (since I would have to maintain the thing) with speed taking a close second.

I prefer a compile time error. If not that, then an assert() failure.

Assert is good because it compiles out of the release version and will not impact performance.

Compile time errors are even better because they provide more immediate feedback without waiting for the software to trip over the bug. Compile time error checks are a thing I love about C++ code over Python, Ruby, Perl code.

I'd rather get vaguey sane behaviour that something crazy.

Well, as a potential consumer of your library, here's what I'd like: if there's no performance cost to the documented usage, then see if one of the memory_order values provides a functional superset of the others, particularly something corresponding to what a caller might naively expect the unsupported modes to do (if any sensible expectation can be formed). The caller may get the slowest, safest mode, but that's better than something functionally wrong. You minimise the client code's dependency on getting everything perfect for your code. The problem with this - compared to an assert/exception - is that it can go unnoticed in a test environment, so consider also writing an explanation to std::cerr, using a static variable to limit the messages to one per process run. That's a very useful diagnostic.

An exception, fatal assertion etc. might bring down a client application at a very inconvenient moment.... Seems a bit draconian, and not something I'd appreciate particularly. Another option is to have an environment variable control this behaviour.

(There's presumably a similar issue for values that aren't even in your current enumeration.)