> Если речь именно о плюсах, а не Си, то нет существенной в данном контексте (особенно, когда нет static и область видимости не очевидна) разницы. И то и то не занимает места в секции данных, будет подставлено непосредственным операндом в машинную инструкцию.Не совсем. const int my_constant может быть операндом операции взятия адреса, и все такие операции должны возвращать одинаковый адрес. В случае же с enum { my_constant = 5}, каждое взятие адреса &my_constant может возвращать свой собственный адрес. Технически правда, я думаю они всё равно все будут одинаковыми, но это не гарантия компилятора, это способ имплементации компилятора.
> Это в случае переменных со связыванием. Отсюда при отсутствии static и возникает вопрос, а не определяется ли константа вот так
Тут компилятор тоже должен предоставить константе валидный адрес, другое дело, что если оптимизатор достаточно умён, и видя что время жизни ограничено лексическим скоупом, он может подметить ситуацию, когда адрес не используется. Такие штуки становятся сложнее, если константная переменная доступна для юнита (топ-левел декларация static const int), потому что то в чём компиль реально силён, и ещё сложнее, если она не ограничена юнитом (там только LTO может помочь, теоретически, а практически я не знаю, помогает ли он).
> В Си ничего нет про аллокацию на стеке. Там это называется automatic storage duration, и всякий сишник знает, что стека может вообще не быть.
Сишное мышление проявляется не в использовании слова "стек", а в озабоченности стораджем в ущерб всему остальному. C не проводит чётко разницы между, например, переменной, сторейжем ассоциированным с ней, и значением сохранённым в этом сторейже. Лол, из-за этого, я когда столкнулся с растом впервые, недели две бился головой о клавиатуру, не мог понять логики. Сторейж переменной может меняться по ходу дела, компилятор не даёт гарантий на этот счёт, значение в строейже может меняться, или сторейж может уходить от одной переменной к другой (например когда ты делаешь move: let my_big_value = ...; foo(my_big_value); функция foo будет работать с тем же самым куском сторейжа, который был ассоциирован с my_big_value, но переменная в ней будет другая).
В расте const декларация -- это имя для _значения_, let декларация -- это имя для переменной, которая может хранить значение, а может и не хранить. let делает _переменную_ неизменной, но нет гарантий что в сторейж никто не будет писать. В том примере выше, когда мы my_big_value отправляем в функцию, она может начать менять это значение. А вот константа... ты не можешь у неё отнять сторейж, ты не можешь изменить значение хранящееся в нём. Ты не можешь "затенить" константу другой декларацией, чтобы создать лексическую изменяемость:
const int x = 5;
{
const int x = 6;
cout << "лол я изменил значение константы x: " << x << endl;
}
cout << "фак ю, она осталась прежней: " << x << endl;
Вот в расте такое не прокатит. С let декларацией ты можешь так поступать, создавая новый бинд взамен старого, с const'ом так уже не выйдет.
> Ну как кто? Вон выше было "первое же -- это имя, с которым линкеру придётся разбираться".
В примере имя lexically scoped в функции. Оно не появляется в таблице имён линкера, все такие имена разрешаются компилятором.
