C++0xドラフトからアトミックライブラリを実装しようとしています。具体的には、 storeメソッドである§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であってはなりません。
これらのいずれかである場合はどうすればよいかわかりません。何もしない、例外をスローする、未定義の動作をする、または何か他のことをする必要がありますか？
PS：「C ++ 0X」は死んだ魚のように見えます：3
あなたがやりたいことをしなさい。それは問題ではありません。
ISOが「何かをしてはならない」と述べている場合、それを行うことは未定義の動作です。ユーザーがそれを行う場合、ユーザーは実装との契約に違反しており、実装は自由に実行する権利の範囲内にあります。
あなたがすることを決めるのは完全にあなた次第です。私はあなたの実装を「より良い」ものにするものを選びます（あなたの目には、より速く、より読みやすく、驚き最小の原則に従うなど）。
私自身、（物事を維持しなければならないので）読みやすさを追求し、スピードを1秒近く取っています。
コンパイル時のエラーが好きです。そうでない場合は、assert（）が失敗します。
アサートはリリースバージョンからコンパイルされ、パフォーマンスに影響を与えないため、優れています。
コンパイル時のエラーは、ソフトウェアがバグを回避するのを待たずに、より迅速なフィードバックを提供するため、さらに優れています。コンパイル時のエラーチェックは、Python、Ruby、PerlコードよりもC++コードについて私が気に入っていることです。
私はむしろ何かがおかしいという漠然とした正気の振る舞いをしたいです。
さて、あなたのライブラリの潜在的な消費者として、これが私が欲しいものです：文書化された使用法にパフォーマンスコストがない場合は、memory_order値の1つが他の値の機能的なスーパーセットを提供するかどうかを確認してくださいサポートされていないモードが実行することを素朴に期待する可能性があります（賢明な期待が形成される場合）。発信者は最も遅く、最も安全なモードを取得する可能性がありますが、それは機能的に間違っているものよりも優れています。コードに完全なものをすべて取得することへのクライアントコードの依存を最小限に抑えます。これに関する問題は、アサート/例外と比較して、テスト環境で見過ごされる可能性があることです。したがって、静的変数を使用してメッセージをプロセス実行ごとに1つに制限し、std::cerrに説明を書き込むことも検討してください。これは非常に便利な診断です。
例外、致命的なアサーションなどは、非常に不便な瞬間にクライアントアプリケーションをダウンさせる可能性があります。もう1つのオプションは、環境変数でこの動作を制御することです。
（おそらく、現在の列挙に含まれていない値についても同様の問題があります。）