Здравствуйте, kov_serg, Вы писали:
_>Атрибут const не мешает менять данные от слова совсем
Мешает, потому что навешивание mutable и всякие там const_cast заставляют испытывать муки совести задуматься, а не случайно же тут константность навешали.
Re[23]: Когда это наконец станет defined behavior?
у компилятора нет возможности отследить, но есть возможность гарантировать правильный результат.
Как и в любой другой оптимизации, в которой компилятор закладывается то, что программист идеально внимательный и не пишет код, содержащий UB. Как в том же стрикт алиасинге, например — компилятор не может доказать что адреса не перекрываются, но он может работать в режиме -fno-strict-aliasing.
R>P.S. Если рассматривать конкретно этот пример, то почему-то же программист написал "return l + a;", а не "return l + ll;". Вероятно, он знает, что после вызова функции bar значение объекта, адресуемого ссылкой "a", должно (или может) измениться и осознанно обрабатывает этот случай?
Ну это ж упрощённый пример. А в реальном коде может так оказаться, что программист поленился закешировать в локалку какое-то более сложное выражение.
Re[26]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>Атрибут const не мешает менять данные от слова совсем
Он уберегает программиста от случайного ошибочного изменения данных и в этом его главная миссия. Если программист использует const_cast, то он осознанно берет на себя ответственность за правомерность этих действий.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[24]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали:
TB>Ну это ж упрощённый пример. А в реальном коде может так оказаться, что программист поленился закешировать в локалку какое-то более сложное выражение.
Ну так кто ему виноват, что он поленился. Значит, запустит профайлер, увидит и исправит свою ошибку. Главное, что такая возможность у него есть в этом случае.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[25]: Когда это наконец станет defined behavior?
Здравствуйте, rg45, Вы писали:
R>Ну так кто ему виноват, что он поленился. Значит, запустит профайлер, увидит и исправит свою ошибку. Главное, что такая возможность у него есть в этом случае.
Ну тогда и стрикт алиасинг не нужен, программист профайлером поймёт, где лишние чтения из памяти, закеширует всё по локалкам и ускорит прогу.
Re[27]: Когда это наконец станет defined behavior?
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, kov_serg, Вы писали:
_>>Атрибут const не мешает менять данные от слова совсем
R>Он уберегает программиста от случайного ошибочного изменения данных и в этом его главная миссия. Если программист использует const_cast, то он осознанно берет на себя ответственность за правомерность этих действий.
И так для кого этот атрибут? Для компилятора или для программиста? При условии что вся ответственность,в любом случае по стандарту, сваливается на программиста.
В современном железе есть возможности гарантировать неизменность памяти, но нет возможности предсказать, то что наворотит компилятор полагаясь на своё понимание отсутствия UB в коде.
Re[21]: Когда это наконец станет defined behavior?
Здравствуйте, netch80, Вы писали:
N>const для объекта как источник предположения, что он не будет меняться, очень полезен.
Ничуть не полезен. Предположение о том, что объект, переданный "снаружи", не будет меняться там же ("снаружи"), следует не из наличия const, а из отсутствия volatile. Предположение о том, что объект не будет меняться вообще, можно делать лишь тогда, когда он создан сразу с const, и в нем нет mutable-членов.
Re[28]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали:
TB>Ну тогда и стрикт алиасинг не нужен, программист профайлером поймёт, где лишние чтения из памяти, закеширует всё по локалкам и ускорит прогу.
Мне кажется, у тебя сложилось не совсем верное представление, для чего те или иные сценарии объявляются как UB. Вовсе не оптимизации первичны в этом деле. UB объявляетя в тех случаях, когда компилятор не может дать гарантий корректности работы программы. И только потом уже эти сценарии используются как возможность для оптимизаций.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[28]: Когда это наконец станет defined behavior?
Здравствуйте, rg45, Вы писали:
R>Язык программирования нужен для программиста. Ваш К.О.
Это тоже надо было программистам:
std::bless<T> renamed to std::start_lifetime_as<T>, mutable const, std::launder и особенныех функций типа malloc, realloc.
Re[24]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>const — может быть только если данные лежат в ПЗУ или в памяти с запретом на запись.
Смысл const вовсе не в том, чтобы "физически гарантировать" невозможность изменения данных. Это указание компилятору: "по моему замыслу, в этой функции объект не будет меняться, поэтому, если я вдруг попытаюсь это сделать, дай мне по рукам". То есть, оно не для того, чтобы не менялось, а для того, чтобы своевременно обнаружить попытки такого изменения, нарушающие замысел автора.
Наверное, стоило бы дать этому атрибуту более подходящее имя, но в C/C++ с этим всегда было плохо.
А для того, чтобы размещать данные в памяти, недоступной для записи, есть совершенно другие средства — на уровне и компилятора, и линкера, и ОС/железа.
_>Вместо того что бы сделать возможность явно сообщать компилятору о допущениях, используемых в программе, его заставляют об этом самому догадываться по косвенным признакам.
Да, это давняя беда C/C++ — "сделаем сам язык как можно более простым и лаконичным, чтобы все остальное написать на нем". В начале 70-х это было вполне оправдано, но уже в 90-х стало анахронизмом.
_>мины заложенные ранее активируются постепенно, с увеличением версии стандарта языка.
Во многом потому, что стандарт языка набивают в основном "вторичным продуктом", который реализован средствами самого языка, но где-то снаружи, предлагая это "просто использовать", не заморачиваясь пониманием того, как оно работает. А сама идеология языка осталась в в 70-х, максимум в 90-х, когда без понимания внутреннего устройства нормально писать на C/C++ было невозможно.
По уму, в язык надо бы добавить побольше различных атрибутов и правил, позволяющих программисту в явной форме объяснить компилятору особенности своего замысла. Но на этом не словишь хайпа. В условиях, когда большинство не использует даже максимального уровня предупреждений, мало кто станет переходить на новую версию только потому, что она позволяет лучше страховать себя от ошибок. А вот перейти на версию, которая поддерживает локальные функции или сопрограммы — запросто, ибо "лямбды и корутины — это круто, это тренд, от них все прутся, значит, и нам это надо".
Re[30]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>Это тоже надо было программистам: _>std::bless<T> renamed to std::start_lifetime_as<T>, mutable const, std::launder и особенныех функций типа malloc, realloc.
Вероятно. Если ты располагаешь доказательствами обратного, то выкладывай.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[27]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали:
TB>навешивание mutable и всякие там const_cast заставляют испытывать муки совести задуматься, а не случайно же тут константность навешали.
Смысл mutable в том, чтобы с помощью const можно было защитить от изменения ключевые свойства объекта, позволив при этом честно меняться его второстепенным свойствам.
Простейший пример — объект имеет в составе критическую секцию, состояние которой при захвате всегда изменяется. Если функция, получившая константную ссылку на такой объект, захочет захватить его лишь для того, чтобы атомарно проверить несколько свойств, не изменяя их, она не сможет этого сделать без извращений, если не снабдить секцию атрибутом mutable.
Re[28]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>И так для кого этот атрибут? Для компилятора или для программиста?
Для того, чтобы они могли лучше понимать друг друга.
_>При условии что вся ответственность,в любом случае по стандарту, сваливается на программиста.
Именно поэтому я считаю, что любой серьезный язык должен иметь достаточное количество средств для того, чтобы программист мог донести до компилятора свои планы. Если компилятор что-то может вывести сам — это прекрасно, но лучше бы иметь это только по умолчанию, а при необходимости иметь возможность его поправить. И все, что может быть автоматизировано, должно быть автоматизировано. Раз компилятор "знает все" о том, что получится в результате компиляции, сам бог велел дать ему возможность знать еще и то, чего ожидает программист.
_>В современном железе есть возможности гарантировать неизменность памяти, но нет возможности предсказать, то что наворотит компилятор полагаясь на своё понимание отсутствия UB в коде.
Так не надо полагаться на const там, где нужна аппаратная неизменяемость. По крайней мере — понимать, в каких случаях компилятор может ее обеспечить, а в каких — реально это сделает.
Re[26]: Когда это наконец станет defined behavior?
Здравствуйте, rg45, Вы писали:
_>>std::bless<T> renamed to std::start_lifetime_as<T>, mutable const, std::launder и особенныех функций типа malloc, realloc. R>Вероятно. Если ты располагаешь доказательствами обратного, то выкладывай.
Почему функциональность std::start_lifetime_as<T> и std::launder нельзя было бы повесить на reinterpret_cast<T> ?
Здравствуйте, Ip Man, Вы писали:
IM>Из p0593, который был принят в C++20:
IM>Однако я не нашёл в стандарте C++20 упоминания, что reinterpret_cast может начать lifetime объекта. Хотя malloc и memcpy теперь легальны с этой точки зрения, т.е. этот пропозал был включён в стандарт, но обошли reinterpret_cast.
lifetime начинается с момента выделения памяти под объект типа implicitly created type, а делать реинтерпрет прямо сейчас или когда угодно позже — какая разница?
В пропозале другое сказано: невзирая на то, что у объекта может быть вырожденный деструктор, время жизни заканчивается после его вызова.
И вот тут возникает забавная дырка!
alignas(T) char buf[sizeof(T)];
T* obj = (T*)buf;
// placement new не нужен, потому что T у нас implicitly created
setup_something(obj);
process_something(obj);
write_some_data(buf);
std::destroy_at(obj);
// obj умер
read_some_data(buf);
// obj снова жив?
// или нужно явно сделать
obj = (T*)buf;
process_something(obj);
IM>>Из p0593, который был принят в C++20:
IM>>Однако я не нашёл в стандарте C++20 упоминания, что reinterpret_cast может начать lifetime объекта. Хотя malloc и memcpy теперь легальны с этой точки зрения, т.е. этот пропозал был включён в стандарт, но обошли reinterpret_cast.
К>lifetime начинается с момента выделения памяти под объект типа implicitly created type
Если такой объект создан. А создаётся он если это необходимо для придания программе определённого поведения.
К>а делать реинтерпрет прямо сейчас или когда угодно позже — какая разница?
Разница в том, что нужен launder вокруг reinterpret_cast. В примере в пропозале его нет. И пропозал не отменяет его необходимости.
Здравствуйте, B0FEE664, Вы писали:
BFE>Почему функциональность std::start_lifetime_as<T> и std::launder нельзя было бы повесить на reinterpret_cast<T> ?
Я не понимаю, какое значение это имеет в данном контексте. Из этого как-то выводится, что const -- ненужный атрибут
Перекуём баги на фичи!
