> может объяснить как же он работает, включая растоманов, ничего нового раст не предлагал.Еще нормальные типы, отсутствие UB, явное маркирование откровенно опасных операций. То на что тупарей из ISO никак прожать в сях не получается, особенно по ВСЕЙ площади вплоть до препроцессора, enum и прочих struct'ов. Мне похрен новое оно или как, меня решение практических проблем "в интерьере" интересует.
> Тогда нет математического доказательства и вся надежность сведется к "что
> нашли тестировщики".
Меня интересует отлов типовых массовых факапов. Никаие математические доказательства не знают правильно я сделал алго или нет. Может я еще в дизайне лоханулся. В этом смысле - десяток посмотревших в тривиальный код больше помогут. А вон то сложность подымает до небес. Начинают обходить, затыкать, мухлевать, и получается как с ариан5. С хрустом конечно тоже так можно но поводов меньше. И никому не интересны оправдания и переваливание ответственности, интересно чтобы этого всего не было а при этом начинают интересовать уже таки комплексные аспекты прожектменеджмента и сбалансированные свойства, а не утыки в погоню за идеалом ведущие к провалу в других аспектах.
> Впрочем и на хаскеле будут нюансы, например все равно придется уйти
> от чистых функций (и это точно такой же unsafe, так что
> не понимаю что с ним носятся растоманы).
На хаскеле по моему основной нюанс в том что потом кроме автора программы ее вообще читать никто не хочет и въезжать в это все. У меня тоже нет никакого желания вкуривать в крутые абстракции уникальные для 1 проекта на всю планету. А если чувак кодивший ECU модуль кода неверно поймет намерения коллеги, ничем хорошим это не закончится.
> Твои хотелки меняются каждую минуту. То тебе надежный код нужен. То тебе
> нужен си-стайл код. То тебе внезапно нужен gcc. Ты только в
> рамках этого треда успел несколько раз попрыгать.
У меня может быть более 1 предпочтения! И если тул сразу эн окучивает, это бонус в пользу тула. Представляете, это сложный комплексный процесс с интегральной оценкой факторов. От реюза знаний по "backend" до возможности других людей въехать в код и вероятностей что они поймут его правильно.
> Сочувствую. Сильно ухудшает читаемость, приводит к проблемам у новичков
Меня читаемость устраивает. Лучше чем у других. И к тому же печатать не сильно много а несовпадение скобок сразу хайлайтит что что-то пошло сильно не так.
> новичков - у школьников), замедляет написание кода (даже с подстановками от
> редакторов).
Да ничего оно не замедляет особо. И это, выделяет логические блоки, при том если при редактировани полблока снести случайно, или при копипасте лоханулись, это по крайней мере замечено будет. Сразу. А не через где-то в рантайме.
> когда программа могла состоять из одной строки или номер строки мог
> иметь решающее значение для выполнения программы.
Номера строк тут не при чем. Это про логическое выделение блоков - и контроль что блок существует атомарно, не вынесли часть случайно при редактировании, копипасте, вот это все.
> Си и не должен знать, потому что это стандарт, а не реализация.
> Реализация (компилятор) знает.
Я нахожу такой подход крайне неудачным. Спихивает все проблемы стандартизаторов и имплементеров на кодера. Это ведет к багам на ровном месте - 100% булшит.
> У тебя выбор либо пишешь под конкретный компилятор и конкретную архитектуру тогда
> твой код будет непереносим, либо пишешь непроизводительную программу под минимальный размер,
А хотели мы таки писать более-меенее портабельно, реюзабельно, шустро и без багов. Get the idea. Если до додиков из исы туго доходит, мы им популярно объясним какой у нас выбор на самом деле может быть. Может и без них - если с ними не получается.
> тогда проблем у тебя не будет, либо пишешь обобщенный код и
> всегда учитываешь что у тебя несколько архитектур.
Я использую типы из C99 и не имею глупых проблем. Но правила математики в си таки остаются кривыми и костыльными, а препроцессор и enum таки все равно грабли. И это утомило.
> Это принципиальная трилемма.
Принципиально это
1) Решать имеющиеся проблемы а не заметать под ковер.
2) Достигать нормального результата по общему набору свойств за разумное время.
3) Не заниматься откровенными идиотизмами и прыгом по минному полю.
> И си как язык общего назначения оставляет тебе решать что ты выберешь.
Я для себя уже и выбрал типы из C99 и ниже в принципе не оперирую. А "int" безжалостно выпиливается если вдруг попадается. И апи совсем иначе строятся.
> Раст же более ограничен и решает за тебя. Как я и сказал, раст предлагает старые
> методы с сомнительными и отвергнутыми побочными эффектами
> под новой упоковкой. Вот и вся разница.
Остальные вообще адекватных решений не предложили.
> Когда ты взаимодействуешь с внешним миром ты либо контроллируешь данные, либо нет.
> Если контроллируешь, то для тебя нет разницы что с внешним миром
> ты взаимодействуешь или в рамках одной программы,
Да, я захватил планету и на ней исключительно мои устройства с моими форматами данных. Разве не заметно? Про то что устройства могут делать более 1 производителя а на протоколы и форматы данных должны быть внятные спеки вы видимо не слышали.
> ты всегда знаешь в каком формате тебе придет, сколько байт и в каком порядке.
До первого хаксора который решит это палочкой потыкать, не загонит ли олд отрицательный индекс своим "int" куда.
> Если ты не контроллируешь данные, то тебе в любом случае придется договариваться
> или перепроверять.
И когда это типы фиксированной битности все почему-то проще а багов в цать раз меньше. Откуда и идея отправить горбатые типы на свалку истории и если не валить компил с error то как минимум warning кидать. Сразу минус 9000 багов на программу. Особенно если идиотские правила integer promotion и UB при signed overflow пофиксить.
> не быть теми данными которые пришли в твою программу. Например может
> поменяться порядок.
Вот это на самом деле сильно зависит от. В сериальном интерфейсе порядок ну вот не поменяется хоть там как. Чисто физически некуда.
> нет никаких проблем. На любой архитектуре на любом ЯП.
"int" в его изначальном определении - сериализации вот так по простому вообще не подлежит. Такая ерунда. И это фигово.
> Если ты контроллируешь данные, то пуляй с необходимыми преобразованиями сколько хочешь
> и проблем у тебя не будет.
Кроме того что этот код на другом проце сломается к хренам. И это источник багов.
> Если не контролируешь и не собираешься их проверять, то можешь дальше есть кактус и раст (и
> никто другой) тут тебе не поможет.
В расте по крайней мере доперли СРАЗУ сделать нормальные типы более годные для вон того - и не делать мозг "int" неопределенного размера что ведет к факапищам математики, IO и проч на всех мыслимых уровнях и тоннам CVE на этом поприще. А даунплеить это я таки вам не дам. Зело дохрена зафиксил такого чтобы игнорить топик.
> Вы с одной стороны топите за недежность и ругаете си за костыльность,
> но при этом форсите древний и довольно костыльный gcc.
Я форшу сбалансированное сочетание свойств и реюз знаний. Ну и шустрый и компактный код, нафиг мне в системщине дотнет очередной.
> Хаскель это не императивный язык вроде раста и си. И он не
> так сильно завязан на архитектуру и даже на систему (впрочем и
> си тоже может быть не сильно завязан, LLVM как пример).
Что-то мне подсказывает что от кадавра который постоянно жрет лучше отойти на безопасное расстояние. LLVM это капец на уровне архитектуры. Либа весом аж 80 мегов, с вообще всеми кодогенераторами подо все что можно одним куском? Концептуалы, с си++ жутковатым. Подмятые на двоих аж гуглем и эплом. Весьма такое себе.
> Я как раз больше использовал промежуточные варианты, а вот вы похоже плохо
> понимаете альтернативы и боитесь их.
Я предпочитаю разумный общий баланс свойств, реюз знаний по бэку тулчейна по возможности и проч. Видите ли, в системщине меня могут интересовать весьма интересные вещи. Вот вы когда-нибудь компоновали кастомно бинарник? С написанием линкер скрипта? А теперь покажите как вы это - в ваших альтернативах? И там бутлоадерок на этом - разложите? DMA транзакцию, с жестким контролем лэйаута памяти, времени жизни буфера, и формата данных - зарядите? Без всего этого булшита про взаимодействие сам с собой. Заодно и узнаете почему реюзать эти знания хочется.
А на чем-то с атмегу или cortex M0 - заведется? Без булшита про докупите проц пожирнее. Хотя за ваш счет я и суперкомпьютер, конечно, купить готов. А за свой - вот пардон.
> императивных и поэтому стали жертвой расторекламы, которая предлагает старые вещи под
> новыми именами.
Хрустики делом доказали что все вон то у них в принципе сделать можно - хоть иногда и с костылями и WIP. Покажите как оно у альтернатив вообще, чтобы про системность вообще заикаться.
> Потому что все что делает препроцессор это делает автозамены строк. Просто подстановщик.
Он еще умеет математику и условные операторы. И даже рекурсию до энного предела. Поэтому он "почти тюринг полный". Это по сути почти отдельный яп позволяющий весьма мощную логику.
> Отсюда и все его ограничения. Собственно поэтому он и ПРЕпроцессор. Вообще
> это дикий костыль, одно из худших решений в си, но раст СКОПИРОВАЛ его и СДЕЛАЛ ЕЩЕ ХУЖЕ.
Я не спорю что Zig прикольнее сделал. Но он позже вылупился. И имеет ряд своих дурных проблем.
> Если кодер не читал и не учил, то понятно что он НЕ ОЖИДАЛ. Ну тут ССЗБ.
Не облегчают нашу участь на тему кучи багов от ССЗБ-кодеров -> бесполезное по жизни знание.
> У вас одни ожидания, у меня другие. Чьи именно ожидания инструмент не
> должен обламывать?
Я буду ориентироваться на статистику по числу багов и общее состояние проектов в поиске ответа на этот вопрос. Если 90% обломается а 10% нет, мне наплевать входите вы в те 10% или где.
> никого не прибьет кроме себя.
Да пока вроде не собирается. Даже вон в gcc начальную реализацию втулили. Она еще не полная но таки - вот - уже есть.
> Никто и не обещал что оно будет работать. Либо контролируешь свои данные
> (например используешь протокол), либо нет. И раст тут не поможет.
Как минимум нормальные типы данных с самого начала багов в таком коде поубавят. Почему-то. А "int" в коде - это почти гарантия багованости - уж пардон. Чисто статисически. И мне похрен чем это вызвано. Это ФАКТЫ, спорить с ними, винить кодеров и проч контрпродуктивно.
> стали весьма сложные и програмеры стали сильно слабее. Тут замкнутый круг,
> одно ведет к другому и раст его только сильнее запутает.
Как показал натурный эксперимент, програмеры возомнив себя богами начали неимоверно лажать в этом самом. И загоняя очередной void* хзкакого размера и array[int] с чем-то отрицательным в индексе получается знатный й0пс с пантеона то. И вот у именно олдов зачастую самый поганый код, нубы более трезво свои скиллы оценивают и более параноидальны, а заодно и новые стандарты изучить не ломаются - и не доверяя себе чрезмерно предпринимают меры для отсутствия лажи если не ленивые. А ленивые вообще идут в питоняши и сишку не используют.
>> И с этим явно перестарались. В ущерб всему остальному. А вот это уже фэйл.
> Я тоже так считаю, но это скорее теоритическая проблема, чем практическая.
Это таки жесткая практическая проблема - куча багов изниоткуда на ровном месте. Стандарт или будет переделан - или писать софт будут на чем-то ином. Глупо получать левые баги за сам факт дурости стандарта.
> Так починили, но не в стандарте, а в реализациях.
Это не есть приемлимый на практике вариант имхо.
> Растоманы уже еще больше сишников бестолково лажают. Просто потому что они даже
> не слышали об алгоритмах, об структурах, об альтернативах, все что они
> знают это вот так создать переменную и как-то там с помощью
> магии какой-то борроу чекер что-то за меня проверит.
Ну вот это уже от кодеров зависит. Гунявый кодер на чем угодно гуняв конечно, чуда не произойдет. Но предпосылок для багов меньше при прочих равных. И мне нравится когда при дизайне яп это понимают, особенно если что-то вякают про системщину.
> ЯП может решить или улучшить, но по иронии раст ничего с
> ними не делает или ухудшает.
Вопрос еще и в цене которую приходится за то или иное действо платить и общий баланс.
> В perl тоже почти всю жизнь не было классов, но это не мешало их использовать ;)
И тем не менее в сях нет классов. Поэтому простой лаконичный код без левых багов - ага, ща.
> Мы про си. А на си я бы не стал делать ничего
> от чего бы зависила человеческая жизнь.
Это показывает насколько вы некомпетентны в вопросах системного программирования. Потому что есть. Работает. И этого - не просто дофига, а "почти все". Если теории не стыкуются с фактами - хреновые теории. Ну то-есть можно. Если захотеть. Но сложно. И с ограничениями. Типа дохреналиона правил MISRA намекающих на "удачность" дизайна ЯП.
> Исключение это всего лишь абстракция и она ничем не отличается от явной
> обработки ошибок и не может быть не самой удачно идеей. Другое
> дело конкретная реализация.
Это упрощает жизнь кодеру - ценой потери предсказуемости, что в системщине смерти подобно. Этим и плохо.
> Нет, я вообще не системщик.
Оно и видно. А какого черта вы лезете учить системщиков что им должно быть надо? Идите вон хирурга поучите как вас оперировать.
> В расте не ок с оверхедом и с тормозами и даже с предсказуемостью как показывает
> практика не ок. Но почему-то вы сюда свернули.
Ну как бы хруст даже в атмегу вон засунул 1 из местных. А вы так сможете с своими "альтернативами"? Если нет - тогда какие нахрен альтернативы и чему?! Явно не сям. И даже не хрусту. Такая ерунда - вы можете так же, или нет, это bool.
> Ну так предвычисли мне размер данных которые я отправлю только завтра.
Разумеется так можно обыграть не все. Зато можно очень крутой и годный препроцессинг оформить, тем же синтаксисом, и менее ограниченно. В сях с этим больше изврашений. Не, извините, на МК питаемом от мелкой батареечки я не могу навороченные вычисления - мелкая батареечка от них быстро сядет и юзер меня проклянет. Добро пожаловать в системщину - "energy-aware coding". Поэтому если что-то можно предвычислить и загнать результат - это нужно предвычислить.
> Совсем люди головой не думают. А заменить функцию из констант на константу
> так это еще паскаль делал когда я в школе учился.
В системщине хочется получать этот процесс явно и гарантированно. С четким отлупом на фазе компила если это вдруг сделать не удалось. Вместо ВНЕЗАПНОГО получения ломового жора батарейки вон той пакостью на ровном месте, с постоянной тряской над профайлингом. Мы вам тут не жабисты и не дотнетчики.
> То что константа может выглядеть как динамический класс это проблема конкретного ЯП.
В системщине хочется весьма конкретный и явный контроль над такими вещами. Например для energy aware coding. Когда я четко понимаю истинную вычислительную сложность вот этого вот - и сколько у меня батарейки в трубу с этого улетит, ага.
> Потому что все сводится к одной программе. Либо контролируешь данные, либо нет
> и тогда проводишь с каждой порцией данных разъяснительную беседу. Тут нет
> особо вариантов.
Примем как факт. В мире более 1 программы, данные мы не всегда контролируем - и в нем более 1 человека, вендора железа, протоколов и прчо. Поэтому мы хотим чтобы этот сценарий работал без гимора и багов. "int" в эту хотелку совсем не вписывается.
> Возможно дело в том что добавление в стандарт аннотаций приведет к тому
> что их нужно будет реализовать всем,
И вообще-то - да вы знаете - надо прожать этих господ чтобы не делать это проблемой ВСЕХ ВООБЩЕ. Если они так не могут - вот отлично! Это - легаси е...чее! Noncompliant. Которое не имеет право называть себя C2X. Пусть C99 декларят! Или что там они могут. А C2X сорец, вот, не соберется на этом хламе с совершенно законными основаниями. Заодно добавит желания поднапрячься и - заимплементить, вместо переваливания своих проблем на других. Иначе хрустики это за них сделают.
> а это не всем нужно и приведет к очевидному снижению производительности.
Как показал пример C99 - ничего там не снизится. Просто булшит надо вытряхнуть не наполовину а весь. А очевидно снизится - число багов. Со всякими отрицательными индексами в массивах бжад. Более того - в сях можно завернуть array -> struct и это даже работать будет. С вполне приличной эффективностью в общем то, если как указатель на тип передать. И даже - таки - будет злой typecheck. А почему сразу нельзя без этого извращения uint8_t[10] как конкретный тип рассмотреть и требовать везде вот именно это и так - кто б его знает. Просто легаси тупняк.
> А на уровне реализаций итак есть аннотации и если не ошибаюсь например
> clang может их вывести.
Аннотация вида u8[10] видите ли для машины и в общем то автопроверок, так то по задумке. Там где это катит. Си же так сразу сливает это знание в толч и не пользуется. То что кто-то где-то сбоку - ну, это уже не то. Это надо на гвозди, в стандарт, как mandatory. Тогда станет хорошо. А noncompliant'ы - не имеют право декларить стандарт. Прям так. Чтобы отделять мух от котлет и дидов с осточертевшим "int" от более нормального кода.
> Так в сях и то и другое есть. И либы с структурами с bounds checking и компиляторы с LTO.
Либы не катят - это в половине случаев работать не будет. Попробуйте такое на мк какой вкатить. Вот в компилтайме прочекать - оно как бы и там нормально будет. И да, вы ж не хотите фирмвару падающую в рантайм?! Поэтому чекать и считать в компил тайм все по максимуму.
> Само собой, потому что базовые структуры они на то и базовые, что
> не реализуют функционал который может не всем потребоваться. Используйте подходящие либы
> и инструменты.
Это все булшит. Я хочу видеть нормальные базовые типы. Предсказуемые и без UB. Точка.
> Даже на x64 знаю как миниум 3 варианта.
И это совсем не круто, между прочим.
> Ох уж это поколение смузи. Ну используй подходящую либу.
Вот когда вы это сами такие умные это все вот именно в ранний бутлоадер втулить попробуете - тогда с вами будет смысл разговаривать об этом. Представляете, там даже malloc какой делать еще может некуда быть делать - потому что DRAM еще не подняли, а SRAM с гулькин нос. И тут вы такой с своей либой. Даже если забыть что 80% клевых либ обгадиться собраться или адекватно работать в "freestanding". Когда попробуете что-то в этом режиме сей тогда и вещайте.
> Она тебе и проверки автоматически сделает и тесты и доку составит и либы сгенерит.
А заодно убьет понимание процессов кодером, привнесет более 9000 нежданчиков, в 80% случаев вообще не сбилдуется, а автоматические тесты окажутся наглухо неприменимы для фирмвари или бутлоадера с ядрами. А вот грабли зато #$%нут от души, каким нить рантайм еррором.
Я вообще хочу посмотреть как вы "либу" из бутлоадера будете с другой стороны звать. Это будет гимор на всю голову. Потому что для начала - вот вы же ABI и создаете наполовину. Типа call table какого, через которого вас вообще вызывать. И вот именно какие-то либы на этом пути резко прибавят гимора на раз.
> Почему ты хочешь этого от базового функционала языка общего назначения? Не
> всем это нужно, поэтому этого нет из коробки и не должно быть.
Я считаю сильно иначе - хрустики очень правильно нормальные целые типы оформили. Так как это должно быть в сях было.
> Все нулевые так и было. Сейчас стало получше,
В каком месте? С ABI Struct как был бардак так и есть. Сами же вон там написали.
> в принципе делает тоже самое, но со своим компилятором. Было 10
> проблем, стало 11.
У них как бы свои траблы тоже есть. Но они по крайней мере дали мастеркласс на тему что на самом деле надо было в сях сделать в ряде мест. И так то давно пора.
> Там то как раз есть протокол который определяет как бутлоадер будет дальше
> запускать код.
А что если я часть бутлоадера потом из кода хочу позвать? И да, прототип и там будет. Но если я захочу одупляемое API с чем-то типа struct вместо вашего окаменелого кала с void* - до чего уже даже САБЖИ доперли как и все минимально продвинутые сишники, вот с ABI этого таки будет много радости. По причинам которые вы сами же и озвучили.
> В этом нет никаких проблем ни для си, ни для ассемблера, ни для чего-либо другого
> потому что не надо контролировать данные.
Си вообще не дает прямой контроль над ABI вызова. Равно как и скажем не позволяет стандартно поместить вон то в конкретную секцию. Это пара мест где стандартный си таки сольет асму и это будет либо кусочек на асм либо экстеншн типа attribute((section)) какой.
> Структ и не должны быть определены по выравниванию, потому что процесс выравнивания
> в разных ситуациях по разному влияет на производительность и очень важен.
На мой вкус - нехило бы определить стандартный способ решения этого вопроса, когда надо именно packed. Иногда предсказуемость ABI важнее. И это, DMA автомат вообще гораздо эффективнее это все пошлет чем проц. Он даже трафик из кода на шине не создает, а вот дырки в данных ему не подарок, он блок данных от сих видите ли тягает. Посоревнуйтесь с ними в эффективности, ага! Думаете, за что мы лю DMA? Это хардварная асинхронщина - и весьма эффективная.
> Какую-то дичь вы пишете. int в си подлежит сериализации, иначе вы бы
> на линуксе не смогли бы пользоваться интернетом, например, потому что внезапно
> ваш драйвер сетевухи написан на си и скорее всего с int'ами.
И грабель по этой линии там скушали тыщи. САБЖ унутрях поэтому заводил сто лет к ряду свои кастомные типы, куда более вменяемые. А с переходом на C11 смогут, видимо, и не изобретать вел с квадратными колесами лишний раз.
> Unsafe это большой красный плащ конкистадора для быка програмера.
Не важно. Важно что заметный и хайлайтит место требуюшее внимания.
> Есть. В си препроцессор это жесткий костыль. От которого страдает и безопасность
> и читаемость и скорость компиляции. А в расте это еще более жесткий костыль.
Если в регистре было 32 бита, а препроцессор меня кастомной логикой жестко завернул с попыткой сунуться в 35-й бит, коего нет, на фазе компила - очевидно, фирварь безопаснее стала, ага. Потому что если бы этого не случилось, оно бы в рантайм сделало какую-то хрень в стиле олдов с отрицательными массивами, эта хрень не имела бы смысла и далее это undefined: програмер хотел невозможного, гарантировано-бажный код.
> Вас не смутило что в си макро подставляется препроцессором-подстановщиком, а в расте
> это ЦЕЛЫЙ ОТДЕЛЬНЫЙ ЯП В ЯП имеющего мало общего с самим растом?
В си это тоже по сути отдельный яп. Вы просто не видели что с ним сделать можно. От генерации предвычисляемых массивов констант для довольно сложной хрени до проверки параметров и констант в компилтайме. Простой пример:
const uint8_t ones[256] =
{
#define B2(n) n, n+1, n+1, n+2
#define B4(n) B2(n), B2(n+1), B2(n+1), B2(n+2)
#define B6(n) B4(n), B4(n+1), B4(n+1), B4(n+2)
B6(0), B6(1), B6(1), B6(2)
};
Да, это всего лишь автозамена. И немного математики. Даже условные операторы не поюзали еще. Те же ядерщики и поинтереснее умеют. Как вам генерация масок для операций длля битового поля от сих до сих на автомате? Да и проверить что в 35-й бит 32-битного регистра не влезли заодно можно. И да, железки опять же нативно маппятся в память как C99-style типы.
>> Это вопрос отсутствия багов и кода который не выглядит как УГ.
> Нет, это просто синтаксичесис никак на баги не влияющий.
Как тот кто загасил кучу багов из-за тупых типов я имею основания считать сильно иначе.
> Про одну программу я уже писал, тут тоже самое.
ИМХО Вы можете курить бамбук с одной программой. Это не от мира сего.
> И не должны чекать. Поэтому то она и СТАНДАРТНАЯ либа.
С чего бы стандарт должен быть дырявым гамном?
> Ох черт, что же ты такое. Ну так НЕ ИСПОЛЬЗУЙ СТАНДАРТНУЮ ЛИБУ
> ЕСЛИ ОНА ТЕБЕ НЕ ПОДХОДИТ. Это же очевидно.
Да вот тут еще есть пачка господ которых бы за вот это самое нехило бы захайлайтить как минимум жирным варнингом за юзеж вон тех функций. Потому что CVEшек в их поделиях лезет более чем. Постоянно. И это утомило.
> И ты опять попытался решить человеческую проблему техническими методами.
А таки частично работает. CAD чекает что я все подключил - вместо упования на внимательность. ERC/DRC чекает что фаба это сможет сделать и нет явных ляпов. Анализатор в компилере чекает что я не сделал что-то явно левое, где декларация и реализация явно разошлись. Машины должны помогать решать проблемы а не перепихивать все на человека и создавать проблемы.
> взятку и дальше будут разъезжать. Ну а остальные просто заполонят гибдд
> бесполезными очередями.
А, ну это решаемо, Судья Дредд показал как надо. Можно и автоматизировать - автоматическая туррель справится не хуже. А для надежности противотанковой ракетой можно подкрепить.
> Не рушит реже. Такие же типы как и в gcc например.
Да вот видите ли GCC таки может и хлам с "int" собирать. И хотелось бы хайлайтить такой код. Потому что статистически, там обычно полный хлам с математикой и граничными условиями. А на стандарты эти ваши олды как раз возлагали известно что.
> Но если бы ты попробовал плюсы, ты бы знал что эксепшены отключаемы,
> а современные плюсы гораздо интереснее по стандартным типа и по предвычислениям чем си.
Я их попробовал - но это еще более ужасное месиво, а для системшины вообще малопригодное имхо. Дада, я согласен с Торвальсом на этот счет. Получаются капец-ужастики.
