Есть константные объекты, есть константные методы. С простыми случаями (типа int size() const) все понятно. А вот как быть с таким:
const QObjectList & QObject::children() const
где
typedef QList<QObject*> QObjectList;
Т.е. можно из константного объекта получить список не константных детей со всеми вытекающими последствиями. Разве в этом случае не нарушиться константность?
Здравствуйте, serjjj, Вы писали:
S>Т.е. можно из константного объекта получить список не константных детей со всеми вытекающими последствиями. Разве в этом случае не нарушиться константность?
Объект это некий последовательный набор байт. Константность означает, что этот набор байт не будет изменяться. А дети это другие объекты, другой набор байт.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, serjjj, Вы писали:
S>>Т.е. можно из константного объекта получить список не константных детей со всеми вытекающими последствиями. Разве в этом случае не нарушиться константность?
M>Объект это некий последовательный набор байт. Константность означает, что этот набор байт не будет изменяться. А дети это другие объекты, другой набор байт.
Я бы сказал по другому. В контексте семантики С++ константность декларирует неизменность такого объекта.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Mystic, Вы писали:
M>>Здравствуйте, serjjj, Вы писали:
S>>>Т.е. можно из константного объекта получить список не константных детей со всеми вытекающими последствиями. Разве в этом случае не нарушиться константность?
M>>Объект это некий последовательный набор байт. Константность означает, что этот набор байт не будет изменяться. А дети это другие объекты, другой набор байт. K>Я бы сказал по другому. В контексте семантики С++ константность декларирует неизменность такого объекта.
Очень жиденькое определение.
Константность параметра в C++ говорит что метод не может вызывать неконстантные методы. Константные методы не могут менять состояние объекта, даже есть проверки на уровне компилятора.
Получается что вызываемый метод не может изменить переданный объект. Но при этом никто не мешает вызывающему коду менять объект, например в другом потоке. Так что константность — обязательство вызывающего метода не менять тот объект, который передан. Гарантий от этого никаких нет практически. Ни вызывающий не может быть уверен что объект не поменяется, ни вызываемый не может рассчитывать на неизменность объекта.
Здравствуйте, serjjj, Вы писали:
S>Есть константные объекты, есть константные методы. С простыми случаями (типа int size() const) все понятно. А вот как быть с таким: S>
S>Т.е. можно из константного объекта получить список не константных детей со всеми вытекающими последствиями. Разве в этом случае не нарушиться константность?
Константость — очень слабая гарантия, которую вынужден реализовывать и поддерживать код контейнера в данном случае.
Т.е. мой пример из Qt не является эталоном для подражания? А константность предполагает (в идеале) нечто большее, чем просто неизменность памяти где лежит непосредственно сам объект. Хотя смысла во всех эти телодвижение не очень много.
Здравствуйте, serjjj, Вы писали:
S>А константность предполагает (в идеале) нечто большее, чем просто неизменность памяти где лежит непосредственно сам объект.
Нет.
Есть константный указаталь на объект, есть указатель на константный объект, есть константный указатель на константный объект, и всё это разные вещи.
S>Т.е. мой пример из Qt не является эталоном для подражания?
It depends.
S>А константность предполагает (в идеале) нечто большее, чем просто неизменность памяти где лежит непосредственно сам объект.
Кто предполагает? В каком идеале?
Константность — набор ограничений для конструкций языка. Увы эти ограничения почти не дают гарантий.
Люди.
G>Константность — набор ограничений для конструкций языка.
Естественно. Вопрос в том как все это использовать дабы код получился понятый не только компилятору, но и человеку.
Вот утрированный пример. Есть метод:
int m1() const;
Он реализован таким образом, что после каждого его вызова будет меняться состояние объекта. Компилятор претензий не имеет, однако вызовет ли это недоумение у других людей, или это вполне нормальная практика?
TB>Есть константный указаталь на объект, есть указатель на константный объект, есть константный указатель на константный объект, и всё это разные вещи.
Здравствуйте, serjjj, Вы писали:
G>>Кто предполагает?
S>Люди.
Это зря. Умозаключения надо строить на основе фактов, а не предположений.
G>>Константность — набор ограничений для конструкций языка.
S>Естественно. Вопрос в том как все это использовать дабы код получился понятый не только компилятору, но и человеку.
S>Вот утрированный пример. Есть метод: S>
S>int m1() const;
S>
S>Он реализован таким образом, что после каждого его вызова будет меняться состояние объекта. Компилятор претензий не имеет, однако вызовет ли это недоумение у других людей, или это вполне нормальная практика?
Если вызовет изменениями наблюдаемого состояния, то конечно плохо так писать. Если нет, то нет.
G>Если вызовет изменениями наблюдаемого состояния, то конечно плохо так писать.
Вот про это я и говорю. Тогда выворачивание на изнанку не константных детей из константного контейнера не самая хорошая идея. Под контейнером я понимаю не просто список (или типа того), а сложный объект, работа которого зависит от состояния детей.
Здравствуйте, serjjj, Вы писали: S>Есть константные объекты, есть константные методы. С простыми случаями (типа int size() const) все понятно. А вот как быть с таким: S>
Здравствуйте, serjjj, Вы писали: S>Я не понял: "const == thread safe" вместо или в дополнение к "const == logically const"?
как я понял, понятие "logically const" слишком неформальное, чтобы им реально пользоваться, а вот с thread safe как раз все однозначно, поэтому, можно сказать, "вместо"
__>как я понял, понятие "logically const" слишком неформальное, чтобы им реально пользоваться, а вот с thread safe как раз все однозначно, поэтому, можно сказать, "вместо"
Эту тему я и создал по причине непонимания что такое "logically const".
Хотя получается мой пример с методом
int m1() const;
который при каждом вызове меняет состояние объекта вполне законен и адекватен, если там все синхронизировано.
Здравствуйте, serjjj, Вы писали: S>Эту тему я и создал по причине непонимания что такое "logically const".
вообще, по уму все обьекты должны быть const — как, соб-но в математике это и есть
не-const это костыль такой, воркэраунд, когда мы считаем, что предыдущее состояние не важно и мы заменяем текущий обьект новым.
это очень рисковая операция, потому что обычно все, кто ссылался на этот обьект, не в теме, что он изменился.
формально, я думаю, const контейнер может ссылаться на не-const обьекты, точно так же, как this — это const указатель на данные, которые могут меняться.
Здравствуйте, serjjj, Вы писали:
G>>const != thread safe
S>Как я понимаю, в C++11 таки "const == thread safe" (bitwise const or internally synchronized).
Неправильно понимаешь.
