А как работает const ?

В гугле забанили? Давай помогу: google

насколько понимаю, если ты её не объявил глобально, это может быть тупо регистр или immediate значение захардкоженоное в команде процессора

Там видео с каким то клоуном, который жует сопли по элементарщине. Конкретно вопрос: могу ли я испортить значение conts T в рантайм?

В случае с int понятно, просто подставляется значение и ответ - нет. А если это сложный объект рамером в 100 мегабайт?

Если пролистаешь ниже там будет ссылка на SO, там уже будет все что тебе надо.

Дело не в глобальности, а в том, виден ли фактически ее «адрес» за пределами тр.юнита. Как там код будет выглядеть это вообще никак не связано с констом. Уехать в регистр может что угодно, а чтобы инициализироваться из imm не нужно быть констом.

Ирл гарантий нет, что тру-конст кинет трап по записи, но на всяких микроконтроллерах с например 64Кб рам и 1Мб флешкой - вот там консты могут лежать на ридонли флешке и траповать, афаик. В терминах линкера это секция rodata.

It depends.

Ничего там нет, что ему надо, умник. Ты ивен вопрос по английской не осилить сфорумлировать. Нечего ответить сидел бы молчал.

Но есть вызов mprotect() system call sets the access protections for the pages that contain the address range addr through addr + len - 1. Что не дает компиляторы объекты const разместить в нем?

SO:

In general const is 100% compiler

I suggest the C++ FQA’s section on const correctness: yosefk.com/c++fqa/const.html

Better read on the FAQ about const-correctnes: parashift.com/c++-faq-lite/const-correctness.html

Мда, онаним опять не смог…

Ты ивен вопрос по английской не осилить сфорумлировать

Ты знаешь что такое ключевые слова?

Нечего ответить сидел бы молчал.

Так зачем пишешь?

Вполне возможно, что он их и размещает всегда в rodata, скомпиляй да проверь. Но какая память будет под этой секцией - решает системный линкер при запуске (если речь о более-менее десктопном цп, а не о мк, где прога шьется заранее). То есть у самого конпелятора тут голос совещательный.

там в шестой ссылке, во втором комментарии нерелевантные данные я принес, чтобы сделать вид, что не обосралси

Иди уже а.

Все проверки делает компилятор

Да.

переменная располагается в области памяти, защищенной от записи

Иногда.

const это не только ro память, а что более важно - ещё и зелёный свет компилятору на оптимизации. Ну зачем в fn(int *i, const int *p) каждый раз читать из памяти p, ему обещали константность.

бред полный. const никак тут не будет влиять на оптимизации.

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

Почему же бред, можно иной fn(const int *i), вот здесь уже будет (например, отдадим указатель куда-то в другую функцию).

Где я тут константность обещаю? Могу в другом потоке в x писать, и мне ничего не будет.

int foo(const int* x) {
    return *x;
}

int main() {
    int x = 0;
    int y = foo(&x);
}

А restrict в стандарте С++ нет.

Можно вместо const int передать адрес int, и должно всё норм работать.

https://gcc.godbolt.org/z/gAnWc6

Siborgium уже всё правильно написал, я слоупок…

Все проверки делает компилятор С++

так точно

Ну вот смотри

void v(const int *i);

void fn(const int*i) {int q = *i; cout << q << '\n'; v(i); q = *i; cout << q << '\n';}
int main() {int i = 2; fn(&i);}

// другой модуль
void v(const int *i) {*const_cast<int*>(i) = 0;}

Очевидно, что компилятор спокойно мог бы вырезать второй q = *i (почему-то clang и gcc этого не делают, но могли бы).

Компилятор там тупо q и не делает, но если очень захочется, то наверняка можно нафантазировать нужные условия.

Ну всё верно.

В функции fn компилятор может оптимизировать, потому что он передаёт в функцию, которая принимает const, то есть не должна менять значение. Оптимизация есть.

Но внутри функции v оптимизации никакой не будет, от того что принимает функция const int* или int*.

Вроде в стандарте было написано что это зависит от реализации, зачем тебе это, знания о поведении достаточно, нет нужды знания о реализации.

const это не только ro память, а что более важно - ещё и зелёный свет компилятору на оптимизации. Ну зачем в fn(int *i, const int *p) каждый раз читать из памяти p, ему обещали константность

Ну и бредятина. От наличия const это никак не зависит

Могу в другом потоке в x писать, и мне ничего не будет.

Старый анекдот.

почему-то clang и gcc этого не делают, но могли бы

void f1(const int& i) { return f2(const_cast<int&>(i)); }

Не могли.

Все проверки делает компилятор С++

Какие проверки?

переменная располагается в области памяти, защищенной от записи?

Причём здесь C++?

Вот чтобы было ясно, как примерно думает компилятор:

1. Ок, есть функция v

2. Она принимает const int*.

3. Я не знаю её тело.

4. Если я передам в неё int, то функция может менять значение через const_cast

5. Если я передам в неё const int, то функция не может менять значение, иначе будет UB.

6. В программе нет UB, следовательно функция v, не может менять int

7. Следовательно можно снова не читать.

Если v, будет inline, то компилятор конечно заного прочитает и выведется 0.

Но если не знает, то рассматривает все случаи и выбирает наихудший, если где-то возникает UB, то всё что связано с UB, считает невозможным.

Скорее всего, зависит от реализации, как и всегда.
Вот тебе пример из gcc:

#include <stdio.h>

const int a = 1;

int main(int argc, char *argv[])
{
    const int b = 1;
    int *ap = (int *)&a;
    int *bp = (int *)&b;

    *ap = 2; // <- segfault
    *bp = 2; // <- ok

    printf("%d %d\n", a, b);
    return 0;
}

Если я передам в неё int, то функция может менять значение через const_cast
Если я передам в неё const int, то функция не может менять значение, иначе будет UB.

Легитимность снятия const и модификации не зависит от наличия/отсутствия const в параметрах. Определено без const - можно снимать и модифицировать.

Ну да, я был не прав. Для меня это стало новостью. UB лишь при снятии константности с объектов, которые были с ней объявлены. Никогда const_cast вообще не применял, говнокод какой-то.

говнокод какой-то

100% проектов на C/C++.

Она принимает const int*.

Не, компиляторам насрать на const. Это дерьмо для дошколят - анализ на основе этой херни никто не проводит, да и им можно жопу вытереть даже в рамках языка.

зачем тебе это

Чтобы ответить на вопрос, что наличие const не дает никаких гарантий, что объект не будет изменен. Т.е. мне никто не мешает писать в память, где расположен const T.

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

Мешает, только наличие хинта у ссылки/указателя - никак и ничего не говорит о памяти.

Ты прав. Убрал в примере pavlick const, компилятор всё равно не стал читать заного

https://gcc.godbolt.org/z/4lP1K_

Блин и в чем тут разница? Ведь компилятор когда видит, что пытаются получить адрес const переменной, он не может заменять ее значением?

Что не дает компиляторы объекты const разместить в нем?

В нём - это в чём? Срочно перечитывать букварь перед тем как срывать покровы.

Что мешает? Есть массив константных объектов, получаю адрес начала массива и пишу с некоторым смещением, константных объект будет испорчен. А если массив лежал бы в ro области, по программа упала с ошибкой.

это более показательно.

Супершкалярный цпу все равно из кеша читнет и будет дешего.

В области, защищенной mprotect.

И? Это шиза. Тебе сообщили, что хинты к ссылке/указателю ничего не означают. Ты можешь брать константную ссылку на не-константную память. Это валидное поведение - перечитай букварь.

Никаких ro-областей нет - срочно в школу. Хочешь менять права доступа - меняй. Кто тебе не даёт?

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

Нету никаких областей. И никакой mprotect ничего не защищает. Прочитай полностью мануал для домохозяек.

Чо нет, когда есть? Ты опять обмазался интелолинуксом и вещаешь за все платформы?

С чего он должен что-то заменять?

Нет. Никакой интел тут непричём. Да и ничего, кроме линукса, не нужно. Это мусор для школоты. За исключением частных, не общих применений. Но мы о них не говорим.

Любой mmu реализован так. Области сдохли как несостоятельное дерьмо. А то, что, возможно, они в каком-то бездарном мусоре до сих пор существует - это ничего не значит.

Если ты не про mmu, то всем насрать. Разговор не об этом и эта почти никому не интересно, примитивно и не представляет какой-либо ценности.

Сам читай.

.rodata and .rodata1

These sections hold read-only data

А почему тогда если объявлять всё что можно const размер кода уменьшается?

Когда ты называешь что-то бездарным мусором, оно от этого не теряет экономической эффективности, и против нее твои слова пустышка. Мы говорим в общем, это лишь ты говоришь в частностях. При этом кукарекая, что речь не только об интелолинуксе. Тем временем поведение в сишке описано и реализовано тоже для общего случая, а не для твоих наколеночных бенчей.