LINUX.ORG.RU
ФорумTalks

Почему жабисты и растаманы лучше С++ников

 , ,


5

12

Кажется я понял основную причину, отчего у С++хейтеров постоянно исключения в деструкторах сыпятся и все падает. Почему у них память принципиально течет, и все сегфолтится. У них просто логика античеловеческая. Всё, что не запрещено, то разрешено, или все что не разрешено то запрещено - это две большие разницы, для этих существ неразличимые.

Показываю на примере undefined результата в случае переполнения int в С в компиляторе здорового человека и в компиляторе курильщика.

В компиляторе здорового человека под undefined behavior в случае переполнения int подразумевается, что человек напишет программу так, что переполнения int не будет потому что он предупреждён. Поэтому компилятор может применить к выражениям оптимизации, которые небезопасны в случае переполнения.

В компиляторе курильщика принято считать что раз у нас в стандарте написано что UB, значит мы имеем право генерировать непредсказуемые результаты в ходе оптимизаций.

А это не одно и то же. Оптимизации здорового человека не предполагают нарушения логики работы программы. Если у вас написано x&y то операция И должна быть выполнена. Там нет переполнения. Её надо выполнить, даже если по отдельности икс и игрек переполнились. Вы не можете убрать операцию только потому, что у вас int в качестве аргумента. Выражение должно давать правильный результат при допустимых аргументах, вот что означает undefined behavior у int при недопустимы аргументах.

Оптимизации курильщика же предполагают что выражение может дать непредсказуемый результат всегда. Они просто не понимают, почему так нельзя. «в стандарте написано». Ученым до сих пор непонятно, почему компиляторы курильщика не заменяют все выражения, содержащие int, на вызов random(). Возможно, курильщики просто не знают о существовавнии этой функции и генерят рандом руками на лету.

А теперь эти идиоты добрались до gcc и сломали его. Это печально. Если бы они так кошмарили свою жабку или раст, это было бы смешно и забавно. Но увы, зло пришло и на нашу землю.

А что касается исключений в деструкторах и прочей байды. Так это то же самое. Они просто не понимают почему нельзя. Не запрещено же. Они реально не понимают, зачем существует та или иная штука. Поэтому кстати у них и шаблоны атакуют и bloatят код. Люди просто не могут не «шаблонить». Зомбачи.

Поэтому жабакодеры и растаманы лучше С++ников. С++ гавно а жаба рулит и раст рулит. GC в каждый дом. Исключения в каждый деструктор. Потому что надо жить не по лжи.

Перемещено tailgunner из development

☆☆☆

Ответ на: комментарий от anonymous

Поэтому простыни я пишу не подобным персонажам - это не имеет смысла, а людям вменяемым.
И потихоньку аудитория меняется.

Допустим аудитория полностью поменяется :-) Все узнают правду и научатся генерить эталонные коды, будут смеяться над UB (и над Си++, лол) и прочей всякой глупостью :-) Что дальше? :-) Все будут делать великий проект? :-)

anonymous
()
Ответ на: комментарий от asaw

Если тебе действительно нужно сделать сдвиг с переполнением то есть специальная функция overflowing_shl

pftBest ★★★★
()
Ответ на: комментарий от ckotinko

давай так договоримся. оптимизация != нарушению работы программы. ок?

Что такое нарушение работы программы?

anonymous
()
Ответ на: комментарий от pftBest

Но правда

Ваши доказательства - в студию!

asaw ★★★★★
()
Ответ на: комментарий от anonymous

Люди верили, что шланг был быстрее гцц - уже не верят.

в обратное тоже не верят. Ни во что теперь нельзя верить....

stevejobs ★★★★☆
()
Ответ на: комментарий от asaw

Не вижу какое отношение это имеет именно к языку.

Самое прямое отношение, у раста нет своего стандарта как у С++, а вместо него язык описывает набор RFC. Так что то что написано в RFC это то как должен вести себя язык и компилятор.

pftBest ★★★★
()
Ответ на: комментарий от ckotinko

Нельзя «оптимизировать» так, чтоб нарушалась логика программы.

Присваивания переставлять тоже нельзя?

anonymous
()
Ответ на: комментарий от pftBest

Никто не обманывал, как раз в этом случае компилятор воспользовался UB чтобы убрать умножение.

Не так. Компилятор воспользовался не УБ, а фактом того, что программист не напишет УБ. И то это не точно, т.к. разница между int и uint может быть обусловлена не УБ, а тем, что переполнения uint частый юзкейс, что и послужило причиной отсутствия оптимизации.

В любом случае первого достаточно. Автор, и я то же - говорили о случае, когда компилятор видит УБ и используете УБ для генерации рандома. В данном случае нет ни использования УБ, ни генерации рандома. В этом и заключается обман.

Т.е. по определению автора этот случай это:

В компиляторе здорового человека под undefined behavior в случае переполнения int подразумевается, что человек напишет программу так, что переполнения int не будет потому что он предупреждён. Поэтому компилятор может применить к выражениям оптимизации, которые небезопасны в случае переполнения.

Я проверил и в данном(а значит и в других) случае гцц/шланг вообще клали на УБ(переполнение в данном случае) при свёртке. Нет никаких проблем и сложности это реализовать. При этом, если там влепить констехпр - они могут.

Это типичный пример того, как компиляторы вместо того, чтобы следить и генерировал логичный результат - решили на него забить и генерить мусор. В данном случае компилятор свернул код, там была явная логическая ошибка - переполнение, но компилятору насрать.

Давай ещё раз я поясню в чём штука( в чём обман). Если компилятор видит код и он валиден, то его можно воспринимать как код не содержащий УБ. Если же компилятор видит явное УБ и превращает код не в код, который бы получился не будучи там УБ, а в мусор - это «жабисткая логика».

И ты предоставил код, который компилятор просто интерпретировал так, как будто бы в нём нет УБ, а не код, который бы компилятор превратил в мусор. ВНИМАНИЕ, НЕ В КОД, КОТОРЫЙ НЕ УЧИТЫВАЕТ НАЛИЧИЕ УБ, А ИМЕННО В МУСОР.

anonymous
()

Шла пятая страница, крестовики продолжали взывать к здравому смыслу компилятора, как будто он человек и понимает, о чем они толкуют =)

stevejobs ★★★★☆
()

Оптимизации здорового человека не предполагают нарушения логики работы программы

Какое именно слово в выражении undefined behavior тебе не понятно?

А вообще, само понятие UB — совершенно чудовищная идея, которая не ведёт ни к чему хорошему. Но увы, в си UB на каждом шагу.

quantum-troll ★★★★★
()
Ответ на: комментарий от anonymous

ВНИМАНИЕ, НЕ В КОД, КОТОРЫЙ НЕ УЧИТЫВАЕТ НАЛИЧИЕ УБ, А ИМЕННО В МУСОР.

На что я тебе отвечу что в общем случае отличить одно от другого не возможно на этапе компиляции. Если бы это все было так просто, то компиляторы бы уже давно выдавали ворнинги на такие случаи. Но они этого не делают потому что люди не любят false positive.

pftBest ★★★★
()
Последнее исправление: pftBest (всего исправлений: 1)
Ответ на: комментарий от anonymous

Не так. Компилятор воспользовался не УБ, а фактом того, что программист не напишет УБ. И то это не точно, т.к. разница между int и uint может быть обусловлена не УБ, а тем, что переполнения uint частый юзкейс, что и послужило причиной отсутствия оптимизации.

Нет, все так, можно не выдумывать хилые отговорки вроде «частый юзкейс», тут все четко как в часах, переполнение знаковых - UB, переполнение беззнаковых 2's complement. Компиляторы очень строго следуют стандарту.

pftBest ★★★★
()
Ответ на: комментарий от quantum-troll

А вообще, само понятие UB — совершенно чудовищная идея, которая не ведёт ни к чему хорошему

UB позволяет коду работать быстрее, так что к чему-то хорошему все-таки ведет :)

annulen ★★★★★
()
Ответ на: комментарий от quantum-troll

А вообще, само понятие UB — совершенно чудовищная идея, которая не ведёт ни к чему хорошему

Ты эту идею просто не понимаешь. А не понимаешь ты её потому, что, как видно, не знаком плотно с ассемблером. UB возникает из-за того, что одни и те же логические конструкции на разных железках дают разные результаты, а не потому, что язык как-то не так определен. А искусственно приводить поведение разных железок к единому - значит убивать производительность ради культа полной определенности. Потому что железки разные тоже не просто так.

asaw ★★★★★
()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от asaw

UB восникает из-за того, что одни и те же логические конструкции на разных железках дают разные результаты, а не потому, что язык как-то не так определен.

Ну это ты погорячился, ++i + ++i ни от какой железки не зависит :)

annulen ★★★★★
()
Ответ на: комментарий от annulen

> if (this == NULL) таки поломали
Да, это они дали маху

Разработчики clang давно сделали эту оптимизацию, но ее пришлось откатить, потому что пришли ребята из V8 и сказали что у них все поломалось.

pftBest ★★★★
()
Последнее исправление: pftBest (всего исправлений: 1)
Ответ на: комментарий от annulen

Ну это ты погорячился, ++i + ++i ни от какой железки не зависит :)

Ещё как зависит. ++i - это именно железячная конструкция.

asaw ★★★★★
()
Ответ на: комментарий от annulen

Быстрее в 1.017 раз, ага.
Вот интересная статья: http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf
Она про то же, что и тред, но подробнее.

UB возникает из-за того, что одни и те же логические конструкции на разных железках дают разные результаты, а не потому, что язык как-то не так определен.

Для этого же есть unspecified behavior и implementation-depended behavior, не? А Стандарт никак не сводит UB к железкам.

quantum-troll ★★★★★
()
Последнее исправление: quantum-troll (всего исправлений: 1)
Ответ на: комментарий от asaw

Во-первых в пацанских архитекурах нет операции инкремента, так как она сводится к сложению с непосредственным аргументом, а во вторых суть этого прикола в точках следования, которых на уровне машкода не существует

annulen ★★★★★
()
Ответ на: комментарий от annulen

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

asaw ★★★★★
()
Ответ на: комментарий от asaw

f(x(), y()) - порядок вычисления значений x() и y() неопределен, и это сделано для увеличения свободы оптимизитора, а не из-за ограничений оборудования

annulen ★★★★★
()
Ответ на: комментарий от annulen

Нет, ну конкретно здесь это обращение к одной переменной/области памяти. А вообще вычисление f(x(), y()) - это UB или нет?

asaw ★★★★★
()
Ответ на: комментарий от annulen

Интересно было бы послушать мнение свидетелей секты полной определенности)

asaw ★★★★★
()

Для любителей Java рекомендую почитать или посмотреть про многопоточность: https://www.youtube.com/watch?v=iB2N8aqwtxc

TL;DR: если компилятор может доказать, что доступ к данным может быть осуществлён через гонку, то он может генерировать «ГОВНО».

vzzo ★★★
()

Эпик, просто эпик. Прослезился. Пеши исчо.

mersinvald ★★★★★
()

Шла пятая страница обсуждения, а ОП продолжал утверждать, что нашёл в gcc баг, так и не удосужившись привести способ его воспроизвести. Виноваты при этом во всём джависты. По-моему, по поциенту плачет Кащенко.

Softwayer ★★
()

Меня удивляет как до адекватных взрослых людей не доходит, что

int x = 8192 & y;
дающий отрицательный результат — ЭТО НЕ НОРМАЛЬНО, при любых обстоятельствах во внешнем контексте.

Но да, без пруфа выглядит как вброс. Осиль повторить баг и зарепортить, тогда будет конструктив.

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 2)
Ответ на: комментарий от mersinvald

Воспроизвести этот отрицательный результат так и не получилось. В какой из 60k строк у ОПа на самом деле косяк — неизвестно.

utf8nowhere ★★★
()
Ответ на: комментарий от utf8nowhere

Это не важно. Чтобы ни было в y, UB или не UB, отрицательного результата быть не может ни при каких обстоятельствах при применении бинарного И с положительной константой.

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от utf8nowhere

Дык при чем тут это? Что бы ни было в y, какие бы оптимизации ни были применены, даже если там unspecified, каким образом получается ОТРИЦАТЕЛЬНОЕ число? Не ноль, не мусор, отрицательное.

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Не ноль, не мусор, отрицательное.

Считай что там мусор, который выглядит как отрицательное число.

utf8nowhere ★★★
()
Ответ на: комментарий от utf8nowhere

это слева, а y то справа.

e.g. int32_t i = (char)(128 & 0xff);

asaw ★★★★★
()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от mersinvald

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

i36_zubov
()
Ответ на: комментарий от mersinvald

то есть я на аргументы и ранее до вычитания и применяю. а причина в том что гцц видит что и ранее применено, думает что линие биты уже похерены и херит само И.

i36_zubov
()
Ответ на: комментарий от i36_zubov

К тому как это делает GCC вопросов нет, вопрос: почему он так делает и зачем, раз это противоречит логике написанного кода?

mersinvald ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.