ну заинитил и чтоб дальше случайно не поменять - конст
Ну ессно
Сделай просто приватным полем без аксессоров. С константой ты нормально не подружишь это.
Оно конечно можно убрать конст, но там у меня класс хранит неизменяемую часть данных и поэтому я делаю конст, чтобы и придерживаться идеологии класса и самому не изменить в каком-нибудь методе спустя годы 😁.
Ну просто ответь себе на вопрос, что должно произойти при a = b (или любом другом операторе, a == b например), если эти константы разные?
Если объекты класса не копируемые и на перемещаемые, то почему бы и нет
const означает неизменность на протяжении всей жизни объекта, а не «обычно нельзя, но иногда (в специальных функциях) можно» меньше методов — меньше вероятность нарушить инварианты. рекомендую https://www.youtube.com/watch?v=glYq-dvgby4 (не потому, что SOLID в названии)
Я бы слово конст заменил на ридонли
Именно, уважаемый, именно! У меня конст поле для того, чтобы быть неизменным на протяжении всей жизни объекта.
Я отвечал счёте на этот вопрос. Будут определены пользовательские операторы.
А при a = b что с константой должно произойти?
Ничего. Она не изменится. Тут надо полностью показывать класс. Просто так не объяснишь зачем это сделано. Ну и не факт, конечно, что я все правильно придумал. 😁
Это может иметь смысл при маппинге экземпляров к их сторонней закрытой репрезентации с opaque-handle'ом (как в случае с GL, например: экземпляр, скажем, не "хранит" буфер, а им "является" - handle как раз станет const-полем).
то есть оба operator= (перемещения и копирования) удалены либо делают что-то специфичное для вашей задачи?
Делают специфичное. Я постараюсь сделать минимальный пример и показать. Возможно я и не прав сильно с этим конст полем.
если семантика присваиваний интуитивна для пользователей и ее легко объяснить, то, может, и норм
Обсуждают сегодня