> Ну насколько я вижу по librust-* в дебиане, прошаренные господа с своим
> путем на все свой антидот найти в принципе могут, если захотят.Всегда можно найти свой антидот со своими побочными эффектами. Проблема растоманов в том что они находят старые антидоты с неподходящими побочными эффектами и преподносят их как новые. Собственно кроме борроу чекера, который никто не может объяснить как же он работает, включая растоманов, ничего нового раст не предлагал.
> Но как вариант - мне может зайти что-то типа zig или
> hare. Но точно не ады с хаскелями, блин.
Тогда нет математического доказательства и вся надежность сведется к "что нашли тестировщики". Впрочем и на хаскеле будут нюансы, например все равно придется уйти от чистых функций (и это точно такой же unsafe, так что не понимаю что с ним носятся растоманы).
> И вопрос в том насколько оно далеко от моих хотелок, соответственно. И
> насколько проблемы под интересную мне проблематику фиксятся.
Твои хотелки меняются каждую минуту. То тебе надежный код нужен. То тебе нужен си-стайл код. То тебе внезапно нужен gcc. Ты только в рамках этого треда успел несколько раз попрыгать.
> А еще мне нравится
> curly bracket.
Сочувствую. Сильно ухудшает читаемость, приводит к проблемам у новичков (ну как у новичков - у школьников), замедляет написание кода (даже с подстановками от редакторов). В нем был смысл в досишные времена магических символов когда программа могла состоять из одной строки или номер строки мог иметь решающее значение для выполнения программы.
> У процов нативно есть юниты N байтов за присест, т.е. u16/u32/u64/... -
> и при этом еще начинает интересовать видение проца в регистре vs
> в оперативе. Возникает такая штука как endianess. Это не пустой звук,
> если я пакет в DMA зарядил. Он то шлет "как в
> RAM было". А не как в регистрах считалось. А если мы
> в сериальный интерфейс данные шлем, на самом нижнем уровне кроме этого
> еще вопрос и какой _бит_ каждого _байта_ первый. Даже байт можно
> слать по разному. Старшим битом вперед или младшим ;).
Вот запомни свои слова.
> А в C "int" трабл в том что мы не знаем сколько
> там битов. И байтов. Ведет к эпикфейлам в анализе граничных условий.
> А если кто удумает мандатом стандарта воспользоваться... ну вот на AVR
> можете заказать 16-битный int. Как вы думаете сколько кода потом работать
> будет правильно? По стандарту можно же. Де факто половина кода сломается.
Си и не должен знать, потому что это стандарт, а не реализация. Реализация (компилятор) знает.
У тебя выбор либо пишешь под конкретный компилятор и конкретную архитектуру тогда твой код будет непереносим, либо пишешь непроизводительную программу под минимальный размер, тогда проблем у тебя не будет, либо пишешь обобщенный код и всегда учитываешь что у тебя несколько архитектур. Это принципиальная трилемма. И си как язык общего назначения оставляет тебе решать что ты выберешь. Раст же более ограничен и решает за тебя. Как я и сказал, раст предлагает старые методы с сомнительными и отвергнутыми побочными эффектами под новой упоковкой. Вот и вся разница.
> Зато как только IO с внешним миром (сеть, файлы, интерфейсы, ...) становится
> очень уж не очень. Как платформенно нейтрально сериализовать "int"?! Никак?! Т.е.
> надо отдельно договориться что там столько-то битов? О конкретном формате signed?
> А в лоб в "int" вообще нини? Теперь вы догадываетесь почему
> появились (u)intXX_t... ибо "int" системщиков заманало в край на самом базовом
> уровне: мы даже не знаем хватит ли точности переменной для работы
> с вот этим полем пакета, например.
Когда ты взаимодействуешь с внешним миром ты либо контроллируешь данные, либо нет. Если контроллируешь, то для тебя нет разницы что с внешним миром ты взаимодействуешь или в рамках одной программы, ты всегда знаешь в каком формате тебе придет, сколько байт и в каком порядке. Если ты не контроллируешь данные, то тебе в любом случае придется договариваться или перепроверять. Более того те данные которые к тебе отправились могут не быть теми данными которые пришли в твою программу. Например может поменяться порядок. Ты просто сериализуешь по выбранному протоколу и у тебя нет никаких проблем. На любой архитектуре на любом ЯП. Если в протоколе указн BE то преобразуешь (если требуется в BE), если указано 8 бит на поле, то делаешь необходимые преобразования для своей архитектуры, своего компилятора, etc.
> Никак не облегчает участь при желании пульнуть пакет бит-за-битом в эфир из
> фирмвари вон того датчика с показаниями - ну, пусть, хотя-бы температуры
> за бортом (еще и signed чтоб вы не скучали). С файлами
> такая же ерунда.
Если ты контроллируешь данные, то пуляй с необходимыми преобразованиями сколько хочешь и проблем у тебя не будет. Если не контролируешь и не собираешься их проверять, то можешь дальше есть кактус и раст (и никто другой) тут тебе не поможет.
> Что-то мне подсказывает что gccrs будет уметь почти все что умеет GCC.
> Минус совсем заброшенные архитектуры конечно. Во всяком случае был тут один
> кадр пытавшийся под AVR на расте.
Вы с одной стороны топите за недежность и ругаете си за костыльность, но при этом форсите древний и довольно костыльный gcc.
> Ну а вы можете показать
> как под такого уродца на хаскеле и аде получается. У того
> гражданина хоть что-то получалось.
Хаскель это не императивный язык вроде раста и си. И он не так сильно завязан на архитектуру и даже на систему (впрочем и си тоже может быть не сильно завязан, LLVM как пример).
> А, теперь я понимаю - вы шарахаетесь от асма в хаскел. Без
> особых промежуточных вариантов. Знакомый антипаттерн. Предпочитаю более сбалансированные
> варианты.
Я как раз больше использовал промежуточные варианты, а вот вы похоже плохо понимаете альтернативы и боитесь их. Вероятно вы не знакомы с историей ЯП, да и в принципе с видами ЯП за исключением популярных императивных и поэтому стали жертвой расторекламы, которая предлагает старые вещи под новыми именами.
>[оверквотинг удален]
> типам сей. Зафорсить там конкретную битность математики как C99? Щаз! И
> "enum" определен весьма фривольно, вкатив -Wconversion можно узнать много нового о
> своем коде. И как он делал не то что вы себе
> вообразили и не так. Зафорсить enum в конкретный тип? И даже
> с конкретными диапазонами? Чтобы баги в заполнении многочисленных констант ловить? Ишь
> размечтались. Существуют весьма неортодоксальные трюки с препроцессором позводяющим
> все-равно запилить компилтайм-чеки, и САБЖ даже даст мастеркласс как это. Но
> это через ж... в левый глаз и выглядит довольно мерзко в
> коде. В С11 еще компилтайм ассерты но препроцессор может и попродвинутее
> чем это, в большем числе случаев.
Потому что все что делает препроцессор это делает автозамены строк. Просто подстановщик. Отсюда и все его ограничения. Собственно поэтому он и ПРЕпроцессор. Вообще это дикий костыль, одно из худших решений в си, но раст СКОПИРОВАЛ его и СДЕЛАЛ ЕЩЕ ХУЖЕ.
> Да. Но он все равно контринтуитивный, дурацкий, и часто делает совсем не
> то что ожидал кодер.
Если кодер не читал и не учил, то понятно что он НЕ ОЖИДАЛ. Ну тут ССЗБ.
> И это фигово. Инструмент не должен обламывать ожидания, ведет к куче багов
> на ровном месте.
У вас одни ожидания, у меня другие. Чьи именно ожидания инструмент не должен обламывать?
> Можно создать море проблем на ровном месте. Это один из способов -
> и это фигово. Я за то чтобы подкрутить в очередном C2x
> спеки и - прибить такой булшит на корню. Иначе раст прибьет
> сишников, вон то никуда не годится.
В целом я согласен. Вот только сейчас ясно что раст никого не прибьет кроме себя.
> В реальной жизни даже тупенькая фирмварь погодной станции шлет одним процом температуру
> за бортом другому. И никто не обещал что там одинаковые процы,
> компилеры и проч. Про файлы, интерфейсы и сети даже и вспоминать
> неудобно.
Никто и не обещал что оно будет работать. Либо контролируешь свои данные (например используешь протокол), либо нет. И раст тут не поможет.
> А надо чтобы знал програмер. И имел конкретные ожидания поведения. Одинаковые на
> разных платформах. Тогда будет меньше глупых багов в математике.
Програмер знал бы если бы разбирался в компиляторе, увы, но и компиляторы стали весьма сложные и програмеры стали сильно слабее. Тут замкнутый круг, одно ведет к другому и раст его только сильнее запутает.
> И с этим явно перестарались. В ущерб всему остальному. А вот это
> уже фэйл.
Я тоже так считаю, но это скорее теоритическая проблема, чем практическая.
> Ну так либо починить - либо сишников замнет раст. Не вижу тут
> места для компромиссов, наслаждаться багами изниоткуда до упора мы, таки, не
> будем. Хоть там как!
Так починили, но не в стандарте, а в реализациях.
> В нем значительно меньше бестолковостей напрягающих в типовых случаях подводящих сишников.
Растоманы уже еще больше сишников бестолково лажают. Просто потому что они даже не слышали об алгоритмах, об структурах, об альтернативах, все что они знают это вот так создать переменную и как-то там с помощью магии какой-то борроу чекер что-то за меня проверит. А если ошибка, то это наверняка в unsafe. Увы, есть вещи которые ЯП решить не в силах, поэтому раст их не решит. Есть вещи которые ЯП может решить или улучшить, но по иронии раст ничего с ними не делает или ухудшает.
> В сях нет классов, на минуточку.
> В сях нет исключений.
В perl тоже почти всю жизнь не было классов, но это не мешало их использовать ;)
> Более того - это не самая удачная идея
> в кернелах, бутлоадерах и особенно фирмварях. Но я бы посмотрел на
> ваш фэйс когда ECU авто на скорости за стольник в исключение
> уйдет, и как вы это оцените по достоинству. Мы, кажется, про
> системщину? :)
Мы про си. А на си я бы не стал делать ничего от чего бы зависила человеческая жизнь.
Исключение это всего лишь абстракция и она ничем не отличается от явной обработки ошибок и не может быть не самой удачно идеей. Другое дело конкретная реализация.
> В системщине я не ОК с оверхедом в run time. И с
> исключениями тоже. Вы точно системщик? Кому и зачем нужны тормозящие и
> непредсказуемо фэйлящие системы?
Нет, я вообще не системщик. В расте не ок с оверхедом и с тормозами и даже с предсказуемостью как показывает практика не ок. Но почему-то вы сюда свернули.
> Сгородив пачку проверок и предвычислений препроцессором я готов поспорить с этим утверждением.
> А Zig может предвычислить произвольное выражение на этапе сборки используя основной
> синтаксис ЯП. Так что наблюдаемые факты не подтверждают вашу теорию.
Ну так предвычисли мне размер данных которые я отправлю только завтра. Совсем люди головой не думают. А заменить функцию из констант на константу так это еще паскаль делал когда я в школе учился. То что константа может выглядеть как динамический класс это проблема конкретного ЯП.
> Вы задолбали одной программой. Даже в пределах 1 ОС программ сейчас сильно
> более 1 и они даже могут взаимодействовать. Если даже забыть про
> файлы, сеть, интерфейсы, и все такое. Хотя если про это все
> забыть то что останется то - особенно в системщине?
Потому что все сводится к одной программе. Либо контролируешь данные, либо нет и тогда проводишь с каждой порцией данных разъяснительную беседу. Тут нет особо вариантов.
> Моя претензия к сям что они по факту 100% сливают аннотацию без
> какого либо использования. А нехило бы обязать компилеры детектить левые доступы
> как минимум при предвычисляемых сценариях. ЧСХ вещи типа LTO optimizer отлично
> в курсе всех краевых условий. Только наружу знание вывесить не могут.
> В этом месте внешний интерфейс сей из стандарта клинит state of
> art компилеров.
Возможно дело в том что добавление в стандарт аннотаций приведет к тому что их нужно будет реализовать всем, а это не всем нужно и приведет к очевидному снижению производительности. А на уровне реализаций итак есть аннотации и если не ошибаюсь например clang может их вывести.
> В сях нет типов с встроенным bounds checking, а если его в
> рантайм делать получится, извините, дотнет какой-то. Хотя для ряда статических сценариев
> когда и размер массива и индекс известны можно и проверить такие
> вещи. LTOшный оптимизер так половину кода выкидыает, ДОКАЗАВ что энные ветки
> кода никак не могут вызываться во всей программе вообще.
Так в сях и то и другое есть. И либы с структурами с bounds checking и компиляторы с LTO.
> В сях видите ли вообще по сути нет ABI на struct. Нельзя
> заявить struct в апи и потом получить interop в сколь-нить гарантированном
> виде.
Само собой, потому что базовые структуры они на то и базовые, что не реализуют функционал который может не всем потребоваться. Используйте подходящие либы и инструменты.
> Более того - у gcc для ARM есть минимум 2
> варианта ABI как передавать структы.
Даже на x64 знаю как миниум 3 варианта.
> Хотите вызвать функцию "bios" (boot loader,
> ...) с культурным, структурированным апи из основной фирмвари? Нннну, хотеть не
> вредно.
Ох уж это поколение смузи. Ну используй подходящую либу. Она тебе и проверки автоматически сделает и тесты и доку составит и либы сгенерит. Почему ты хочешь этого от базового функционала языка общего назначения? Не всем это нужно, поэтому этого нет из коробки и не должно быть.
> Как вам требование что бут и фирмвара будут обязаны собираться
> 1 компилером с 1 набором флагов? Круто и интероперабельно.
Все нулевые так и было. Сейчас стало получше, решили придумать раст, который в принципе делает тоже самое, но со своим компилятором. Было 10 проблем, стало 11.
> Давайте, еще
> раз булшит про "одну программу". Бутлоадеры же не нужны, а код
> реюз для лохов. Или нет?!
Там то как раз есть протокол который определяет как бутлоадер будет дальше запускать код. В этом нет никаких проблем ни для си, ни для ассемблера, ни для чего-либо другого потому что не надо контролировать данные.
> Да вот нормальные сишники таки взмахнули факами - и таки struct всякие
> в апях юзать стали. А чтоб эффективно - как указатель. На
> вот именно конкретный тип. С typedef даже не так плохо получается.
> И код не очень мерзкий, и левак ему в отличие от
> void* уже не впаришь. Вот так у них в коде багов
> на порядок меньше чем у кодеров с "одной программой" видимо подвешенной
> в сферическом вакууме а потому не обрабатываюшей внешние данные вообще никак.0
Не буду повторяться про одну программу.
> Это связано в основном с дурным определением этого хлама в стандартах. А
> сами struct плохо определены по выравниванию. Но вот тут есть __attribute__(())
> и прочие pragma, а то что не стандартно... ну... если у
> вас не GCC, и даже не шланг - suxx to be
> you, just f...g die! Как-то так, да. Потому что packed struck
> форсанутый на конкретные адреса - позволяет таки по простому поработать с
> чем-то типа хардварных регистров и их вот блин реально отдельных битов.
Структ и не должны быть определены по выравниванию, потому что процесс выравнивания в разных ситуациях по разному влияет на производительность и очень важен.
> Местами - да. Но это не выглядит фатальным. А вот определенные баги
> сей - особенно int безразмерный, не подлежащий сериализации, реально достали, вот
> честно.
Какую-то дичь вы пишете. int в си подлежит сериализации, иначе вы бы на линуксе не смогли бы пользоваться интернетом, например, потому что внезапно ваш драйвер сетевухи написан на си и скорее всего с int'ами.
> У unsafe есть жирный плюс. Это большой красный флаг места где я
> должен трижды проверить код этого господина что все ЗБС. А у
> сишника void* с безразмерным нечто - норма жизни, удачи в проверках
> что они сделали и как это совпало с намерениями вообще.
Unsafe это большой красный плащ конкистадора для быка програмера. Вот только пока бык бежит проверять unsafe конкистадор делает мемори лик в safe. Ну а в хорошем коде обычно итак критичные и бытовые вещи разделены на любом языке. Так что не будь быком, не ведись на красную тряпку.
> У сей препроцессор тоже видите ли не совпадает по синтаксису с основным
> яп. И никакого проигрыша нет.
Есть. В си препроцессор это жесткий костыль. От которого страдает и безопасность и читаемость и скорость компиляции. А в расте это еще более жесткий костыль.
> Как злостному юзеру макро в С мне показалось что хрустиковские макро мощнее
> сишных. Хоть и инопланетнее в замен.
Вас не смутило что в си макро подставляется препроцессором-подстановщиком, а в расте это ЦЕЛЫЙ ОТДЕЛЬНЫЙ ЯП В ЯП имеющего мало общего с самим растом?
> Это вопрос отсутствия багов и кода который не выглядит как УГ.
Нет, это просто синтаксичесис никак на баги не влияющий. Ну а с синтаксисом у раста еще большие проблемы.
> В этом месте мы узнаем что one size doesnt fits all. Более
> того - что такое 1U может быть еще и платформозависимо, бжад.
> Не, конечно можно везде 1ULL ввернуть. К сожалению это настолко круто
> промотит все вычисления что резко деоптимизирует код. В самых критичных местах,
> типа операций с битиками регистров. Самое то - заякорить всю работу
> с периферией в пару раз. И вот выбирайте дескать между тормозами
> и прострелом пяток, дорогой сишник. А поприкольнее выбор нельзя ли? Чувствую
> что можно.
Про одну программу я уже писал, тут тоже самое.
> А потому что функции stdlib это окаменелое дерьмо мамонта. Которое давно надо
> было списать в утиль. Те варианты которые не чекают размер буфера
> calle'а и выносят все.
И не должны чекать. Поэтому то она и СТАНДАРТНАЯ либа.
> В сях нет никаких умных указателей. Можно конечно скроить себе самому много
> чего - даже функции для работы с строками. Что половина софта
> и делает. А дырявый мусор в stdlib зачем?!
Ох черт, что же ты такое. Ну так НЕ ИСПОЛЬЗУЙ СТАНДАРТНУЮ ЛИБУ ЕСЛИ ОНА ТЕБЕ НЕ ПОДХОДИТ. Это же очевидно.
> На лично мой вкус я бы сильно ужесточил экзамен на водительские права
> и сделал так что попадение в аварию серьезно дисквалифицирует виновника на
> тему управления ТС. Надолго. И вероятно с пересдачей экзамена как чайник.
> То что сейчас вытворяют некоторые двуногие на дорогах полнейшая жесть и
> ад.
И ты опять попытался решить человеческую проблему техническими методами. Эти двуногие дадут взятку и дальше будут разъезжать. Ну а остальные просто заполонят гибдд бесполезными очередями.
> Да вот - память рушат реже, типы целых так то получше. А,
> еще и многопоточность кой-как все ж сделали.
Не рушит реже. Такие же типы как и в gcc например.
Реализовали один вид многопоточности со своими проблемами и забили на остальные. Как я и говорил очередное старое решение с побочками под новой упаковкой.
> И не надо меня плсами кормить. Это здоровый страшный урод. Который не
> си. И которому совсем не место в кернеле, фирмвари МК и
> проч. Во избежание. Потому что вот эти ваши экспешны там -
> ну совсем не айс например.
Но если бы ты попробовал плюсы, ты бы знал что эксепшены отключаемы, а современные плюсы гораздо интереснее по стандартным типа и по предвычислениям чем си.
