Перейти к содержанию
    

Инлайновая функция

Так что - даже если современные версии компиляторов не инлайнят, то ничто не мешает инлайнить последующим версиям.

Имхо все идет именно к этому. Стандарт отдает работу с volatile на усмотрение компилятору.

What constitutes an access to an object that has volatile-qualified type is implementation-defined.
Изменено пользователем aiwa

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Стандарт отдает работу с volatile на усмотрение компилятору.

Нет, не отдаёт. И вот эта цитата из стандарта - это вовсе не про то.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Насколько я понимаю, под реализацией имеется ввиду компилятор+платформа.

Но по поводу доступа к 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.

Что это всего лишь подсказка компилятору, что объект может быть изменен незамеченным для компилятора способом.

Однако в случае локального указателя с последующим вызовом, компилятор гарантированно может быть уверен какое значение содержится в нем.

Инлайн-вставка никак не противоречит стандарту.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Однако в случае локального указателя с последующим вызовом, компилятор гарантированно может быть уверен какое значение содержится в нем.

Нет, не может. Стандарт запрещает: "An object that has volatile-qualified type may be modified in ways unknown to the implementation". По-моему, это фразу нельзя толковать никак иначе. Если компилятор на это забил - что же, можно подумать, мы не видели глючных компиляторов.

Кстати, я цитирую C99. Вы цитируете C++. Там есть некоторая разница. Сам предпочитаю в C++ не вникать, да и не использую я его.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Стандарт отдает работу с volatile на усмотрение компилятору.

Приведенная строка говорит лишь о том что обращение к волайл объектам может отличаться от простого доступа на аппаратном уровне. И если бы вы прочитали следующую фразу то увидели бы что там дополнительно предупреждается что если будешь обращаться к волатайл объекту через указатель в котором этот волатайл открутили, то это ЮБ.

 

А так все правила для волатайла которые записаны в стандарте должна выполнять любая реализация. Независимо от того как она их имплементирует.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

предупреждается что если будешь обращаться к волатайл объекту через указатель в котором этот волатайл открутили, то это ЮБ.

Значит ли это, что копирование волатайл объектов при помощи memcpy - это UB? Как страшно жЫть!

Мы-то понимаем, что memcpy может читать и писать в произвольном порядке, и даже повторно. Но зачем пугать этими страшными буквами UB?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Стандарт запрещает: "An object that has volatile-qualified type may be modified in ways unknown to the implementation". По-моему, это фразу нельзя толковать никак иначе.

В английском не силен, правильно толковать не берусь, но, имхо, "мау be" - это предупреждение ни к чему строго не обязывающее.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Значит ли это, что копирование волатайл объектов при помощи memcpy - это UB? Как страшно жЫть!

Мы-то понимаем, что memcpy может читать и писать в произвольном порядке, и даже повторно. Но зачем пугать этими страшными буквами UB?

Если вы пишете абсолютно переносимый код - да. Представьте что у вас регистровый файл с байтовым доступом на 32битной машине (да, извращение). Компилятор про это извращение знает и волатайл доступ делает правильно. А теперь представьте что вы делаете memcpy в этот регистровый файл.

Стандарт такой, его задача формализовать язык которой возможно имплементировать на самой извращенской платформе, вкупе с максимальными возможностями для оптимизации.

Хотя сейчас наметилась тенденция по вычищению самых упоротых ЮБ, но комитет как всегда быстр (чуть быстрее улитки).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В английском не силен, правильно толковать не берусь, но, имхо, "мау 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:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати с волатайл буферами (если не хочется быть платформозависимым) стоит использовать std::copy, который вроде как правильно воспринимает волатайл. Но сам указатель-итератор не должен быть выхолощен от волатайл-квалификатора.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нет, не может. Стандарт запрещает: "An object that has volatile-qualified type may be modified in ways unknown to the implementation". По-моему, это фразу нельзя толковать никак иначе. Если компилятор на это забил - что же, можно подумать, мы не видели глючных компиляторов.

А разве в таком случае компилятор к оператору ((void (*volatile)())func)(); не равным образом?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...