Здравствуйте, so5team, Вы писали:

s> ·>Хаскель же уж если так хочется.
s> Haskell или OCaml хорошие примеры, но там GC, это другая область. Меня радует, что в Rust-е сделали константность. Причем предположу, что там за счет borrow checker-а похожая на C++ модель константности работает лучше, чем в C++ (но утверждать не могу, дальше hello-world-ов у меня с Rust-ом не зашло).
Да, borrow checker нужен для нормальной реализации константности. Иначе полумеры.

s> ·>Не совсем. YAGNI же.
s> C++ более требовательный язык и задачи на нем простотой не отличаются, так что здесь "не совсем" и "yagni" имеют другой привкус.
Я имею в виду не бизнес-задачи, а задачи манипуляции кодом. Почему, например, перенос метода между классами _должно_ быть сложной задачей?

s> ·>Это не в java, а в программировании вообще.
s> "Отучаемся говорить за всех" (с)
Ну вот видишь, нетривиальный borrow checker ещё как-то может это решить. А не этот ваш const.

s>>> и у нас реально константный объект.
s> ·>Он константный лишь потому, что так говорит Стандарт про std::string.
s> Замените std::string на любой пользовательский тип и вы обнаружите, что для const объекта компилятор разрешает вызывать только const-методы. А в const-методах нельзя менять поля объекта.
Так это просто неявный интерфейс, вот и всё.

std::string oops{ "Hello, World" };
const std::string &hello = oops;

и уже бардак. Как бы константный объект, но уже нереально, оксюморон "изменяемая константа" получается внезапно.

s> И это изкаропки и бесплатно.
Как и интерфейсы в java.

s> ·>А если это какой-то левый тип, там внезапно зависимость от статик переменной и приплыли.
s> Как приплыли, куда приплыли, ничего не понятно.
Состояние объекта меняется.

constObj.getX();
...
constObj.getX();

может иметь разный результат.

А иммутабельность гарантирует, что результат будет одинаковый, не смотря ни на что.

s> ·>А так в java то же самое final String hello = "Hello, World" реально иммутабельный объект в константной переменной.
s> Так это у вас безусловный рефлекс на то, что в Java String -- это иммутабельная строка, вот вам и кажется, что вы приводите аналогичный пример. Замените std::string на std::vector из std::queue и ничего не поменяется. В отличии от Java.
List.of(1, 2, 3) тоже иммутабельный. А зачем иметь queue константную, чтобы что? Чтобы, например, дать возможность перебрать, но запретить добавлять. Ну так она имплементирует интерфейс Iterable, внезапно. И Iterable likeAConstQueue = queue даёт тебе что ты хочешь (с небольшими оговорками).

s> ·>В java делают defensive copy, как правило.
s> Так память же не ресурс!
А в плюсах как иммутабельность делать? Других вариантов тупо нет. ownership можно передавать, но это частный случай.

Иммутабельность — полезная вещь. Константность — очень спорная полезность.

s> В C++ для этих целей есть mutable, который устраняет надобность во многих const_cast. А вот когда в коде появляется const_cast, то это уже признак наличия какого-то костыля.
Но уже этот mutable сводит на нет идею константности.
Можешь считать, что в java просто умолчание другое — все поля mutable по дефолту, кроме обозначенных final.

s> ·>Или наоборот — сильно так.
s> Не так. Есть языки посложнее Java (или C#), которые десятилетиями живут без IDE уровня IDEA или VisualStudio и это никому не мешает.
Ах да, конечно, бедность — не порок.

s> ·>Иначе тебе приходится очень аккуратно думать как назвать каждую переменную и функцию и т.п.
s> А вы не думаете?
s> Хотя да, "фигак-фигак-и-в-продакшен" mind-set и все дела
Решение задачи важнее, чем названия методов. Методы можно потом переименовать, когда тесты проходят. А ещё требования любят меняться, потом.

s> ·>Без рефакторингов это будет дорогой ошибкой, если придётся потом что-то поменять.
s> Или не будет.
"Работает — не трожь" mind-set? Нет, я люблю чтоб и красиво тоже было.

s> ·>Может быть это важно для написания каких-то общеиспользуемых библиотек, но в обычных аппликухах это не так.
s> Мне не доводилось видеть разработки на C++ "обычных аппликух" уже лет 20, наверное.
"Обычные", в смысле не API. Что ты под этим подразумеваешь — не знаю.

Здравствуйте, ·, Вы писали:

s>> ·>Хаскель же уж если так хочется.
s>> Haskell или OCaml хорошие примеры, но там GC, это другая область. Меня радует, что в Rust-е сделали константность. Причем предположу, что там за счет borrow checker-а похожая на C++ модель константности работает лучше, чем в C++ (но утверждать не могу, дальше hello-world-ов у меня с Rust-ом не зашло).
·>Да, borrow checker нужен для нормальной реализации константности. Иначе полумеры.

В D сделали иммутабельность и без borrow checker-а.

·>Я имею в виду не бизнес-задачи, а задачи манипуляции кодом. Почему, например, перенос метода между классами _должно_ быть сложной задачей?

А это сложная задача?

s>> ·>Это не в java, а в программировании вообще.
s>> "Отучаемся говорить за всех" (с)
·>Ну вот видишь, нетривиальный borrow checker ещё как-то может это решить. А не этот ваш const.

Так у нас в C++ хотя бы const есть, а в Java и этого нет.

·>Так это просто неявный интерфейс, вот и всё.

Может вам матчасть подучить?

·>

·>std::string oops{ "Hello, World" };
·>const std::string &hello = oops;
·>

·>и уже бардак.

Таки да, марш учить матчасть.

·>Как бы константный объект

Как бы константным объектом здесь и не пахнет. От слова совсем.

s>> И это изкаропки и бесплатно.
·>Как и интерфейсы в java.

Так уже выяснили, что интерфейсы Java к константности отношения не имеют. Просто привыкли жрать что дали и научились получать удовольствие.

·>Состояние объекта меняется.
·>

·>constObj.getX();
·>...
·>constObj.getX();
·>

·>может иметь разный результат.

А кто сказал, что getX имеет отношение к состоянию объекта? Стиль наименования как в Java?

·>А иммутабельность гарантирует, что результат будет одинаковый, не смотря ни на что.

Ну и в C++ у нас есть помощь со стороны компилятора в ее обеспечении, в отличии от.

·>List.of(1, 2, 3) тоже иммутабельный.

А у вас, походу, фантазия вообще отсутствует.

·>А зачем иметь queue константную, чтобы что?

Чтобы показать, что в C++ константой можно сделать даже то, что на такую роль и не предполагалось.

·>А в плюсах как иммутабельность делать?

Поверить тому, что переданное по константной ссылке и есть константа.

·>Иммутабельность — полезная вещь. Константность — очень спорная полезность.

Вам бы еще понять, что в нормальных языках константность на уровне языка сильно помогает в достижении иммутабельности. Но с этим пониманием явно проблемы, mind-set полагаю, плюс отсутствие воображения.

·>Можешь считать, что в java просто умолчание другое — все поля mutable по дефолту, кроме обозначенных final.

Вы бы уяснили себе, что final в Java запрещает присвоить новое значение ссылке. И не более того. А то мне, как C++нику, как-то совестно об этом вам напоминать.

·>Ах да, конечно, бедность — не порок.

Нет, просто языки делались людьми для людей, а не для заработка на индусах разных национальностей.

s>> ·>Без рефакторингов это будет дорогой ошибкой, если придётся потом что-то поменять.
s>> Или не будет.
·>"Работает — не трожь" mind-set?

Нет, вы не поняли. Не будет дорогой ошибкой если придется потом что-то поменять.

·>"Обычные", в смысле не API. Что ты под этим подразумеваешь — не знаю.

Обычные -- это такие, в которых нет суровых требований к сложности/ресурсоемкости/производительности. Вне зависимости от того, бэкэнд это, GUI, CLI или еще что-то.

Здравствуйте, so5team, Вы писали:

S>В D сделали иммутабельность и без borrow checker-а.

То есть компилятор D точно знает, что если в функцию передали const*, то пока выполняется функция, объект невозможно изменить никакими внешними способами? В С++ это не так, в Русте это так за счёт борзочекара.

Здравствуйте, ·, Вы писали:

·>А если указатель?

Можно использовать указатель как ключ, почему б и нет.

·>А если массив является ключом в двух разных мапах?

Тогда копировать, да.

Здравствуйте, T4r4sB, Вы писали:

TB>·>А если массив является ключом в двух разных мапах?

TB>Тогда копировать, да.

Тут могут быть варианты — в качестве ключей можно использовать указатели и std::reference_wrapper-ы с кастомными хэшерами/компараторами.

Здравствуйте, T4r4sB, Вы писали:

S>>В D сделали иммутабельность и без borrow checker-а.

TB>То есть компилятор D точно знает, что если в функцию передали const*, то пока выполняется функция, объект невозможно изменить никакими внешними способами?

В D есть понятие immutable: https://dlang.org/spec/const3.html
Насколько я помню, то const ссылку на immutable можно передать, в этом случае компилятор знает, что по const ссылке значение менять не будут.
Использует ли это компилятор для оптимизаций -- хз, я давным-давно перестал следить за D и его возможностями. Когда-то давно компилятор D базировался на кодовой базе от Digital Mars C++ и вряд ли оптимизатор там был такой же продвинутый, как у GCC/MSVC/Clang конца 00-х. Перешел ли сейчас референсный dmd на какой-то современный продвинутый бэкэнд не в курсе.

Насколько помню, если в функцию/метод передается immutable ссылка, то внутри функции/метода можно быть уверенным, что снаружи значение не изменится (для const ссылок такой уверенности нет).

TB>В С++ это не так, в Русте это так за счёт борзочекара.

В Rust учли опыт C++, к счастью.

Здравствуйте, T4r4sB, Вы писали:

TB>·>А если указатель?
TB>Можно использовать указатель как ключ, почему б и нет.
Сравнивать надо указуемое, а не значение указателя. Иначе ты тупо извлечь ничего из мапы не сможешь.

TB>·>А если массив является ключом в двух разных мапах?
TB>Тогда копировать, да.
Ага-ага. Память — не ресурс.

Здравствуйте, so5team, Вы писали:

s> ·>Да, borrow checker нужен для нормальной реализации константности. Иначе полумеры.
s> В D сделали иммутабельность и без borrow checker-а.
Так я про константность. Не путай. Иммутабельность и в яве давно есть в виде records.

s> ·>Я имею в виду не бизнес-задачи, а задачи манипуляции кодом. Почему, например, перенос метода между классами _должно_ быть сложной задачей?
s> А это сложная задача?
Если это делать без поддержки IDE, то менять вручную сотни мест — может быть очень сложно. И это ведь не единственный доступный рефакторинг.

s> s>> "Отучаемся говорить за всех" (с)
s> ·>Ну вот видишь, нетривиальный borrow checker ещё как-то может это решить. А не этот ваш const.
s> Так у нас в C++ хотя бы const есть, а в Java и этого нет.
Ты не убедил, что он таки нужен в java, там есть другие средства.

s> ·>Так это просто неявный интерфейс, вот и всё.
s> Может вам матчасть подучить?
Если ты будешь придираться к тому, что константный объект и константная ссылка на объект — не одно и то же, то пофиг, не в этом суть, а в практике. Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.

s> s>> И это изкаропки и бесплатно.
s> ·>Как и интерфейсы в java.
s> Так уже выяснили, что интерфейсы Java к константности отношения не имеют. Просто привыкли жрать что дали и научились получать удовольствие.
Они могут создавать константное представление объекта для использования в других местах. Т.е. в качестве этой роли их можно использовать.

s> ·>Состояние объекта меняется.
s> ·>может иметь разный результат.
s> А кто сказал, что getX имеет отношение к состоянию объекта? Стиль наименования как в Java?
Не понял вопрос.

s> ·>А иммутабельность гарантирует, что результат будет одинаковый, не смотря ни на что.
s> Ну и в C++ у нас есть помощь со стороны компилятора в ее обеспечении, в отличии от.
В java есть records.

s> ·>А зачем иметь queue константную, чтобы что?
s> Чтобы показать, что в C++ константой можно сделать даже то, что на такую роль и не предполагалось.
А дальше что с этой константой делать?

s> ·>А в плюсах как иммутабельность делать?
s> Поверить тому, что переданное по константной ссылке и есть константа.
Гы. "Поверить". Ясно... Правильно, без веры, молитвы, да чистого сердца разве можно код писать?!

s> ·>Иммутабельность — полезная вещь. Константность — очень спорная полезность.
s> Вам бы еще понять, что в нормальных языках константность на уровне языка сильно помогает в достижении иммутабельности. Но с этим пониманием явно проблемы, mind-set полагаю, плюс отсутствие воображения.
Константность — не помогает. Иммутабельность помогает, как record в java.

s> ·>Можешь считать, что в java просто умолчание другое — все поля mutable по дефолту, кроме обозначенных final.
s> Вы бы уяснили себе, что final в Java запрещает присвоить новое значение ссылке. И не более того. А то мне, как C++нику, как-то совестно об этом вам напоминать.
А более и не надо.

s> ·>Ах да, конечно, бедность — не порок.
s> Нет, просто языки делались людьми для людей, а не для заработка на индусах разных национальностей.
Бедные, но очень гордые.

s> s>> Или не будет.
s> ·>"Работает — не трожь" mind-set?
s> Нет, вы не поняли. Не будет дорогой ошибкой если придется потом что-то поменять.
Как сделать банальное переименование в сотне файлов за 1 секунду? Только про search&replace не рассказывай.

s> ·>"Обычные", в смысле не API. Что ты под этим подразумеваешь — не знаю.
s> Обычные -- это такие, в которых нет суровых требований к сложности/ресурсоемкости/производительности. Вне зависимости от того, бэкэнд это, GUI, CLI или еще что-то.
И? Поменять смысл слова — не годится в качестве контраргумента моим высказываниям.

Здравствуйте, rg45, Вы писали:

r> TB>·>А если массив является ключом в двух разных мапах?
r> TB>Тогда копировать, да.
r> Тут могут быть варианты — в качестве ключей можно использовать указатели и std::reference_wrapper-ы с кастомными хэшерами/компараторами.
Верно. Но тогда пропадает "защита" от изменений ключа в мапе, которую обещает T4r4sB.

Здравствуйте, ·, Вы писали:

·>Верно. Но тогда пропадает "защита" от изменений ключа в мапе, которую обещает T4r4sB.

Почему это? И ссылка и указатель могут быть константными (ссылаться на константные данные, если быть более точным):

std::map<const int*, Foo, CustomComparer>;
std::map<const (*int)[42], Foo, CustomComparer>;
std::map<std::reference_wrapper<const int[42]>, Foo, CustomComparer>;

Так что, это уж как захочет программист

Здравствуйте, ·, Вы писали:

TB>>Можно использовать указатель как ключ, почему б и нет.
·>Сравнивать надо указуемое, а не значение указателя. Иначе ты тупо извлечь ничего из мапы не сможешь.

Без проблем — для этого предусмотренa возможность кастомизации хэшеров и компараторов: std::map, std::unordered_map.

Здравствуйте, rg45, Вы писали:

R>·>Верно. Но тогда пропадает "защита" от изменений ключа в мапе, которую обещает T4r4sB.
R>Почему это? И ссылка и указатель могут быть константными (сслаться на константные данные, если быть более точным):
Потому. Ты тоже не понимаешь разницу между константностью и иммутабельностью?

R>std::map<std::reference_wrapper<const int[42]>, Foo, CustomComparer>;

Давай попробуем:

std::map<std::reference_wrapper<const int>, std::string> map;
int key = 42;
map[key]= "hi";
key++; //упс! Мапа сломана.

Здравствуйте, rg45, Вы писали:

TB>>>Можно использовать указатель как ключ, почему б и нет.
R>·>Сравнивать надо указуемое, а не значение указателя. Иначе ты тупо извлечь ничего из мапы не сможешь.
R>Без проблем — для этого предусмотренa возможность кастомизации хэшеров и компараторов: std::map, std::unordered_map.
Дело не в этом. А в том, что указуемое может меняться независимо от мапы и нарушить инвариант.

Здравствуйте, ·, Вы писали:

·>Дело не в этом. А в том, что указуемое может меняться независимо от мапы и нарушить инвариант.

Все правильно, может. Потому что константность ссылки/указателя не гарантируют неизменности адресуемых данных. И тем не менее, программист МОЖЕТ обеспечить реальную константность адресуемых данных. И в этом случае их неизменность будет гарантирована в well-defined программе. Короче говоря, да, в этой области больше возможностей выстрелить себе в ногу. Но и возможность писать добротные надежные программы тоже есть.

Здравствуйте, rg45, Вы писали:

R>·>Дело не в этом. А в том, что указуемое может меняться независимо от мапы и нарушить инвариант.
R>Все правильно, может. Потому что константность ссылки/указателя не гарантируют неизменности адресуемых данных. И тем не менее, программист МОЖЕТ обеспечить реальную константность адресуемых данных. И в этом случае их неизменность будет гарантирована в well-defined программе. Короче говоря, да, в этой области больше возможностей выстрелить себе в ногу. Но и возможность писать добротные надежные программы тоже есть.
Я это прекрасно знаю. Ровно то же и в java. Просто T4r4sB заявил

Автор: T4r4sB
Дата: 12.05.23

, что в C++ есть какая-то защита в виде const. Да не даёт const ровным счётом ничего. Только если либо копия передаётся, либо передача ownership, и это немного помогает в некоторых случаях, но возможностей стрельнуть в ногу всё равно дофига.

Здравствуйте, ·, Вы писали:

s>> ·>Да, borrow checker нужен для нормальной реализации константности. Иначе полумеры.
s>> В D сделали иммутабельность и без borrow checker-а.
·>Так я про константность. Не путай.

Матчасть, матчасть!

·>Если это делать без поддержки IDE, то менять вручную сотни мест — может быть очень сложно.

А может и не быть.

·>Ты не убедил, что он таки нужен в java, там есть другие средства.

Вы думаете, что вас кто-то в чем-то убеждал? Полноте. Поржать над тем, как с удовольствием жрут убожество, да еще и причмокивают, -- это запросто. А вот убеждать...

s>> ·>Так это просто неявный интерфейс, вот и всё.
s>> Может вам матчасть подучить?
·>Если ты будешь придираться к тому, что константный объект и константная ссылка на объект — не одно и то же

Не одно.

·>, то пофиг, не в этом суть

Да ну?

·>, а в практике.

А, ну да.

·>Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.

Во-первых, могу передать по значению.

Во-вторых, константные ссылки могут быть на неконстантные объекты. Поэтому не нужно путать теплое с мягким. Хотя без знания матчасти это сложно, да.

·>Они могут создавать константное представление объекта для использования в других местах.

Это никак не контролируется компилятором. Это раз.
Это все порождает новые сущности. Это два.
И все, можно закапывать.

·>Не понял вопрос.

Вопрос в том, что с чего вы взяли, что вызов метода getX имеет какое-то отношение к состоянию объекта.
Но это риторический вопрос.

s>> ·>А иммутабельность гарантирует, что результат будет одинаковый, не смотря ни на что.
s>> Ну и в C++ у нас есть помощь со стороны компилятора в ее обеспечении, в отличии от.
·>В java есть records.

HashMap в Java -- это records? Как вы получите константный HashMap в Java?

s>> ·>А зачем иметь queue константную, чтобы что?
s>> Чтобы показать, что в C++ константой можно сделать даже то, что на такую роль и не предполагалось.
·>А дальше что с этой константой делать?

Например, разделить между тредами.

s>> ·>А в плюсах как иммутабельность делать?
s>> Поверить тому, что переданное по константной ссылке и есть константа.
·>Гы. "Поверить". Ясно... Правильно, без веры, молитвы, да чистого сердца разве можно код писать?!

Ну вы же в Java пишете интерфейсы и верите в то, что в их реализации никто ничего не модифицирует. Нам-то почему нельзя?

·>Константность — не помогает.

Так вы же ее готовить не умеете.

s>> Вы бы уяснили себе, что final в Java запрещает присвоить новое значение ссылке. И не более того. А то мне, как C++нику, как-то совестно об этом вам напоминать.
·>А более и не надо.

Поциент безнадежен, так и запишем.

Здравствуйте, ·, Вы писали:

·>Да не даёт const ровным счётом ничего.

Ну вот на этот счет у меня немного другое мнение. То, что он не гарантирует неизменности объектна, не означает, что он не дает НИЧЕГО. Это защита от непреднамеренного ошибочного изменения данных. А относительно примера, который ты привел выше — программист должен понимать опасность такого дизайна. И если даже такое где-то встрется, то, наверное, это следует рассматривать как какую-то вынужденную исключительную меру, а не как общий случай. Да, способов выстрелить себе в ногу в C++ больше, чем в других языках. По-моему, это ни для кого не секрет.

Здравствуйте, ·, Вы писали:

·>... Да не даёт const ровным счётом ничего. Только если либо копия передаётся, либо передача ownership, и это немного помогает в некоторых случаях, но возможностей стрельнуть в ногу всё равно дофига.

Например некоторый случай

Здравствуйте, so5team, Вы писали:

S>·>Так я про константность. Не путай.
S>Матчасть, матчасть!
Угу. Разберись. Вопросы-то какие возникли?

S>·>Если это делать без поддержки IDE, то менять вручную сотни мест — может быть очень сложно.
S>А может и не быть.
Давай, просвети: Как сделать банальное переименование в сотне файлов за 1 секунду? Только про search&replace не рассказывай. И про регекспы я тоже знаю.

s>>> ·>Так это просто неявный интерфейс, вот и всё.
s>>> Может вам матчасть подучить?
S>·>Если ты будешь придираться к тому, что константный объект и константная ссылка на объект — не одно и то же
S>Не одно.
Я знаю. Только рояли в нашем случае не играет.

S>·>Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.
S>Во-первых, могу передать по значению.
Ох, да. Я забыл. "Память — не ресурс!" — девиз С++. Я ничего не попутал?
А вообще если ты передаёшь по значению, то с таким же успехом можно передавать и неконстантный объект.

S>Во-вторых, константные ссылки могут быть на неконстантные объекты. Поэтому не нужно путать теплое с мягким. Хотя без знания матчасти это сложно, да.
Угу. Только причём тут константные объекты за которых ты так топишь? Выделил выше, чтобы ты контекст не терял.

S>·>Они могут создавать константное представление объекта для использования в других местах.
S>Это никак не контролируется компилятором. Это раз.
Как и в плюсах.

S>Это все порождает новые сущности. Это два.
Не порождает. А наоборот, уменьшает. Я тебе уже объяснял — вместо двух полных имплементаций методов const/non-const у тебя будет только сигнатура дважды — в классе и в интерфейсе.

S>И все, можно закапывать.
Да, бери лопату.

S>·>Не понял вопрос.
S>Вопрос в том, что с чего вы взяли, что вызов метода getX имеет какое-то отношение к состоянию объекта.
Состояние объекта обнаруживается по результату операций с ним. Иммутабельный объект имеет неизменное внешнее состояние. И getX обязан выдавать один и тот же результат вне зависимости от когда или где он был вызван.

s>>> ·>А иммутабельность гарантирует, что результат будет одинаковый, не смотря ни на что.
s>>> Ну и в C++ у нас есть помощь со стороны компилятора в ее обеспечении, в отличии от.
S>·>В java есть records.
S>HashMap в Java -- это records? Как вы получите константный HashMap в Java?
Map.ofEntries(entry(1, "a"), entry(2, "b"));

s>>> Чтобы показать, что в C++ константой можно сделать даже то, что на такую роль и не предполагалось.
S>·>А дальше что с этой константой делать?
S>Например, разделить между тредами.
Это как? Ты можешь разделить либо ссылку между тредами (без возможности защитить ссылаемое от изменений), либо копию (память — не ресурс).

S>·>Гы. "Поверить". Ясно... Правильно, без веры, молитвы, да чистого сердца разве можно код писать?!
S>Ну вы же в Java пишете интерфейсы и верите в то, что в их реализации никто ничего не модифицирует. Нам-то почему нельзя?
Верим. Просто вы ещё и привираете, что компилятор вас спасает и сохраняет благодаря молитве "const".

Здравствуйте, kov_serg, Вы писали:

_>·>... Да не даёт const ровным счётом ничего. Только если либо копия передаётся, либо передача ownership, и это немного помогает в некоторых случаях, но возможностей стрельнуть в ногу всё равно дофига.

_>Например некоторый случай

Компилятор имеет право воспринимать происходящее следующим образом:
В векторе 1 элемент
Вектор не реаллоцировался.
Указатель на элемет в первом cout и во втором cout один и тот же.
И там и там используется константное поле
Я его уже читал при первом cout
Зачем мне его читать еще раз, это же константа!
Вывожу закэшированное значение.

Бред собачий. Не имеет права компилятор так воспринимать происходящее. Вектор неконстантный и он модифицировался. Была реллокация или нет — это насрать. Более того, в этом случае используется даже неконстантная версия метода back, которая возвращает неконстантную ссылку на элемент вектора. Поводов для описанной оптимизации здесь нет от слова "совсем". Если какой-то компилятор так делает, то это просто баг. Это во-первых. А во-вторых, а какой компилятор так делает — пруфы будут?