Почему атомный двойной полностью не реализован

Мой вопрос довольно прост. Почему не std::atomic<double> реализовано полностью? Я знаю, что это связано с взаимным доступом с переменной скоростью. Но я действительно не понимаю, почему это невозможно в двойнике.

В нем указано, что можно использовать любой тип тривиально скопируемый. И, конечно, двойной среди них. Поэтому основные операции должны быть точными (настройка, чтение и т.д.). Однако на целых числах возможен дополнительный набор операций (fetch_add, ++, + = и т.д.).

Двойник очень мало отличается от этих типов. Это родная, тривиально скопируемая и т.д. Почему стандарт не включал double с этими типами?

Ответ 1

std::atomic<double> поддерживается в том смысле, что вы можете создать его в своей программе, и он будет работать в соответствии с правилами С++ 11. Вы можете выполнять с ним грузы и магазины, а также выполнять обмен по обмену и т.д.

В стандарте указано, что арифметические операции (+, *, + =, &, и т.д.) предоставляются только для атоматики "интегральных типов", поэтому std::atomic<double> не будет иметь какой-либо из указанных операций.

Мое понимание заключается в том, что, поскольку поддержка с добавлением fetch-add или любых других атомных арифметических операций для типов с плавающей запятой в аппаратных средствах, используемых сегодня, стандарт С++ не предоставляет им операторов, поскольку они должны быть осуществляется неэффективно.

(редактировать). В стороне, std::atomic<double> в VS2015RC заблокирован.

Ответ 2

Стандартная библиотека задает std::atomic<T>, где T - любой тип TriviallyCopyable. Так как double TriviallyCopyable, std::atomic<double> должен компилироваться и работать отлично.

Если это не так, у вас есть неисправная библиотека.

example: http://goo.gl/QhaphY

Изменить: поскольку комментарий разъясняет вопрос:

В стандарте С++ задаются конкретные специализации для фундаментальных интегральных типов. (т.е. типы, которые содержат целые числа, которые должны присутствовать на языке). Эти специализации имеют дополнительные требования к общему случаю атома, поскольку они должны поддерживать:

fetch_add
fetch_sub
fetch_and
fetch_or
fetch_xor
operator ++
оператор - Операторы сравнения и присваивания

ИЛИ, XOR и, конечно, не имеют отношения к плавающим типам, и даже даже сравнения начинают становиться сложными (из-за необходимости обрабатывать epsilon). Поэтому представляется неоправданным поручать, чтобы разработчики библиотек предоставляли специальные специализации, когда нет необходимости поддерживать спрос.

Конечно, нет ничего, что помешало бы разработчику библиотеки предоставить эту специализацию в маловероятном случае, когда данная архитектура поддерживает атомный эксклюзив - или двух двухлокальных (он никогда не будет!).