> Никак, раст это гугломайкрософтамазон, избавление от их влияния уже проходили например
> в андройде, ничем хорошим это не закончилось.Ну насколько я вижу по librust-* в дебиане, прошаренные господа с своим путем на все свой антидот найти в принципе могут, если захотят. Но как вариант - мне может зайти что-то типа zig или hare. Но точно не ады с хаскелями, блин.
> У всего есть слабые стороны.
И вопрос в том насколько оно далеко от моих хотелок, соответственно. И насколько проблемы под интересную мне проблематику фиксятся. А еще мне нравится curly bracket.
> Потому что типов нет. Есть байтики, а ты сам можешь их интерпретировать.
У процов нативно есть юниты N байтов за присест, т.е. u16/u32/u64/... - и при этом еще начинает интересовать видение проца в регистре vs в оперативе. Возникает такая штука как endianess. Это не пустой звук, если я пакет в DMA зарядил. Он то шлет "как в RAM было". А не как в регистрах считалось. А если мы в сериальный интерфейс данные шлем, на самом нижнем уровне кроме этого еще вопрос и какой _бит_ каждого _байта_ первый. Даже байт можно слать по разному. Старшим битом вперед или младшим ;).
А в C "int" трабл в том что мы не знаем сколько там битов. И байтов. Ведет к эпикфейлам в анализе граничных условий. А если кто удумает мандатом стандарта воспользоваться... ну вот на AVR можете заказать 16-битный int. Как вы думаете сколько кода потом работать будет правильно? По стандарту можно же. Де факто половина кода сломается.
> ВВОДНЫМИ. А в пределах одной программы и у сей никаких проблем нет.
Зато как только IO с внешним миром (сеть, файлы, интерфейсы, ...) становится очень уж не очень. Как платформенно нейтрально сериализовать "int"?! Никак?! Т.е. надо отдельно договориться что там столько-то битов? О конкретном формате signed? А в лоб в "int" вообще нини? Теперь вы догадываетесь почему появились (u)intXX_t... ибо "int" системщиков заманало в край на самом базовом уровне: мы даже не знаем хватит ли точности переменной для работы с вот этим полем пакета, например.
> Компилятор знает на сколько байтиков у него int, а всякие
> извращенные типы инта используются крайне редко на редкоиспользуемых архитектурах
Никак не облегчает участь при желании пульнуть пакет бит-за-битом в эфир из фирмвари вон того датчика с показаниями - ну, пусть, хотя-бы температуры за бортом (еще и signed чтоб вы не скучали). С файлами такая же ерунда.
> (а не только x64 и arm как на расте).
Что-то мне подсказывает что gccrs будет уметь почти все что умеет GCC. Минус совсем заброшенные архитектуры конечно. Во всяком случае был тут один кадр пытавшийся под AVR на расте. Ну а вы можете показать как под такого уродца на хаскеле и аде получается. У того гражданина хоть что-то получалось.
> (если уже не случились). Но смузипогромистов не знакомых с ассемблером
А, теперь я понимаю - вы шарахаетесь от асма в хаскел. Без особых промежуточных вариантов. Знакомый антипаттерн. Предпочитаю более сбалансированные варианты.
>> 1.1) Благодать с НОРМАЛЬНЫМИ типами вроде uintXX_t - на макросы и enum
>> не распостраняется! По крайней мере в цивильном и контролируемом виде.
> Не понял.
Что бы вы ни сделали, препроцессор не оперирует НОРМАЛЬНЫМИ, ПРЕДСКАЗУЕМЫМИ типами вроде "uint16_t" при вычислениях! Все числовые константы которые в нем встречаются (да, он умеет в математику и почти-тюринг-полный) работают более-менее эквивалентно "классическим" типам сей. Зафорсить там конкретную битность математики как C99? Щаз! И "enum" определен весьма фривольно, вкатив -Wconversion можно узнать много нового о своем коде. И как он делал не то что вы себе вообразили и не так. Зафорсить enum в конкретный тип? И даже с конкретными диапазонами? Чтобы баги в заполнении многочисленных констант ловить? Ишь размечтались. Существуют весьма неортодоксальные трюки с препроцессором позводяющим все-равно запилить компилтайм-чеки, и САБЖ даже даст мастеркласс как это. Но это через ж... в левый глаз и выглядит довольно мерзко в коде. В С11 еще компилтайм ассерты но препроцессор может и попродвинутее чем это, в большем числе случаев.
> Вот как раз integer promotion достаточно подробно описан в стандарте.
Да. Но он все равно контринтуитивный, дурацкий, и часто делает совсем не то что ожидал кодер.
> Большинство кодеров (подходящее слово) очевидно не читали его и не собирались,
И это было большой ощибкой с их стороны.
> но ВНЕЗАПНО он работает не так как они ОЖИДАЛИ. Ну знаете ли, многое
> работает не так как я ожидаю.
И это фигово. Инструмент не должен обламывать ожидания, ведет к куче багов на ровном месте.
>> такой код? Потому что он разваливается от тыкания палочкой.
> Уже обсуждалось. Специфичные условия чтобы развязать руки разработчикам компилятора.
Можно создать море проблем на ровном месте. Это один из способов - и это фигово. Я за то чтобы подкрутить в очередном C2x спеки и - прибить такой булшит на корню. Иначе раст прибьет сишников, вон то никуда не годится.
> В реальной жизни в рамках одной программы проблемы не встречается,
В реальной жизни даже тупенькая фирмварь погодной станции шлет одним процом температуру за бортом другому. И никто не обещал что там одинаковые процы, компилеры и проч. Про файлы, интерфейсы и сети даже и вспоминать неудобно.
> компилятор знает что у него UB и как на него реагировать,
А надо чтобы знал програмер. И имел конкретные ожидания поведения. Одинаковые на разных платформах. Тогда будет меньше глупых багов в математике.
> могут перекладываться по-разному, так это ВНЕЗАПНО всегда будет, хотя бы из-за
> разных архитектур (собственно поэтому и добавили UB).
И с этим явно перестарались. В ущерб всему остальному. А вот это уже фэйл.
> Мне и самому не нравится концепция UB, я считаю ее неудачной (да и авторы тоже).
Ну так либо починить - либо сишников замнет раст. Не вижу тут места для компромиссов, наслаждаться багами изниоткуда до упора мы, таки, не будем. Хоть там как!
> Но сишники уже на нее наступили, а раст...ее повторил!
В нем значительно меньше бестолковостей напрягающих в типовых случаях подводящих сишников.
> Уже описывал. Ну используй другой класс,
В сях нет классов, на минуточку.
> который при инициализации будет проверять контрольные
> суммы и поля и выдавать исключения
В сях нет исключений. Более того - это не самая удачная идея в кернелах, бутлоадерах и особенно фирмварях. Но я бы посмотрел на ваш фэйс когда ECU авто на скорости за стольник в исключение уйдет, и как вы это оцените по достоинству. Мы, кажется, про системщину? :)
> если байтики не похожи на класс, вот только заплатишь за это производительностью.
В системщине я не ОК с оверхедом в run time. И с исключениями тоже. Вы точно системщик? Кому и зачем нужны тормозящие и непредсказуемо фэйлящие системы?
> И в сях и в расте и в любом другом языке, потому что так работает
> процессор и ничего ты с этим не сделаешь.
Сгородив пачку проверок и предвычислений препроцессором я готов поспорить с этим утверждением. А Zig может предвычислить произвольное выражение на этапе сборки используя основной синтаксис ЯП. Так что наблюдаемые факты не подтверждают вашу теорию. И хотя это окучивает частные случаи, спасает от множества багов и/или сильно оптимизирует код.
> Ну а в рамках одной программы ты внезапно можешь этого не делать.
Вы задолбали одной программой. Даже в пределах 1 ОС программ сейчас сильно более 1 и они даже могут взаимодействовать. Если даже забыть про файлы, сеть, интерфейсы, и все такое. Хотя если про это все забыть то что останется то - особенно в системщине?
> Как и в любом другом языке. И в расте тоже
Моя претензия к сям что они по факту 100% сливают аннотацию без какого либо использования. А нехило бы обязать компилеры детектить левые доступы как минимум при предвычисляемых сценариях. ЧСХ вещи типа LTO optimizer отлично в курсе всех краевых условий. Только наружу знание вывесить не могут. В этом месте внешний интерфейс сей из стандарта клинит state of art компилеров.
> ты можешь использовать типы с bounds checking и подозреваю при грамотно
> написанном коде производительность будет выше чем в расте.
В сях нет типов с встроенным bounds checking, а если его в рантайм делать получится, извините, дотнет какой-то. Хотя для ряда статических сценариев когда и размер массива и индекс известны можно и проверить такие вещи. LTOшный оптимизер так половину кода выкидыает, ДОКАЗАВ что энные ветки кода никак не могут вызываться во всей программе вообще.
> Такие абстрактные вещи сказать про любой проект/ЯП и т.д..
В сях видите ли вообще по сути нет ABI на struct. Нельзя заявить struct в апи и потом получить interop в сколь-нить гарантированном виде. Более того - у gcc для ARM есть минимум 2 варианта ABI как передавать структы. Хотите вызвать функцию "bios" (boot loader, ...) с культурным, структурированным апи из основной фирмвари? Нннну, хотеть не вредно. Как вам требование что бут и фирмвара будут обязаны собираться 1 компилером с 1 набором флагов? Круто и интероперабельно. Давайте, еще раз булшит про "одну программу". Бутлоадеры же не нужны, а код реюз для лохов. Или нет?!
> "неструктурированный, неудобный, непонятный апи", даже сейчас во времена протобафа.
> Очевидно это больше психологическая проблема, чем технологическая.
Да вот нормальные сишники таки взмахнули факами - и таки struct всякие в апях юзать стали. А чтоб эффективно - как указатель. На вот именно конкретный тип. С typedef даже не так плохо получается. И код не очень мерзкий, и левак ему в отличие от void* уже не впаришь. Вот так у них в коде багов на порядок меньше чем у кодеров с "одной программой" видимо подвешенной в сферическом вакууме а потому не обрабатываюшей внешние данные вообще никак.0
> Вот тут согласен, все популярные компиляторы это !@#$%^, особенно gcc.
Это связано в основном с дурным определением этого хлама в стандартах. А сами struct плохо определены по выравниванию. Но вот тут есть __attribute__(()) и прочие pragma, а то что не стандартно... ну... если у вас не GCC, и даже не шланг - suxx to be you, just f...g die! Как-то так, да. Потому что packed struck форсанутый на конкретные адреса - позволяет таки по простому поработать с чем-то типа хардварных регистров и их вот блин реально отдельных битов.
> сишном llvm. Ну т.е. да, разобраться что и почему генерит компилятор
> это проблема, а раст ВСЕ ЕЩЕ УСЛОЖНЯЕТ.
Местами - да. Но это не выглядит фатальным. А вот определенные баги сей - особенно int безразмерный, не подлежащий сериализации, реально достали, вот честно.
> Уже писал. Не используй указатели где не нужны. Почему-то unsafe для тебя
> норм, а не использовать указатели по каждому чиху (что тоже своего
> рода unsafe) тебя не устраивает.
У unsafe есть жирный плюс. Это большой красный флаг места где я должен трижды проверить код этого господина что все ЗБС. А у сишника void* с безразмерным нечто - норма жизни, удачи в проверках что они сделали и как это совпало с намерениями вообще.
> не избавишься), например от макросов...еще все ухудшил и создал для макросов
> отдельный язык. Растоманы, вы больные. И лицемерные.
У сей препроцессор тоже видите ли не совпадает по синтаксису с основным яп. И никакого проигрыша нет. Дада, и "uint16_t" препроцессор сей сожрать в принципе не может. Мне больше всего нравится как это в zig сделано. Просто компилтайм вычисления, сразу основным ЯПом. Самое логичное решение, и самое крутое и гибкое.
Как злостному юзеру макро в С мне показалось что хрустиковские макро мощнее сишных. Хоть и инопланетнее в замен.
> В си другой механизм. Мне тоже приятнее отправлять пачку в return, но
> в итоге это вопрос привычки и вкуса.
Это вопрос отсутствия багов и кода который не выглядит как УГ.
> Так ты же можешь выбрать что-то одно и использовать.
В этом месте мы узнаем что one size doesnt fits all. Более того - что такое 1U может быть еще и платформозависимо, бжад. Не, конечно можно везде 1ULL ввернуть. К сожалению это настолко круто промотит все вычисления что резко деоптимизирует код. В самых критичных местах, типа операций с битиками регистров. Самое то - заякорить всю работу с периферией в пару раз. И вот выбирайте дескать между тормозами и прострелом пяток, дорогой сишник. А поприкольнее выбор нельзя ли? Чувствую что можно.
> 0b1111_0000.
Это кстати как раз весьма читабельно. А в именно сях это легально только в C23, кажется, и без разделителя. Хотя конечно все МКщники юзали GCC экстеншн со времен 99 и плевали на формальности. Потому что иные способы выражения констант для регистров железа не очень информативны.
> О, первый нормальный наброс и то случайный. В си и правда есть
> проблемы со строками. Их много. Конечно они не просто так появились
А потому что функции stdlib это окаменелое дерьмо мамонта. Которое давно надо было списать в утиль. Те варианты которые не чекают размер буфера calle'а и выносят все.
> используй умные указатели.
В сях нет никаких умных указателей. Можно конечно скроить себе самому много чего - даже функции для работы с строками. Что половина софта и делает. А дырявый мусор в stdlib зачем?!
> А я видел 2 аварии, переводим всех водителей машин на самокаты?
На лично мой вкус я бы сильно ужесточил экзамен на водительские права и сделал так что попадение в аварию серьезно дисквалифицирует виновника на тему управления ТС. Надолго. И вероятно с пересдачей экзамена как чайник. То что сейчас вытворяют некоторые двуногие на дорогах полнейшая жесть и ад.
> по unsafe дорогам" !@#$%, кэп, итак все нормальные люди так уже и делают.
Проблема с сями начинается в случае когда начинает хотеться предсказуемости, а булшит про 1 программу не взаимодействюущую с внешним миром начинает вызывать вопросы.
> Пока ни одну не услышал.
Да вот - память рушат реже, типы целых так то получше. А, еще и многопоточность кой-как все ж сделали.
И не надо меня плсами кормить. Это здоровый страшный урод. Который не си. И которому совсем не место в кернеле, фирмвари МК и проч. Во избежание. Потому что вот эти ваши экспешны там - ну совсем не айс например.
> Уже видно.
Ну дык, если GCC разовьется на эту тему - я подумаю. Кент вон тоже так считает. Я такой далеко не один имхо.
> Если вы пишете софт для АЭС на сях, то у меня плохие
> новости. И на расте у вас будут точно такие же проблемы.
На сях написана чертова куча критичных фирмварей и софта для всего чего угодно. Авиация, космос, автомотивщики, производства, вот это все. А если вы будете ждать фирмварь ECU на аде - будете пешком ходить, имхо.
> Не подскажешь где ваш софт используется, может я успею переехать?
Хехе фирмвари на сях много где используются. Вы будете пещком теперь ходить? Не, поезда, автомобили и проч - не для вас, там этого добра выше крыши. Вплоть до непосредственного кручения колес, как то управления мотором "от и до".
> Так он не для управляющих систем. Он для "типа управляющих систем".
И теперь мы собираемся избавиться от "типа" повысив гарантии...
> использовать специализированные RTOS. Т.е. RT в линуксе это "мы попробуем подтюнить
> линукс чтобы снизить задержки, но ничего не гарантируем". Где-то применимо, но
> далеко не там где нужны реальные RTOS.
В линух уже довольно много чего вкомитили на тему именно выдачи достаточно жестких гарантий, вида что на интервале X программа будет выполняться не менее Y. Это именно ртосовские гарантии. И там очень много оговорок и специфики. Вплоть до рефактора кода, блин, консолей. Дабы printk оптом таки не смог заякорить реалтаймный софт.
А когда мне жесткое реальное время надо - ну я могу себе фирмварь МК накодить. Там вообще весь камень может быть посвящен задаче и я могу менее чем микросекунду потрогать руками.
> Некоторые компании хотели бы больше контроллировать ядро и раст это очередная попытка,
Кодеры со своей стороны хотят меньше багов лепить. А вот именно контролировать - врядли особо получится, ядерщики пронырливые типы.
> раст явно не читаемый (си, кстати тоже).
Ну уж не фанатам хаскеля про читаемый код рассуждать.
> Вот только лучше пока не придумали.
А таки для меня раст смотрелся бы апгрейдом по ряду моментов. И даунгрейдом по другим. Но как я вижу в истории с кернелом - они не чужды решению проблем. Выгодное отличие от ISO.
> Поэтому при внедрении раста в линукс переизобретают растоманские примитивы?
У них было более 9000 костылей для именно си, задолго для всяких хрустов. Я оттуда половину идей бессовестно спер в окружения типа фирмварей, там компилтайм проверки и все такое очень кстати. А вы можете исключения кидать. В программах которые работают одним. Лучше это сделать в ECU вашего авто сразу, чтобы оценить как это офигенно в системщине.
> это домашний проект из двухтысячных который по-быстрому попытались привести к чему-то
> похожему на поделия конца двухтысячных, но который подхватили маркетологи и довольно
> успешно зафорсили.
А таки для меня это выглядит как инкрементальный фикс ряда проблем сей. Не, ваши ады и заскелы сеье оставьте, это не ко мне с их парадигмами и синтаксисом.
> Примерно то же самое было с php, ничем хорошим это не закончилось.
...но ничего лучше phpbb для форумов и mediawiki для вики так никто и не смог.
> не предлагая ничего взамен кроме как переставлять кровати (unsafe, встроенный в
> компилятор линтер, встроенные проверки в стандартные типы, да этот список даже
> смешно звучит, раньше бы я подумал что это юмористический язык).
Ну как бы в сях как раз половина проблем системщины из-за таких вещей и лезет. Скостить объем багов в разы - то что доктор прописал.
> Раст это не будущее, не решение проблем си (которые конечно есть, но
> в основном не те которые вы назвали).
КМК про си в свое время тоже вещали что-то такое. А паскалисты это и по сей день втирают. Правда, забыв накодить сравнимое со всеми этими фирмварями, бутлоадерами, ядрами, либами...
> Ваши предшественники это не деды. Это вы. Деды это Столлман, Ритчи, можно
> наверное Линукса туда запихнуть.
А кто сказал что вот у Столлмана такой уж офигенный код? И нет если багу влепил некто возрастом почти с столлмана и еще в C89 - это, очевидно, был не я. Я вообще в принципе менее чем C99 не оперирую. Такая ерунда.
> это ваш современник и вероятно он и дальше пишет код в другой шаражке.
Это реверанс про XFSника чтоли? А то передо мной увольняться некому - я сам себе режиссер.
> А ляпы в конструкциях раста вас не смущает? Или итераторы вместо индексов
> (которые тоже есть в расте) существенно меняют дело?
Хм, сделать итератором аналог отрицательного индекса в массив я бы уже напрягся. Как и последствия от всего сэмулировать в виде шарахания в совсем левую память.
> Ну меня в си магические символы не устраивают. Но конкретно в языке
> их не очень много и язык все же наследник, а зачем
> городить в новом языке такие символы не понятно.
Тут я даже согласен что усугубили грабли, но 1 раз в жизни я могу закорючки выучить если это разгонит эффективность и побустает баги.
> человека с узким кругозором (иначе он бы уже знал про питон например),
Я не желаю иметь ничего общего с питоном. И это уж точно не системный ЯП.
> Похвальное качество но раст в этом не помогает.
Это не вам судить. Да и работоспособных рецептов лучше вы не предложили.
> Который не знает что Linux RT это не RTOS
Который знает что в линух вкатили гарантии характерные для ртос. Что приближает его к именно ртосам по уровню гарантий.
> и вероятно не знает альтернатив?
Знает но - крепко не любит иметь с ними дело. Для себя я предпочитаю вообще выпихнуть low level на мк а линух - координатор. При этом можно избавить себя от сомнительной радости иметь дело с недо-ос.
> Который не знает как пишут софт с особыми требованиями к надежности?
И только опеннетовские посетители все в белом и мастеркласс в скромности дадут.
> Который знает проблемы указателей и стандартных типов, но не
> знает современных альтернатив и не использует их?
Удачи убедить препроцессор рассматривать числа как именно вот те современные типы. Ах, этот крап все равно будет трактовать 1ULL как нечто близкое к (unsigned long long) в результате?
> Который ругает си за проблемы, которых фактически нет у практикующих разработчиков,
Длинный список CVE что-то с вами не согласен.
> но про которые пишут новички столкнувшись с проблемами потому что учились
> по учебникам 1980ых переведенных в РФ в 2000ых?
Я уж точно не учился по этому хламу. А antibug для сей в рф вообще никто не преподаст. Этого знания у россиян вообще мизер. У вас больше апломба, в что-то практическое он не транслируется.
> Вы либо студент, либо начинающий разработчик какой-то
> шаражки, либо пришли из какого-нибудь особо высокоуровнего языка вроде джавы и
> не особо развивались.
"Играл но не угадал ни 1 буквы. Ход переходит к анониму!" :)
> Практически все что вы назвали сводится к теоритическим проблемам.
Это _практические_ проблемы доставшие меня и вон тех кодеров кернела. Но вы можете конечно рассказывать всем что проблем нет. Только не обижайтесь на то что за этим последует.
> Их часто ругают, но по факту они не столь влияют на работу. UB ну
> есть такое, есть предпоссылки почему они попыли в стандарт,
Мне похрен на предпосылки если это ведет к такому числу багов, вулнов и т.п. - пора пересмотреть эти предпосылки. И либо радикально починить - либо нехай вон те из rust, hare, zig и т.п. порубятся за звание "более хорошего си" если ISO совсем уж импотенты стали.
> успешно их обрабатывают. Да, можно встретить на конференции как какой-нибудь проженный
> сишник ругается на UB в стандарте в какой-нибудь специфичной ситуации из
> которой он вполне успешно на практике выходит.
Я не желаю видеть станларты с кучей UB, implementation defined и прочего крапа. И хочу чтобы long standing issues были решены. ISO это либо обеспечит, либо его сделают obsolete те же хрустики - или "убийцы хруста". Там уже очередь за головами - и таки имея на то веские причины. Все уже поняли что можно сильно лучше чем вон то, сохранив общую идею. Что бы вы там не вещали.
> Встроенные типы си из коробки были рассчитаны на производительность и простоту,
Это все булшит бинго. Даже просто прочитать "int" из файла это нечто ... почти нереализуемое в нормальном кроссплатформенном виде. И это уж точно не эталон простоты и производительности будет если файло захочется читать на других платформах.
> либы, есть отдельные гайдлайны по современному безопасному кодингу, потому что применений
> множество и разработчики стандарта си не ограничивают применение.
Да и как по мне настало время либо починить long standing BS который нагибает девов в планетарном масштабе - либо вон те займут нишу.
> кому-то под опеределнную архитектуру, а кому-то под определенные данные. Что должен
> сделать разработчик ЯП?
А ничего - опцией/сторонней либой/etc. В этом смысле то что си не стали чрезмерно отращивать stdlib как раз умный ход.
> В целом согласен. Но на мой взгляд комитет просто видит свою цель
> в строительстве нового языка, а в неполомании текущего.
Тогда их доломают хрустики или убийцы хруста. Сделав "как си только лучше и без топовых грабель оного". Выбор за ними как им там угодно. Я не вижу смысл принимать новый стандарт если он не чинит старые проблемы. Кому это надо и зачем?
> Очевидно что как только комитет начнет ломать ABI (как раст),
Да оно и так сломаное - а какой у struct abi? А, implementation defined, да еще с абы каким выравниванием по дефолту? Ох, круто, это конечно такое ABI...
> (и это не хипстеры-студенты, а целые устоявшиеся отрасли) успели переехать.
Устоявшимся отраслям между прочим никто не запрещает билдить с опцией что это C89 до сих пор, если они окей с тем качеством кода и багов вдруг. Правда это мы еще будем посмотреть кто там с чем ок, CVE нас уже таки подутомили, видите ли.
> и желательно без корпораций которые будут полностью контролировать закулисье ЯП.
Корпоряции мне тоже не нравятся. С другой стороны _полностью_ контролировать что-то они таки облажаются. Ну вон дебиан пакетит либы в своем варианте, gccrs вон той клике не подконтролен, контрол начинает разваливаться, опенсорс так и работает.
Вариант для распечатки
