aiwa 0 11 июля, 2018 Опубликовано 11 июля, 2018 (изменено) · Жалоба Так что - даже если современные версии компиляторов не инлайнят, то ничто не мешает инлайнить последующим версиям. Имхо все идет именно к этому. Стандарт отдает работу с volatile на усмотрение компилятору. What constitutes an access to an object that has volatile-qualified type is implementation-defined. Изменено 11 июля, 2018 пользователем aiwa Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба Стандарт отдает работу с volatile на усмотрение компилятору. Нет, не отдаёт. И вот эта цитата из стандарта - это вовсе не про то. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aiwa 0 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба Насколько я понимаю, под реализацией имеется ввиду компилятор+платформа. Но по поводу доступа к volatile говорится Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. Что это всего лишь подсказка компилятору, что объект может быть изменен незамеченным для компилятора способом. Однако в случае локального указателя с последующим вызовом, компилятор гарантированно может быть уверен какое значение содержится в нем. Инлайн-вставка никак не противоречит стандарту. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба Однако в случае локального указателя с последующим вызовом, компилятор гарантированно может быть уверен какое значение содержится в нем. Нет, не может. Стандарт запрещает: "An object that has volatile-qualified type may be modified in ways unknown to the implementation". По-моему, это фразу нельзя толковать никак иначе. Если компилятор на это забил - что же, можно подумать, мы не видели глючных компиляторов. Кстати, я цитирую C99. Вы цитируете C++. Там есть некоторая разница. Сам предпочитаю в C++ не вникать, да и не использую я его. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба Стандарт отдает работу с volatile на усмотрение компилятору. Приведенная строка говорит лишь о том что обращение к волайл объектам может отличаться от простого доступа на аппаратном уровне. И если бы вы прочитали следующую фразу то увидели бы что там дополнительно предупреждается что если будешь обращаться к волатайл объекту через указатель в котором этот волатайл открутили, то это ЮБ. А так все правила для волатайла которые записаны в стандарте должна выполнять любая реализация. Независимо от того как она их имплементирует. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба предупреждается что если будешь обращаться к волатайл объекту через указатель в котором этот волатайл открутили, то это ЮБ. Значит ли это, что копирование волатайл объектов при помощи memcpy - это UB? Как страшно жЫть! Мы-то понимаем, что memcpy может читать и писать в произвольном порядке, и даже повторно. Но зачем пугать этими страшными буквами UB? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aiwa 0 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба Стандарт запрещает: "An object that has volatile-qualified type may be modified in ways unknown to the implementation". По-моему, это фразу нельзя толковать никак иначе. В английском не силен, правильно толковать не берусь, но, имхо, "мау be" - это предупреждение ни к чему строго не обязывающее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба Значит ли это, что копирование волатайл объектов при помощи memcpy - это UB? Как страшно жЫть! Мы-то понимаем, что memcpy может читать и писать в произвольном порядке, и даже повторно. Но зачем пугать этими страшными буквами UB? Если вы пишете абсолютно переносимый код - да. Представьте что у вас регистровый файл с байтовым доступом на 32битной машине (да, извращение). Компилятор про это извращение знает и волатайл доступ делает правильно. А теперь представьте что вы делаете memcpy в этот регистровый файл. Стандарт такой, его задача формализовать язык которой возможно имплементировать на самой извращенской платформе, вкупе с максимальными возможностями для оптимизации. Хотя сейчас наметилась тенденция по вычищению самых упоротых ЮБ, но комитет как всегда быстр (чуть быстрее улитки). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба В английском не силен, правильно толковать не берусь, но, имхо, "мау be" - это предупреждение ни к чему строго не обязывающее. Там есть продолжение, которое именно обязывает: An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine... "Shall" - это как раз "обязательно". Как Гэндальф со своим "you shall not pass" :biggrin: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 11 июля, 2018 Опубликовано 11 июля, 2018 · Жалоба Кстати с волатайл буферами (если не хочется быть платформозависимым) стоит использовать std::copy, который вроде как правильно воспринимает волатайл. Но сам указатель-итератор не должен быть выхолощен от волатайл-квалификатора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aiwa 0 12 июля, 2018 Опубликовано 12 июля, 2018 · Жалоба Нет, не может. Стандарт запрещает: "An object that has volatile-qualified type may be modified in ways unknown to the implementation". По-моему, это фразу нельзя толковать никак иначе. Если компилятор на это забил - что же, можно подумать, мы не видели глючных компиляторов. А разве в таком случае компилятор к оператору ((void (*volatile)())func)(); не равным образом? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться