Здравствуйте, Кодт, Вы писали:
К>std::destroy_at(obj); К>// obj умер
К>read_some_data(buf); К>// obj снова жив?
Срочно нужна функция для проверки наличия души у объекта std::has_soul и изгнания демонов std::exorcise и библиотека стандартных обрядов <rituals>
Умер не умер какая разница, процессору фиолетово, там что биты переходят в Z состояние. Но компилятор надо ублажить иначе UB, а в случае UB компилятору позволено делать пакости, даже если на данной архитектуре никаких неоднозначностей не могло возникнуть. Имхо весь этот анонизм с присоединёнными сущностями к хорошему не приведёт. Если они нужны сделайте их явными и доступными по const_expr. А так в результате имеем разные данные по одинаковым указателям. И другие не наблюдаемые на железе чудеса, но которые компилятор не моргнув глазом воплощает в бинарный код.
Re[33]: Когда это наконец станет defined behavior?
Здравствуйте, rg45, Вы писали:
R>Это const — ненужный атрибут? Боюсь, найдется немало людей с противоположным мнениеем. И я в их числе. Вообще есть мнение, что const следовало бы сделать модификатором по умолчанию, а мутабельность прописывать явно.
Для это есть erlang где все переменные не мутабельные.
Здравствуйте, Кодт, Вы писали:
К>lifetime начинается с момента выделения памяти под объект типа implicitly created type, а делать реинтерпрет прямо сейчас или когда угодно позже — какая разница?
Байты пришли по сети и сохранились в буфер. Можно считать, что память выделилась? При этом тип объекта к которому мы кастуем, может меняться в зависимости от заголовка (как в примере).
_>Корме того что налагает обязательства на компилятор и требует дополнительных функций для разных модификаторов.
Что-то мне все труднее и труднее отслеживаться связь между тезисами. Какова цель вообще нашей дискуссии — ты хочешь меня в чем-то убедить, или ты хочешь, чтоб я тебя в чем-то убедил?
--
Справедливость выше закона. А человечность выше справедливости.
Re[33]: Когда это наконец станет defined behavior?
Здравствуйте, rg45, Вы писали: BFE>>Почему функциональность std::start_lifetime_as<T> и std::launder нельзя было бы повесить на reinterpret_cast<T> ? R>Я не понимаю, какое значение это имеет в данном контексте. Из этого как-то выводится, что
Не обязательно это рассматривать в контексте "const -- ненужный атрибут".
Рассмотрите, пожалуйста, этот вопрос шире: зачем мне, как программисту, иметь отдельно reinterpret_cast<T>, std::start_lifetime_as<T> и std::launder<T>?
Почему reinterpret_cast<T> не может делать работу std::start_lifetime_as<T>?
Почему reinterpret_cast<T> не может делать работу std::launder<T>?
Другими словами, почему список здесь
нельзя дополнить пунктом
12) if a pointer p represents the address A of a byte in memory
— an object X is located at the address A
— X is within its lifetime
— the type of X is the same as T, ignoring cv-qualifiers at every level
— every byte that would be reachable through the result is reachable through p
then
reinterpret_cast<T>(p) returns a pointer to the same memory that p points to, but where the referent object is assumed to have a distinct lifetime and dynamic type
?
И почему нельзя добавить аналогичный пункт для std::start_lifetime_as ?
К>alignas(T) char buf[sizeof(T)];
К>T* obj = (T*)buf;
К>// placement new не нужен, потому что T у нас implicitly created
К>
Удачи тебе с любым объектом, у которого есть внутренние инварианты. Например, с юником. В какой строке байтовый мусор из char[] превращается в валидный юник? Ну вот зануление указателя вот, в какой строке оно должно происходить?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[34]: Когда это наконец станет defined behavior?
Тут по сути ничем. А вот даже для итерирования по сету нужно жёстко запретить программисту менять ключи. Если это можно сделать на этапе компиляции, то почему б этого не сделать.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[35]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали:
TB>Тут по сути ничем. А вот даже для итерирования по сету нужно жёстко запретить программисту менять ключи. Если это можно сделать на этапе компиляции, то почему б этого не сделать.
Что бы запретить программисту жестко менять ключи ему надо выдавать область памяти которую он физически не сможет поменять (read only) или копию (что бы изменения ни на что не повлияли).
А так он преобразует const в не const и алга. А то что компилятор пытается это делать избыточно и не нужно. Всё равно есть обходные пути. Я к тому что не хрен указателю T* присовывать свойства которых физически нет.
Если они нужны сделайте явно complex_pointer<T> со всеми необходимыми атрибутами (выравниванием, правилами доступа, наличием "благословения" и жезненной силы) и правилами преобразования. Храните их в compile_time в шаблонах наздоровье. Но с возможность с ними взаимодействовать.
Но нет делается тоже самое, но все атрибуты скрываются под ковёр в результате сложность всплавает в компиляторе который быстро соображает что это UB и можно поиздеваться над программистом (так как можно делать что удобнее).
То есть программист должен знать не как работает железо, а что задумывает компилятор и чего там еще эти стандартизаторы напридумывали в последнем издании. И чем дальше тем более наркоманские оторванные от реального мира конструкции получаются.
ps: Если разделить виртуальное адресное пространство примерно так. То можно делать настоящие константные указатели и не только. Которые физически будут ограничивать указатели. Благо в 64битных системах свободных адресных бит более чем дофига.
[memory , npages] data вся достпная память программе
[memory+delta_ro , npages] замаплено на data только чтение (запись игнорируется)
[memory+delta_we , npages] тоже замаплено на data только вызывает исключение при попытке записи
[memory+delta_na , npages] при любом обращении вызывает исключение
Re[36]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>А так он преобразует const в не const и алга.
Не надо путать преднамеренную диверсию и невнимательность.
Так можно сказать что и руст ни от чего не защищает, ведь можно написать unsafe и алга.
Предполагается, что средний программист ХОЧЕТ писать безопасный безглючный код, но в силу человеческого фактора регулярно случайно косячит. Конечно, С++ программисты вовсе не такие, и никогда не ошибаются, если верить тому, что они про себя говорят , но мы будем умнее и не будем им верить.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[37]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали:
TB>Не надо путать преднамеренную диверсию и невнимательность.
так что мешает в названии переменной говорить программисту не менять переменную, зачем дополнительный тип.
TB>Так можно сказать что и руст ни от чего не защищает, ведь можно написать unsafe и алга.
Что самое интересное без алга не работает
TB>Предполагается, что средний программист ХОЧЕТ писать безопасный безглючный код, но в силу человеческого фактора регулярно случайно косячит.
Но стандарт разрешает компилятору верить что в коде который написал программист нет UB. То есть они никогда не косячат. И на основании этого ложного утверждения делает не вменяемые изменения в генерируемом коде. Иногда даже такие какие физически не возможны в принципе.
TB>Конечно, С++ программисты вовсе не такие, и никогда не ошибаются, если верить тому, что они про себя говорят , но мы будем умнее и не будем им верить.
Тут еще веселей правила постоянно меняются и дополняются.Так что то что раньше было норм и работало теперь лютое UB и надо помимо преобразования типа еще и благословение у компилятора выпрашивать. И программа обрастает обрядами и костылями.
Здравствуйте, T4r4sB, Вы писали:
TB>Удачи тебе с любым объектом, у которого есть внутренние инварианты. Например, с юником. В какой строке байтовый мусор из char[] превращается в валидный юник? Ну вот зануление указателя вот, в какой строке оно должно происходить?
Что мешает объекту быть в не валидном состоянии и при этом не вызывать UB. Можно добавить методы валидации или даже коррекции ошибок, когда не валидные состояния меняются на ближайшие валидные.
Re[38]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>так что мешает в названии переменной говорить программисту не менять переменную, зачем дополнительный тип.
А ещё лучше чтоб компилятор давал предупреждения, если программист меняет переменные, у которых такое специальное название! Чтоб ревью автоматизировать. А если лучше если это будут не предупреждения, а ошибки!
_>Что самое интересное без алга не работает
Как и с const_cast.
_>Но стандарт разрешает компилятору верить что в коде который написал программист нет UB. То есть они никогда не косячат. И на основании этого ложного утверждения делает не вменяемые изменения в генерируемом коде. Иногда даже такие какие физически не возможны в принципе. _>Тут еще веселей правила постоянно меняются и дополняются.Так что то что раньше было норм и работало теперь лютое UB и надо помимо преобразования типа еще и благословение у компилятора выпрашивать. И программа обрастает обрядами и костылями.
Ну сорян, сообщество С++ полно не очень вменяемых людей . И любимый заскок крестовиков — это неадекватная переоценка своей внимательности.
_>Что мешает объекту быть в не валидном состоянии и при этом не вызывать UB. Можно добавить методы валидации или даже коррекции ошибок, когда не валидные состояния меняются на ближайшие валидные.
И как ты провалидируешь юник, собранный из битового мусора? Ну в нём какой-то набор байт, который, возможно, какой-то указатель куда-то, и? Как ты поймёшь, что он валиден? В реальном юнике это постулируется тем, что мы вызвали конструктор и верим в то, что конструктор корректный.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[39]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали: _>>Что мешает объекту быть в не валидном состоянии и при этом не вызывать UB. Можно добавить методы валидации или даже коррекции ошибок, когда не валидные состояния меняются на ближайшие валидные.
TB>И как ты провалидируешь юник, собранный из битового мусора? Ну в нём какой-то набор байт, который, возможно, какой-то указатель куда-то, и? Как ты поймёшь, что он валиден? В реальном юнике это постулируется тем, что мы вызвали конструктор и верим в то, что конструктор корректный.
Для начала можно просто контрольную сумму добавить. Во вторых так собирают POD объекты без указателей, умных объектов и виртуальных таблиц.
Re[26]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
R>>Это const — ненужный атрибут? Боюсь, найдется немало людей с противоположным мнениеем. И я в их числе. Вообще есть мнение, что const следовало бы сделать модификатором по умолчанию, а мутабельность прописывать явно. _>Для это есть erlang где все переменные не мутабельные.
И где полно жизнерадостных хаков против этого типа словаря процесса, ETS, соседних процессов — хранителей состояния по своему настроению, или даже просто саморекурсии с исправленными значениями... а так да, можно сказать, что не мутабельные
The God is real, unless declared integer.
Re[22]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>Просто const тут многозначный атрибут и в разных ситуациях его трактуют по разному. Именно отсюда все беды.
Никаких бед нет — в каждой отельной ситуцации трактовка однозначна. Многие ключевые слова могут иметь различную трактовку, в зависимости от контекста использования: "const", "class", "typename", "using" и пр. Тебя же не смущает, что в следующих двух маленьких объявлениях ключевое слово "class" употреблено сразу в четырех(!) разных смыслах?
Константный объект с константным полем передаётся по константной ссылке!
Разве изменение такого объекта (через const_cast, placement_new итд) это не UB? Разве компилятор не вправе предположить, что после вызова bar в объекте по-прежнему останется единица?
Или тут внезапно случился конфликт высера стандартизаторов и реально существующей кодобазы, и компиляторы решили не наглеть?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
TB>Константный объект с константным полем передаётся по константной ссылке! TB>Разве изменение такого объекта (через const_cast, placement_new итд) это не UB?
Это будет UB.
TB> Разве компилятор не вправе предположить, что после вызова bar в объекте по-прежнему останется единица?
, но мы будем умнее и не будем им верить.
