Дело не в глобальности, а в том, виден ли фактически ее «адрес» за пределами тр.юнита. Как там код будет выглядеть это вообще никак не связано с констом. Уехать в регистр может что угодно, а чтобы инициализироваться из imm не нужно быть констом.
Ирл гарантий нет, что тру-конст кинет трап по записи, но на всяких микроконтроллерах с например 64Кб рам и 1Мб флешкой - вот там консты могут лежать на ридонли флешке и траповать, афаик. В терминах линкера это секция rodata.
Но есть вызов mprotect() system call sets the access protections for the pages that contain the address range addr through addr + len - 1. Что не дает компиляторы объекты const разместить в нем?
Вполне возможно, что он их и размещает всегда в rodata, скомпиляй да проверь. Но какая память будет под этой секцией - решает системный линкер при запуске (если речь о более-менее десктопном цп, а не о мк, где прога шьется заранее). То есть у самого конпелятора тут голос совещательный.
const это не только ro память, а что более важно - ещё и зелёный свет компилятору на оптимизации. Ну зачем в fn(int *i, const int *p) каждый раз читать из памяти p, ему обещали константность.
В функции fn компилятор может оптимизировать, потому что он передаёт в функцию, которая принимает const, то есть не должна менять значение. Оптимизация есть.
Но внутри функции v оптимизации никакой не будет, от того что принимает функция const int* или int*.
const это не только ro память, а что более важно - ещё и зелёный свет компилятору на оптимизации. Ну зачем в fn(int *i, const int *p) каждый раз читать из памяти p, ему обещали константность
Ну и бредятина. От наличия const это никак не зависит
Если я передам в неё int, то функция может менять значение через const_cast Если я передам в неё const int, то функция не может менять значение, иначе будет UB.
Легитимность снятия const и модификации не зависит от наличия/отсутствия const в параметрах. Определено без const - можно снимать и модифицировать.
Ну да, я был не прав. Для меня это стало новостью. UB лишь при снятии константности с объектов, которые были с ней объявлены. Никогда const_cast вообще не применял, говнокод какой-то.
Не, компиляторам насрать на const. Это дерьмо для дошколят - анализ на основе этой херни никто не проводит, да и им можно жопу вытереть даже в рамках языка.
Чтобы ответить на вопрос, что наличие const не дает никаких гарантий, что объект не будет изменен. Т.е. мне никто не мешает писать в память, где расположен const T.
Говнокод - любое не-семантическое использование const. Но в основном пишут код дошколята, которые пропаганда рассказала про какой-то const и что им нужно обмазываться.
Что мешает? Есть массив константных объектов, получаю адрес начала массива и пишу с некоторым смещением, константных объект будет испорчен. А если массив лежал бы в ro области, по программа упала с ошибкой.
И? Это шиза. Тебе сообщили, что хинты к ссылке/указателю ничего не означают. Ты можешь брать константную ссылку на не-константную память. Это валидное поведение - перечитай букварь.
Никаких ro-областей нет - срочно в школу. Хочешь менять права доступа - меняй. Кто тебе не даёт?
Почему это не используется - это не нужно. Но а когда букварь почитаешь - осилишь понять, почему это и не реализуемо в общем случае. Хотя-бы мануал для домохозяек дочитай.
Нет. Никакой интел тут непричём. Да и ничего, кроме линукса, не нужно. Это мусор для школоты. За исключением частных, не общих применений. Но мы о них не говорим.
Любой mmu реализован так. Области сдохли как несостоятельное дерьмо. А то, что, возможно, они в каком-то бездарном мусоре до сих пор существует - это ничего не значит.
Если ты не про mmu, то всем насрать. Разговор не об этом и эта почти никому не интересно, примитивно и не представляет какой-либо ценности.
Когда ты называешь что-то бездарным мусором, оно от этого не теряет экономической эффективности, и против нее твои слова пустышка. Мы говорим в общем, это лишь ты говоришь в частностях. При этом кукарекая, что речь не только об интелолинуксе. Тем временем поведение в сишке описано и реализовано тоже для общего случая, а не для твоих наколеночных бенчей.