Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, so5team, Вы писали:
S>>Как вы предлагаете сравнивать с nullptr ссылку?
ЕМ>(&ref != nullptr)
Вменяемый оптимизатор свернет это до true.
Ты в курсе одного из смыслов, что такое уб? Это когда ты делаешь что-то, чего по мнению оптимизатора не бывает.
Здравствуйте, rg45, Вы писали: R>P.S. Тут где-то Shmj шарахается неподалеку — вот это собеседник для тебя — в самый раз. Можете скипидарить мозги друг другу до одновременного огразма.
А ты был достаточно терпелив, особенно учитывая репутационный шлейф оппонента в разделе "С++". Не знаю, как он выступает в других областях, но тут же просто воинствующее невежество.
Я, право, иногда удивляюсь донкихотству некоторых коллег.
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>ссылка — это второе имя объекта, указатель — это другой объект. ЕМ>Не "это" ("является"), а "может рассматриваться в качестве", и то лишь на самых начальных этапах изучения, чтобы сформировать общую картину языка.
Разумеется в самом начале, ведь это базовое знание.
ЕМ>В большинстве же практических применений никуда не деться от того, что ссылка — это самостоятельный объект, занимающий место в памяти, копируемый при передаче, подверженный непреднамеренным искажениям и т.п.
Я знаю ровно один случай, когда ссылку можно исказить — это если поместить её в объединение и провести некоторые манипуляции. Во всех остальных случаях искажается не сама ссылка, а объект на который ссылка ссылается.
ЕМ>Так что под "идеологически" я подразумевал сугубо идеологию работы с ними.
Тому, кто отклоняется от этой идеологии иногда часами-сутками-неделями приходится искать причину падения программы при переходе на новый компилятор или просто при добавлении ключа оптимизации.
Здравствуйте, cppguard, Вы писали:
TB>>Потому что ты написал не то. В случае со std::string надо передавать std::string_view, а в случае с std::unique_ptr надо передавать указатель на внутренний ресурс при помощи get() C>std::string для примера был. А вопрос как раза про то, почему используют get() вместо передачи по ссылке?
Здравствуйте, Voivoid, Вы писали:
V>А я правильно понимаю, что практическое программирование это: V>"Пишем хоть какой-нибудь код который пусть хоть худо-бедно, но компилируется, чтобы наконец-то приступить к настоящей работе — отладке в debugger'е" ?
Здравствуйте, so5team, Вы писали:
S>Вы думаете, что UB куда-то исчезнет, если такое произойдет неявно?
Разумеется, нет. Но программа с явным присваиванием nullptr указателю, из которого затем получается ссылка, по определению является ill-formed. Если же такая ссылка в готовом виде приходит откуда-то извне (например, из системной библиотеки), то программа может быть well-formed, но столкнется с UB. Отсюда вопрос: на каком основании нам нужно пристально фиксироваться именно на этом варианте UB, а не на всех остальных возможных? Что говорит статистика о частоте UB именно из-за подобных ссылок? Она превышает частоту UB из-за обычных невалидных указателей?
S>у вас нет такой штуки, как нулевая ссылка. Легально, по крайней мере.
А я где-то предлагал считать такой случай легальным? Я говорю лишь о том, что он возможен. А началось все, напомню, с вопроса о том, что предпочесть для косвенной адресации объектов — ссылки или указатели.
S>Тут скорее речь о том, что не следует пытаться трогать жопу. Вообще. Не говоря уже о том, чтобы делать это голыми руками.
Все это очень напоминает поповские речи об "избегании греховного", а потом вдруг выясняется, что найти праведного попа — задача не из простых. Вывод — не следует делать из еды культа.
S>как говорят, UB в случае обращения к значению невалидного указателя появилось в языке Си (а оттуда и в C++) не просто так. А из-за наличия в прошлом архитектур, на которых указатели обрабатывались и хранились отдельно от других значений. Соответственно, попытка использовать значение указателя после того, как указатель был помечен как невалидный (в результате free, к примеру) проверялась на аппаратном уровне и приводила к порождению аппаратного прерывания.
Я таких страшилок читал в количестве. Их объединяет то, что их авторы, оперируя словами "архитектура", "виды памяти", "регистры" и т.п., лишь отдаленно представляют себе, как это все работает, но фантазию имеют изрядную.
Я такой архитектуры даже представить не могу. Хотя нет, представить-то могу — например, в виде специального учебного стенда, где нерадивого студента в случае UB бьет током или обрызгивает водой. В качестве производственной системы, на которой идет реальная работа — не могу, даже изо всех сил напрягая фантазию. Хотя бы потому, что автоматическая аппаратная проверка всех указателей и ссылок, хранящихся в памяти, обойдется неимоверно дорого. Это ж надо не только пометить тэгами все ячейки, в которых хранятся адреса, но и иметь аппаратную базу данных этих адресов. В примитивных архитектурах, где процесс всегда занимает непрерывную область памяти, еще можно проверять границы, но кто станет совмещать общую примитивность архитектуры с развитыми проверками указателей? Можно проверять на нуль и на выравнивание (там, где это важно), но тогда пропадет возможность осознанно хранить нуль в указателе.
А что делать, например, с традиционным для C и "неканонического" C++ способом перебора элементов массива, когда указателю присваивается адрес первого элемента и увеличивается до тех пор, пока не выйдет за пределы массива — как минимум, на адрес, следующий за последним элементом, но может выйти и дальше, если перебор не последовательный? Программ, использующих его, огромное количество, и они все должны не работать на таких архитектурах. Значит, многие из программ общего пользования там тупо не заведутся. А если это архитектуры сугубо специальные, вроде систем управления реакторами или космическими аппаратами, то для них и программы пишутся с нуля, и языки, как правило, используются более другие, нежели C/C++.
А хоть одна архитектура, заточенная конкретно под особенности ссылок C++, существует ли? Если да, то зачем?
Гораздо проще и практичнее было бы добавить в сишные/плюсовые компиляторы опции, заставляющие компилятор генерить дополнительные проверки, и я бы такое изо всех сил приветствовал. Но это делать как-то не спешат, хотя это было бы относительно недорого, но чертовски полезно.
S>Так что написанный вами сейчас код с UB в рамках "практического программирования" запросто может перестать работать уже буквально завтра. Или послезавтра.
Тут важно не забывать, что мы живем в мире, который управляется вероятностями, и устранять риски по мере убывания их вероятностей. Из каких соображений Вы заключаете, что вероятность именно такого поведения выше вероятности присутствия в коде скрытых ошибок, или ошибок компилятора, или ошибок системы, в которой будет работать код?
Все это мне сильно напоминает отношение к ГМО, канцерогенам, токсинам и прочим источникам священных войн.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А я где-то предлагал считать такой случай легальным? Я говорю лишь о том, что он возможен.
То, что он вожможен, понятно даже ежику. Тебе всем колхозом объясняют, что, если это случилось, то все дальнейшие телодвижения бессмысленны. Ты же как одержимый продолжаешь оживлять умерших.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Кодт, Вы писали:
К>Или кто пишет говнокод, после чего понимает, что технически ссылка ОТЛИЧАЕТСЯ от любой другой переменной.
Так я искренне хочу понять, чем ссылка технически (на уровне машинного кода) отличается от указателя. Есть возможность это сделать иначе, как медитируя на стандарт C++?
К>0 превращается в sizeof(SomeExtension)+padding для передачи внутрь CWnd::IsValid
Я вижу, что 0 везде превращается в 0. У меня есть кучка компиляторов MS VC++ с 1995-го по 2023-й, все они проверяют указатель на нуль перед преобразованием, ибо это стандартное условие для static_cast и dynamic_cast. Возможно, какие-то совсем древние компиляторы этого не делали — то ли из-за ошибок, то ли требований тогда еще не было.
К>надо сказать спасибо MSVC, который знает, что оптимизировать проверку this!=nullptr = всегда true ему запрещено.
Что значит "запрещено"? Чтобы ее оптимизировать, оптимизатору нужно как-то узнать, что this не положено быть нулевым. Сам он догадаться не сможет — в него должно быть явно добавлено такое правило. То есть, "запрещено" оно по умолчанию, пока не будет явным образом разрешено.
Но какой смысл добавлять такое правило? Если такая проверка встречается редко, ее оптимизация не даст ощутимого эффекта. Если же она встречается часто, то на это должны быть объективные причины, и ее тем более не следует оптимизировать.
Вообще, вменяемый оптимизатор работает с общими случаями, а не с частными.
Здравствуйте, T4r4sB, Вы писали:
ЕМ>>(&ref != nullptr)
TB>Вменяемый оптимизатор свернет это до true.
Во-первых — да и ради бога. Я несколько раз специально подчеркнул, что зависимости логики работы программы от таких конструкций не предполагается, они могут использоваться исключительно для контроля — в составе тех же assert'ов. А assert'ы обычно используются только в отладочном, неоптимизированном коде, в оптимизированном они чаще всего отключаются.
Во-вторых, вменяемый компилятор такое как раз не свернет, ибо такая конструкция не является типичной, часто встречающейся. Вменяемый оптимизатор работает прежде всего с общими случаями. Если он вдруг это свернул — значит, какой-то энтузиаст добавил в список правил "ссылка всегда ненулевая", и неплохо бы того энтузиаста спросить, из каких соображений он это сделал, и чего хотел добиться.
TB>Ты в курсе одного из смыслов, что такое уб? Это когда ты делаешь что-то, чего по мнению оптимизатора не бывает.
Угу. Но вменяемый оптимизатор ставит целью повысить эффективность работы программы, а не наказать программиста за нарушение положений стандарта.
Здравствуйте, B0FEE664, Вы писали:
BFE>Я знаю ровно один случай, когда ссылку можно исказить — это если поместить её в объединение и провести некоторые манипуляции. Во всех остальных случаях искажается не сама ссылка, а объект на который ссылка ссылается.
А я боюсь сбиться со счета, если начну перечислять, сколько знаю способов испортить ссылку. Ибо их ровно столько же, сколько способов испортить обычную переменную.
BFE>Тому, кто отклоняется от этой идеологии иногда часами-сутками-неделями приходится искать причину падения программы при переходе на новый компилятор или просто при добавлении ключа оптимизации.
Только если применяются какие-то очень редкие и заковыристые приемы. Но те, кто не понимает, как текст программы преобразуется в машинный код, такими приемами не пользуются, или пользуются в виде копипасты из чужих текстов, за что справедливо и огребают. Когда понимаешь, как работает эта кухня, то вполне представляешь, во что выльется та или иная конструкция языка.
Ну и кому надо, чтоб было абсолютно переносимо, и правильно компилировалось во веки веков, тот любые некошерные конструкции использовать не станет. А кому надо, чтоб работало на практике — с разумной долей вероятности, как и все в этом мире — тот обставит их проверкой на известные компиляторы/архитектуры, только и всего.
Здравствуйте, rg45, Вы писали:
R>То, что он вожможен, понятно даже ежику. Тебе всем колхозом объясняют, что, если это случилось, то все дальнейшие телодвижения бессмысленны.
Бессмысленны они исключительно в той прекрасной стране, где малейшее отступление от Стандарта карается немедленным умерщвлением. А там, где не молятся на Стандарт, а применяют язык на практике, существует ряд вполне осмысленных, а главное — эффективных, телодвижений.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Бессмысленны они исключительно в той прекрасной стране, где малейшее отступление от Стандарта карается немедленным умерщвлением.
Ну во-первых, не малейшее, а грубейшее — в данном случае. А во-вторых, другой страны не существует — для людей в здравом рассудке.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Во-первых — да и ради бога. Я несколько раз специально подчеркнул, что зависимости логики работы программы от таких конструкций не предполагается, они могут использоваться исключительно для контроля — в составе тех же assert'ов. А assert'ы обычно используются только в отладочном, неоптимизированном коде, в оптимизированном они чаще всего отключаются.
ReleaseWithAssert — слышал про такое?
Тут можно надеяться на санитайзеры, но никак не на ассерты.
ЕМ>Во-вторых, вменяемый компилятор такое как раз не свернет, ибо такая конструкция не является типичной, часто встречающейся.
В говнокоде?
ЕМ>Вменяемый оптимизатор работает прежде всего с общими случаями. Если он вдруг это свернул — значит, какой-то энтузиаст добавил в список правил "ссылка всегда ненулевая", и неплохо бы того энтузиаста спросить, из каких соображений он это сделал, и чего хотел добиться.
Он это сделал из соображений ускорить программу.
TB>>Ты в курсе одного из смыслов, что такое уб? Это когда ты делаешь что-то, чего по мнению оптимизатора не бывает.
ЕМ>Угу. Но вменяемый оптимизатор ставит целью повысить эффективность работы программы, а не наказать программиста за нарушение положений стандарта.
У оптимизатора нет цели наказывать программиста. Он должен закладываться на какие-то предположения, потому что иначе ему придётся, грубо говоря, каждое обращение к переменной компилировать в честное чтение памяти. Компилятор нихрена не может честно предсказать, была ли запись в данную ячейку памяти между двумя последовательными чтениями, вот невозможно это угадать, поэтому уме приходится предполагать, что при некоторых условиях записи не было. И он убирает второе чтение. И делает он это не из вредности, а потому что он должен опираться хоть на что-то. И поскольку это не руст, который позволяет делать предположения в стиле "если ты не налажал в унсафе, то адрес точно никто сбоку не портил", то у крестокомпилятора предположения более стрёмные. И ему приходится это делать, чтоб поддерживать имидж самого быстрого языка. По идее вся эта хрень экономит около 10% времени, но живём с чем живём.
Здравствуйте, T4r4sB, Вы писали:
TB>ReleaseWithAssert — слышал про такое?
Ага. Я поэтому и сказал "обычно", "чаще всего".
TB>Тут можно надеяться на санитайзеры, но никак не на ассерты.
Надеяться можно на то, что работает реально. Если какое-то требование озвучено, но в реальности не соблюдается, надеяться на него глупо — можно лишь принимать во внимание. Соответственно, делая assert'ы для кода, подлежащего оптимизации, нужно не только "писать код по стандарту", но и проверять, что получается после оптимизации.
ЕМ>>такая конструкция не является типичной, часто встречающейся.
TB>В говнокоде?
Термин "говнокод" слишком расплывчат, чтобы оперировать им в контексте обсуждения особенностей оптимизатора. Мне не приходилось видеть, чтобы конструкции вида (&r != nullptr) встречались в программах достаточно часто. А Вам?
TB>Он это сделал из соображений ускорить программу.
То есть, он видел достаточно много программ, где такие конструкции не только используются регулярно, но и значимо увеличивают потребность в ресурсах?
TB>Он должен закладываться на какие-то предположения, потому что иначе ему придётся, грубо говоря, каждое обращение к переменной компилировать в честное чтение памяти.
Спасибо, я имею некоторое представление о целях и методах оптимизации.
TB>крестокомпилятора предположения более стрёмные. И ему приходится это делать, чтоб поддерживать имидж самого быстрого языка.
Так я ж не спорю с тем, что в программах часто встречаются конструкции вроде (x != 0), и их совершенно логично преобразовать в одноадресные команды типа test вместо того, чтобы делать сравнение с явным нулем. И столь же часто встречается последовательное использование значения переменной, так что логично один раз загрузить ее в регистр.
Но все эти нюансы оптимизатор может вывести непосредственно из текста программы и сведений о целевой платформе, ему не требуются дополнительные условия вроде "this и любой ссылке положено быть ненулевыми". Чтобы такие условия могли использоваться, их нужно добавить в явном виде. Для этого, в свою очередь, неплохо бы иметь некий мотив, обоснование — например, оценку ожидаемого эффекта. Как бы Вы оценили ожидаемый эффект от таких оптимизаций, и на основании чего Вы бы это сделали?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Надеяться можно на то, что работает реально.
Санитайзеры, валгринд.
TB>>Он это сделал из соображений ускорить программу.
ЕМ>То есть, он видел достаточно много программ, где такие конструкции не только используются регулярно, но и значимо увеличивают потребность в ресурсах?
Ты очень плохо понимаешь термин УБ в контексте оптимизации, если думаешь, что оно работает как "давайте выкидывать такие-то сравнения".
ЕМ>Так я ж не спорю с тем, что в программах часто встречаются конструкции вроде (x != 0), и их совершенно логично преобразовать в одноадресные команды типа test вместо того, чтобы делать сравнение с явным нулем.
Это если компилятору не удалось доказать, что это не бывает нулём. И да, на таких доказательствах, которые зарыты более неявно, строятся многие оптимизации.
ЕМ> Чтобы такие условия могли использоваться, их нужно добавить в явном виде. Для этого, в свою очередь, неплохо бы иметь некий мотив, обоснование — например, оценку ожидаемого эффекта. Как бы Вы оценили ожидаемый эффект от таких оптимизаций, и на основании чего Вы бы это сделали?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Отсюда вопрос: на каком основании нам нужно пристально фиксироваться именно на этом варианте UB, а не на всех остальных возможных?
Не уверен что понимаю суть вопроса. Для меня он выглядит так "в C++ есть 101 способ выстрелить себе в ногу, так зачем нам обсуждать один конкретный, если остается еще 100?"
Если мы не стреляем себе в ногу одним конкретным способом (а именно не пытаемся убедить самих себя в наличии такой штуки, как нулевая ссылка), то у нас остается уже не 101, а всего 100 способов.
ЕМ>Что говорит статистика о частоте UB именно из-за подобных ссылок?
Давайте еще выводить значение sin(pi) на основании опроса людей на улице.
S>>у вас нет такой штуки, как нулевая ссылка. Легально, по крайней мере.
ЕМ>А я где-то предлагал считать такой случай легальным?
.
ЕМ>Я такой архитектуры даже представить не могу.
А я вот не могу представить, как можно демонстрировать такую непроходимую ту ограниченность, но при этом писать связные тексты в обсуждениях и, вроде как, даже писать работающий код. Однако ж...
Работать с указателем после его освобождения нельзя ни в Си, ни в C++. Это UB. Точка.
Разыменование нулевого указателя -- это UB. Точка.
Компиляторы могут не эксплуатировать какой-то UB десятилетиями. Как это было, например, с компиляторами C++ вот с таким UB до C++17 C++20:
alignas(T) char buffer[sizeof(T)];
file.read(buffer, sizeof(buffer));
T * data_object = reinterpret_cast<T*>(buffer);
Только вот UB это быть не переставало. И после добавления в C++17 std::launder принятия C++20 подобный код может оказаться поломанным в любой момент.
ЕМ>А что делать, например, с традиционным для C и "неканонического" C++ способом перебора элементов массива, когда указателю присваивается адрес первого элемента и увеличивается до тех пор, пока не выйдет за пределы массива — как минимум, на адрес, следующий за последним элементом, но может выйти и дальше, если перебор не последовательный?
Если руки из жопы, то разве что отдать этот код тем, у кого они растут из правильного места.
ЕМ>Из каких соображений Вы заключаете, что вероятность именно такого поведения выше вероятности присутствия в коде скрытых ошибок, или ошибок компилятора, или ошибок системы, в которой будет работать код?
Здесь важна не вероятность, а зона ответственности. Ошибки в компиляторе или run-time библиотеке вне моей зоны ответственности. А вот написанный мной код -- в моей. И если мой код теряет работоспособность из-за моих ошибок, то отвечать за это мне.
Прецеденты того, как работавший в прошлом код перестал быть таковым из-за оптимизаций в очередной версии компилятора, уже были. Очень наивно предполагать, что подобного не может произойти в будущем.
S>>Только вот UB это быть не переставало.
TB>Кстати, тут что не так? Если T это POD без указателей на таблицы, конечно. С алиасингом проблем тут нет, потому что один из типов — чар.
В C++20 добавили новые правила, которые позволяют "начинать жизнь" объектам вроде data_object. Если не ошибаюсь, то вот из этого предложения: https://wg21.link/P0593
