Ленивое вычисление и проблемы с правильностью констант

Я создал класс камеры openGL, который использует ленивую оценку для предоставления окончательной проекции или матриц проекции модель-вид-проекция через функции получения. Пользователь предоставляет различные параметры камеры на протяжении всего жизненного цикла экземпляра (FOV, положение и т. Д.), Но вместо того, чтобы пересчитывать матрицу проекции и / или матрицу MVP каждый раз при изменении параметра, устанавливается флаг «изменено» ( т.е. старая кешированная матрица теперь недействительна). Каждый раз, когда пользователь затем запрашивает обновленную финальную матрицу, она пересчитывается, результат кешируется и возвращается константная ссылка.

Все звучит нормально, пока я не позвоню своему:

const QMatrix4x4& oE_GLCamera::getModelViewProjection() const;

из экземпляра const oE_GLCamera ... Я использую ссылки на константу повсюду в своем приложении для извлечения данных камеры из видовых экранов САПР без изменения камеры, но моя функция получения выполняет ленивую оценку переменных-членов, если они недействительны, что нарушает корректность констант.

Есть ли языковая функция или парадигма дизайна, о которых я не знаю, чтобы помочь с этим? Или ленивое вычисление принципиально несовместимо с константной корректностью? Мне известно о const_cast ‹>, я никогда не использовал его сам, но прочитал несколько вещей об этом, которые сводятся к следующему: если вы используете его, вы уже где-то ошиблись. Или это будет моим спасителем?

Любые советы будут приняты с благодарностью, Кэм.


person cmannett85    schedule 20.12.2010    source источник


Ответы (1)


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

Может быть, mutable?

Член класса, помеченный как mutable, всегда не является const, даже если к нему обращаются через ссылку или указатель на класс-владелец, который является const ссылкой или указателем на const.

person CB Bailey    schedule 20.12.2010
comment
Да: кешированное значение не является частью состояния объекта, поэтому его разумно пометить как изменяемое. - person Martin York; 21.12.2010
comment
Ага, это правильный путь. Однако вместо того, чтобы создавать половину элементов данных mutable по отдельности, я бы переместил все изменяемые данные в свои собственные struct и получил mutable экземпляр этого. - person sbi; 21.12.2010