Почему не полностью реализован атомарный двойной
Мой вопрос довольно прост. Почему нет std::atomic<double> реализован полностью? Я знаю, что это связано с блокированным доступом к переменным. Но я действительно не понимаю, почему это не может быть возможно на двойной.
Указано что любой тривиально копируемый Тип может быть использован. И, конечно, двойной среди них. Таким образом, основные операции должны быть в порядке (установка, чтение и так далее). Однако для целых чисел возможен дополнительный набор операций (fetch_add, ++, + = и т. Д.).
Двойник очень мало отличается от этих типов. Он является родным, легко копируемым и т. Д. Почему стандарт не включает в себя тип double с этими типами?
Решение
std::atomic<double> поддерживается в том смысле, что вы можете создать его в своей программе, и он будет работать по правилам C ++ 11. Вы можете выполнять загрузки и склады с ним и делать сравнение-обмен и тому подобное.
Стандарт определяет, что арифметические операции (+, *, + =, &и т. д.) предоставляются только для атомик «целочисленных типов», поэтому std::atomic<double> не будет определена ни одна из этих операций.
Насколько я понимаю, поскольку из-за слабой поддержки операций выборки-добавления или любых других атомарных арифметических операций для типов с плавающей запятой в используемом сегодня оборудовании, стандарт C ++ не предоставляет для них операторы, поскольку они должны быть реализованы неэффективно.
(редактировать). Как в сторону, std::atomic<double> в VS2015RC без блокировки.
Другие решения
Стандартная библиотека мандатов std::atomic<T> где Т любой TriviallyCopyable тип. поскольку double является TriviallyCopyable, std::atomic<double> должен компилироваться и работать на отлично
Если это не так, у вас есть неисправная библиотека.
пример: http://goo.gl/QhaphY
Изменить: так как комментарий уточняющий вопрос:
Стандарт c ++ определяет конкретные специализации для фундаментальных целочисленных типов. (то есть типы, которые содержат целые числа, которые должны присутствовать в языке). У этих специализаций есть дополнительные требования к общему случаю атомарности, которые они должны поддерживать:
- fetch_add
- fetch_sub
- fetch_and
- fetch_or
- fetch_xor
- оператор ++
- operator—
- операторы сравнения и присваивания
ИЛИ, XOR и AND, конечно, не относятся к плавающим типам, и даже сравнения начинают становиться сложнее (из-за необходимости обрабатывать эпсилон). Так что кажется необоснованным мандат что сопровождающие библиотеки делают доступными конкретные специализации, когда нет необходимости поддерживать спрос.
Там нет ничего, чтобы предотвращать сопровождающий библиотеки, предоставляющий эту специализацию в маловероятном случае, когда данная архитектура поддерживает атомарный исключающий или два двойных (это никогда не будет!).