C ++: const volatile методы

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Структуры / классы должны иметь квалификатор volatile для этих методов.

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

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

Answer 1

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

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

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

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

Answer 2

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

Да.

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

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