Реализация atomic <T>:: магазин

Question

Я пытаюсь реализовать атомарную библиотеку из черновика C ++ 0x.В частности, я реализую §29.6 / 8, метод store :

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

Требование гласит:

Аргумент порядка не должен быть memory_order_consume, memory_order_acquire, ни memory_order_acq_rel.

Я не уверен, что делать, если это один из них.Должен ли я ничего не делать, выдавать исключение, получать неопределенное поведение или делать что-то еще?

_{PS: «C ++ 0X» выглядит как мертвая рыба: 3}

Answer 1

Делай, что хочешь. Это не имеет значения.

Когда ISO заявляет, что вы «не должны что-то делать», это неопределяемое поведение. Если пользователь делает это, он нарушает договор с реализацией, и реализация имеет право делать, что пожелает.

То, что вы решили сделать, полностью зависит от вас. Я бы выбрал то, что делает вашу реализацию «лучше» (на ваш взгляд, это будет быстрее, более читабельно, с учетом принципа наименьшего удивления и т. Д.).

Сам я бы пошел на удобочитаемость (поскольку мне пришлось бы поддерживать вещь) со скоростью, составляющей близкую секунду.

Answer 2

Я предпочитаю ошибку времени компиляции.Если нет, то сбой assert ().

Assert хорош, потому что он компилируется из версии выпуска и не влияет на производительность.

Ошибки времени компиляции еще лучше, потому что они обеспечивают большенемедленная обратная связь, не дожидаясь ошибки программного обеспечения.Проверки ошибок во время компиляции - это то, что мне нравится в коде C ++ поверх кода Python, Ruby, Perl.

Answer 3

Я бы предпочел смутное вменяемое поведение, что-то сумасшедшее.

Ну, как потенциальный потребитель вашей библиотеки, вот что я хотел бы: если нет затрат на производительность для документированного использования, тогда посмотритеесли одно из значений memory_order предоставляет функциональный расширенный набор других, в частности что-то, соответствующее тому, что вызывающий может наивно ожидать от неподдерживаемых режимов (если может быть сформировано какое-либо разумное ожидание).Вызывающий может получить самый медленный, самый безопасный режим, но это лучше, чем что-то функционально неправильное.Вы сводите к минимуму зависимость клиентского кода от получения всего, что идеально подходит для вашего кода.Проблема с этим - по сравнению с утверждением / исключением - заключается в том, что он может остаться незамеченным в тестовой среде, поэтому рассмотрите также написание объяснения для std :: cerr, используя статическую переменную, чтобы ограничить количество сообщений одним запуском процесса.Это очень полезная диагностика.

Исключение, фатальное утверждение и т. Д. Может привести к сбою клиентского приложения в очень неудобный момент ... Кажется, немного драконовским, а не то, что я особенно ценю.Другой вариант - иметь переменную окружения, управляющую этим поведением.

(Вероятно, существует аналогичная проблема для значений, которых нет даже в текущем перечислении.)