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

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

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

Кстати, тоже согласен. Разделение уже по сути есть, проблема в том что си старается усидеть на двух стульях. All heil to Rust... наверно

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

ага, Си заставляет обжабаных писать на Си говнокод. какой подлец!

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

Кстати, тоже согласен. Разделение уже по сути есть, проблема в том что си старается усидеть на двух стульях. All heil to Rust... наверно

Только раст неюзабильное гогно, максимум пойдёт на замену с без плюсов.

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

не очень понимаю, что в этом коде не так.

Читать не умеешь?

This is a violation of the C spec, due to type-based aliasing issues (the right approach is to use a union).

anonymous
()

Ты предлагаешь генерировать заведомо медленный код только для того, чтобы программы с ошибками не так громко падали? Эти оптимизации ведь не просто так придумали. В результате разворачиваний макросов и инлайнов функций в реальном коде вполне могут быть выражения, которые эффективно оптимизируются исходя из предположения, что код работает верно. И убирая недостижимый код компилятор ускоряет программы без ошибок.

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

О-о-о!

Я же говорю - это антилюди. У них логика другая в принципе. То есть вообще, на самом низком уровне.

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

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

я предлагаю генерить код, который отражает написанное в программе. это что, невыполнимое требование?

неужели так сильно полыхает пламя в сраке демонов, что при первой же возможности(даже фиктивной, созданной кривой трактовкой поведения int) надо срочно генерить говнокод? чо, сотона распирает изнутри?

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

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

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

А, попутал, это IDB и запрещено CERT-C. Тогда надо бы контекст смотреть.

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

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

люди в принципе не понимают, а что не так. они не понимают, что оптимизации != право на генерацию говнокода. это пизец. всех в раст, и чтоб не возвращались.

я даже так скажу: люди походу не особо то и думают. тут даже учебником логики сталинским не отделаться. просто перед нами говорящие животные. да они говорят и даже осмысленно говорят, но они не мыслят. это чистые «нейросетки».

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

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

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)

Для джависта Стандарт Языка и Стандарт Виртуальной Машины - библия и лучший друг.

Ты пишешь не на конкретной реализации, а в первую очередь на Стандарте.

Если какая-то хотелка, какой-то придуманный твой миф относительно языка/рантайма не описан в стандарте - значит результат этого выполнения может быть совершенно рандомный

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

В программе отражено то, что

В программе отражено то, что что написал я. Попробуй это осознать. В программе, которую написал я, отражено то, что я написал. В программе, которую написал вася, отражено то, что написал вася. В программе, которую написал петя, отражено то, что написал петя.

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

И да, я не могу выложить на лор весь код. просто потому что его 30+ строк и он вообще-то закрыт.

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

У тебя логика ассемблерщика. Ты просто не можешь писать на чем-то выше.

Почитай стандарт, осознай что такое абстрактная семантика, ужаснись и возвращайся в ассемблер.

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

жобс, нет никаких хотелок. есть шизоидная интерпретация стандарта Си шизофрениками от жабы, где можно как угодно колбасить int потому что якобы там UB.

блин, а ведь когда то кровавый Сталин хотел мучать школьников логикой, учебники даже напечатали. Прикинь бы сейчас кроме меня тут была армия жертв Сталина, что бы вы делали.

Ты что, реально не понимаешь чем оптимизация отличается от генерации говнокода?

А кстати, а кто нибудь знает как вообще происходит «оптимизация» в компиляторах? или тут только диванные теоретики от жабы?

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

Если что-то не описано в стандарте - значит результат этого выполнения может быть совершенно рандомный

Нет. Его (результата) просто не будет.

Для джависта Стандарт Языка и Стандарт Виртуальной Машины - библия и лучший друг.
Ты пишешь не на конкретной реализации, а в первую очередь на Стандарте.

Конечно это не правильно! Нужно писать для конкретной реализации! Даёшь glBufferData(bufId, bufSize, bufData, static_cast<GLenum>(rand())); во все движки! Ну а чО, в месе же работает (пока что).

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

Всё, что ты написал, это в лучшем случае набор байтов в кодировке UTF-8. Что эти байты означают — решает стандарт, а не ты. Попробуй это осознать. Сидят дядьки в комитете во главе со Страуструпом и решают. Ты тут вообще никаким боком. Ты можешь только внимать их изречениям и молиться на разработчиков компилятора, чтобы они тоже вняли. Всё.

Если тебе не нравится C++, сделай свой компилятор, какой-нибудь C+-, в котором не будет неудобных тебе мест, переименуй свои файлы в cpm, форкни g++ в g+-, откуси там мешающие тебе куски и живи счастливой жизнью, забыв про ужасный C++. Только не удивляйся, когда жаваскрипт будет обгонять твои бинарники.

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

Если тебе не нравится C++, сделай свой компилятор, какой-нибудь C+-

Уже есть - так появился мой любимый GoLang

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

я предлагаю генерить код, который отражает написанное в программе.

Есть модель языка/рантайма, и два разных исполнения могут быть эквивалентны относительно этой модели. Тогда оптимизирующий компилятор может менять код на любое из эквивалентных исполнений, которое ему может показаться более оптимальным

обычно имеется не просто равенство, а равенство в контексте. Например, если компилятор может доказать, что весь код в этом блоке можно сделать с помощью векторизации на процессоре, он просто снесет весь твой код и перезапишет совершенно другим. Если он сможет выставить предположения о типах значений, то он может переписать не только низкоуровнево, но и поменять логику работы с типами (не нарушая модели!). Ну dead code elimination понятно, итп

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

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

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

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

давай всё таки попробуем осознать вместе.

оптимизации не могут нарушать логику программы. оптимизации не могут нарушать логику программы. оптимизации не могут нарушать логику программы. оптимизации не могут нарушать логику программы. оптимизации не могут нарушать логику программы.

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

что такое ломать в нашем случае:

си говорит что (а вы же читаете только там где вам нравится), что «нормальные программы не содержат переполнений, поэтому мы оптимизируем блаблабла». это значит, что мы исходя из предположения об отсуствии переполнений оптимизируем блаблабла. это не значит что мы просто берем и выкидываем операции.

нет, ну я понимаю что есть такая штука как заведомо 1чные и 0вые биты. но вот конкретно их тут не было. был каст из double. да даже дело не в этом. ну правда, «неопределенный результат в случае переполнения» не означает что «неопределенный результат всегда». ну блин, я не могу сто раз подряд азы логики разжевывать на ЛОРе. надо или поверить в логику или скзать ей «геть, мы пишем на расте»

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

Нет никакой «логики программы», вы всё выдумали.

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

оптимизации не могут нарушать логику программы.

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

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

я не понимаю, при чем тут векторизация, кошка, и т.д. ты о чем вообще?

оптимизация не должна нарушать логику работы программы. при чем тут «интуитивно-понятное поведение»? если я делают операцию И, то в обнуленных битах я ожидаю видеть нули. Ну так работает логическое И здорового человека. Может быть в жаве нет так, я же не знаю. Мне честно говоря по херу что там «оптимизирует» компилятор - я хочу чтоб результат отражал то, что я ввел.

Если Си говорит что результат при переполнении неопределен, это не значит что результат в принципе не определен. Не? Это сложно понять? Пусть у меня нет переполнения. Почему генерится говнокод? Должен генериться код расчитаный на отсутсвие переполнения. Вообще ,каким хером оно уничтожает логические операции. вообще как это может быть. а хотя кому я это говорю.

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

я предлагаю генерить код, который отражает написанное в программе. это что, невыполнимое требование?

И твоя программа будет рабоать на 40% медленнее. UB позволяет делать оптимизации которые недоступны в других языках. Имменно благодаря UB язык C самый быстрый на этой планете.

Если тебе так сильно не нравится UB, то может тебе стоит перейти на языки в которых нету UB? Например Java, Rust, Go. Там код исполняется как ты написал, так как тебе и хочется.

Вместо этого ты называешь разработчиков gcc идиотами, за то что они делают что-то не так как в Java.

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

И твоя программа будет рабоать на 40% медленнее

почему ты так решил? а, наверно ты хотел сказать «твоя корректно работающая программа будет работать на 40% медленнее чем рандомная глючащая шайтан-арба». да, пожалуй. даже не знаю что тут возразить. слава шайтан-арбе.

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

приписываешь мне свои слова? скорее к врачу!

int i = 100500 * 100500 — действительно то же самое что int i = random()

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

Оптимизации по определению не могут испортить корректную программу. Если они портят твою программу значит она не корректна (содержит UB), и это твоя задача исправить ее, а не ждать что в компиляторе подставят костыль специально для тебя.

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

и да, я называю разработчиков gcc идиотами.

после того, как у них вконец развалилась в седьмой версии размотка констант, уже всё. дальше некуда. видимо толератнтость доконала. а тут еще такой ой.

ckotinko ☆☆☆
() автор топика

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

Если реально баг gcc - пойдет в багзиллу.

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

Неужели люди начали поднимать нормальные темы - это радует.

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

Я тут не буду говорить о том, что 99% экспертов не понимаю вообще что такое УБ - они не отличают операцию и результат.

На эту тему я уже срался с пацанами - есть основная отмазка - логика у всех разная. И естественно, что это бред т.к. не бывает разной логики - бывает логика верная и неверная.

Пример прост. В рамках верной логике компилятор при оптимизации подобных конструкций руководствуется неопределённым результатом выполнения неких конструкций/операций. Т.е. всё это строится на ОПРЕДЕЛЕНИИ НЕ ВАЛИДНОСТИ КОДА, что есть ошибка. И тут возникает логичный вопрос - какого хрена? Почему в одном случае не валидность трактуется за ошибку, а в другом нет?

Это такая же семантическая ошибка, как и любая другая. И имея такое поведение компилятор с таким же успехом мог просто игнорировать невалидный код при сборке программы - почему он выдаёт какие-то ошибки?

Всё это имеет смысл только в том случае, когда мы придерживаемся логики «неопределено != не валидно». В этом случае нельзя никак руководствоваться стандартом для определения валидности результата данных операций. По идее так было и так должно быть.

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

Именно это и называется нелогичностью. Да и вообще - ЗАЧЕМ ВООБЩЕ оптимизировать код с ЗАРАНЕЕ НЕ ИМЕЮЩИМ СМЫСЛА РЕЗУЛЬТАТОМ. Это не имеет смысла. Именно про это ты и писал, когда говорил про замену инта на рандом.

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

Оптимизации по определению не могут испортить корректную программу

скажи пожалуйста, оптимизации делают непогрешимые ангелы на неглючащем компиляторе, или мы все таки говорим про реальный мир?

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

оптимизации делают непогрешимые ангелы

Нет, но ты ведь используешь компилятор не из гита, а стабильную сборку не самой свежей версии. Шанс что там будет баг очень мал.

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

I-Love-Microsoft is not in the sudoers file. This incident will be reported.

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

у меня правда большой кусок, и я сам не очень понимаю чем оно триггерится

ну вот у нас есть арктангенс:

inline int atan2i(int n, double x, double y) {
    return int(atan2(y,x)*(double(n)/M_PI)) & (n-1);
}
n=8192 и это константа.

только дело не в нём. оно превращается в говно в более крупном коде, который на 300 строк, и вызывает функцию в том же файле, где и происходит писец. чисто по коду этого быть не должно никак. там даже на входе в функцию где уже появляется минус стоит И. но после И у нас отрицательное число. по отдельности не получается.

я просто переписал всё на uint. ну честно я не понимаю. минус был даже сразу после &8191.

ckotinko ☆☆☆
() автор топика
Последнее исправление: ckotinko (всего исправлений: 1)

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

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

Си маленький достаточно. Ему не страшно.

А вот костыли к нему прикрутили зря. Си-с-костылями слишком жирный, уже не влезает в голову.

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

Оптимизации по определению не могут испортить корректную программу.

Ты пишешь абсолютный бред.

Некорректная программа НЕ ДОЛЖНА собираться. И тут не работает отмазка «компилятор не владеет результатом исполнения программы» - компилятор руководствуется при таких оптимизациях ИМЕННО что РЕЗУЛЬТАТОМ. При этом этот результат(компиляции) НИКАК и НИЧЕМ не определён.

Т.к. компилятор ЗНАЕТ, что он генерит ГОВНО и НИКАК на это не реагирует.

Так же это делает вообще бессмысленным такое понятие как УБ. Зачем нам пытаться определить поведение/результат, если мы заранее определяем его не валидность. В рамках такой логики в стандарте должно быть написано «операция при таких-то условиях не допускается», но она допускается - его результат не определяется в рамках стандарта.

И если он не определяется, то каким образом мы руководствуется определениями стандарта? Хотя это слишком сложно для тебя будет, но всё же. Разберу подробнее.

Если стандарт поведение НЕ ОПРЕДЕЛЯЕТ, то нельзя ССЫЛАЯСЬ на стандарт ОПРЕДЕЛЯТЬ его поведение. НЕЛЬЗЯ ИЗ НЕ ОПРЕДЕЛЯЕТ СДЕЛАТЬ ОПРЕДЕЛЯЕТ.

Давай ещё проще. Стандарт говорит «я не знаю» - компилятор говорит «не верно, потому что стандарт», но стандарт НИЧЕГО не говорит. Он НЕ ЗНАЕТ.

Так же, я уже писал об этом, но если «ошибка в программе не дело компилятора», то иди и выпиливай все ошибки в компиляторе.

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

мне честно в лом дампить GIMPLE из gcc и в нем копаться, тем более что я просто переименовал int в uint и всё заработало. но не может после &8191 на 32-битном компе и даже на 16битном получиться отрицательное число. у здорового человека. а вот у gcc может.

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

специально для тебя процитирую [defns.undefined] полностью и выделю жирным что должен делать компилятор:

behavior for which this International Standard imposes no requirements [ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. —end note ]

т.е. он может (имеет право) поступить как ты предлагаешь, а может и нет.

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

оптимизации не могут нарушать логику программы

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

вот в этой «настоящей логике» нет вообще ничего человеческого. Совсем. Ничерта. Она контр-интуитивная, развесистая, в самом глубоком бэкенде может меняться от процессора к процессору, от платформы к платформе, и так далее.

обычно прикладной программист никогда не знает этой логики! Он пишет исходя из каких-то своих мифов и верований.

понять прикладного программиста можно. «настоящая логика» безумно сложная, выучить ее без специальной подготовки невозможно. Да ладно, разработчики Скалы зачастую не могут понять, почему Скала выбрала то или иное решение

но и компилятор понять можно - он ничего не знает о эротических фантазиях прикладного программиста

этот мисматч между моделью в голове человека, и моделью языка/рантайма является основной философской категорией и инженерным компромиссом в компиляторостроении

представь такой «регулятор температуры», как на кондиционере. В самой низкой темппературе соответствует полная 1-в-1 компиляция, самой высокой - полный фарш на ассемблере

при построении компиляторов, в которых скорость - самое важное (Java, C++, etc), разработчики компилятора иногда жертвуют интуитивной понятностью некоторых вещей и выкручивают температуру в максимум

но это НЕ значит, что компилятор или рантайм нарушают логику работы

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

на прошлой странице я тебе подробно объяснил как работает гцц: разбирает выражение, наступает на уб и перестаёт его разбирать. с точки зрения оптимизации — однозначный вин: дополнительные инструкции никак не влияют на результат, потому что он может быть каким угодно.

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

я помоему с идиотами говорю. с такими вот сферическими эталонными идиотами.

мой вопрос: как можно взяв int, сделав И с 8191 получить отрицательное число. вы что все, шизофреники что ли или у вас как у собак павлова рефлекс на слово int?

кто нибудь тут вообще может понять что int != random?

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

И я не говорил про то, что он ДОЛЖЕН. Это ты сам придумал.

Мы говорил о логике, и поведение НЕ ПОСТУПИТЬ - ущербно и нелогично. Оно убого и КОНТРПРОДУКТИВНО.

Дак мало того - НЕ ТАКОЕ поведение НЕ ИМЕЕТ СМЫСЛА. ДОПУЩЕНИЯ стандарта НЕ ИМЕЮТ СМЫСЛА, если их трактовать как НЕ ДОПУЩЕНИЯ.

т.е. ЗАЧЕМ ЧТО-ТО ДОПУСКАТЬ, ЕСЛИ ПОТОМ МЫ ЭТОГО НЕ ДОПУСКАЕМ ССЫЛАЯСЬ НА ТОМ, ЧТО В «ДОПУСКАТЬ» ВХОДИТ И «НЕ ДОПУСКАТЬ».

У нас есть три варианта - запретить, разрешить и не определить. Разрешить мы не можем т.к. мы предполагаем определяем гарантии для всего того, что мы разрешаем. Да и раздует это стандарт не мерено.

Если же мы хотели ЗАПРЕТИТЬ, то нет смысла НЕ ОПРЕДЕЛЯТЬ. В данном случае НЕ ОПРЕДЕЛИТЬ - есть РАЗРЕШИТЬ, но НЕ БРАТЬ НА СЕБЯ ОТВЕТСТВЕННОСТЬ. Иное НЕ ИМЕЕТ СМЫСЛА.

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

с идиотом, всё-таки, говорю я :)

у тебя написано int i = <ub> & j;

результат этого выражения — <ub> (можешь рассматривать его как аналог бесконечности) хоть с &, хоть без

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

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

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

у тебя написано int i = <ub> & j;

результат этого выражения — <ub> (можешь рассматривать его как аналог бесконечности) хоть с &, хоть без

ахренеть. только в нашем цирке вы можете видеть людей с неаристотелевой логикой, а также женщину с бородой.

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