C++: константные Летучие методы

Question

У меня судорога мозга:

struct MyStruct 
{ 
    int x; 

    ... 

    inline int getX1() const { return x; } 
    inline int getX2() const volatile { return x; } 
}; 

volatile MyStruct myStruct; 

Я понимаю, что компилятор будет позволять мне называть myStruct.getX2() и не позволит мне позвонить myStruct.getX1(), потому что методы призвали volatile structs/classes должны иметь квалификатор volatile для этих методов.

Вот мой вопрос: если я создам такой класс, и я опубликую его для использования другими программными подпрограммами, каковы причины, по которым я бы добавил или не добавил изменчивый классификатор метода?

Это потому, что метод помеченный volatile говорит компилятору не принимать какие-либо из ее членов не volatile, в целях оптимизации, в то время как, если метод не помечен volatile, то все члены не помечена volatile могут быть оптимизированы?

Answer 1

Стандарт не предоставляет функции volatile для любых стандартных классов, поэтому при нормальных обстоятельствах вы не должны.

Вы правы о последствиях в последнем абзаце - так же, как с const функций-членов, в функции volatile члена this является указателем к летучим. И так, независимо от того, что ваша реализация делает для реализации энергозависимого доступа к памяти (отключение различных видов оптимизации, для стартеров), он сделает это для любых обращений через this.

Я подозреваю, что это будет стоит только предоставление volatile функций-членов для класса, который охватывает некоторые немного памяти, что может фактически быть летучими или может нет. Затем пользователь может создать объект volatile или не-volatile, если применимо. Если память определенно должна быть изменчивой, то я думаю, что вам лучше с не volatile объектами, имеющими элемент данных volatile.

Теперь я пытаюсь представить себе реальное использование - класс «счетчик», который может быть создан поверх магического адреса, который обновляется аппаратным обеспечением или прерыванием, которое вы написали (в этом случае вы может создать волатильный экземпляр с новым местом размещения), но также имеет прецедент, где он всегда обновляется только по вызову из «нормального» кода (в этом случае он может быть нестабильным экземпляром).Вероятно, вы просто воспользуетесь «хитом производительности» для того, чтобы сделать элемент данных нестабильным в обоих случаях, поскольку он не наносит никакого вреда. Но вы могут предоставить volatile и не volatile версии функций-членов, содержащие идентичный код, один из которых будет оптимизирован, а другой нет.

Answer 2

Это потому, что метод помеченного летучим указует компилятор не принимать какие-либо из ее членов не является неустойчивым, в целях оптимизации, в то время как, если метод не помечен изменчив, то любые члены не помеченные летучими могут быть оптимизированы?

Да.

В volatile функции, то *this объект становится volatile который, в свою очередь, означает, что каждый нестатический член класса становится volatile, так же, как в const функции, то *this объект становится const который, в свою очередь, означает, что каждый нестатический член класса становится const.

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