Mergiraf — новый движок разрешения конфликтов в коде

Я искал новые, менее дорогие и более доступные контроллеры, вместо PIC от Microchip, которые в последние годы стали менее доступными и сильно более дорогими в России. Нашёл китайские, 32 бит, RISC-V. Сижу от, С вспоминаю, поскольку давно ничего не писал, а там только С у производителя...

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

А второй, такой же, Rust для моих CH32V003 упомянул. Да, есть, но выбор в пользу Rust пока что никто и никак не обосновал... А я не уверен, что стоит вот так, просто, взять и сменить язык, на котором писал уже, на новый совсем для меня...

Выбирайте бейсик

Не, я его «с детства программистского», с 1980-х, не полюбил почему-то... :))

В 1990-х FORTH был «моё всё», но сейчас это, наверное, уже не то...

Так UB же разработчикам компиляторов дает карт-бланш реализовать любую логику , оставили бы доступ по null pointer. Стандарт же за это по рукам не бьет. Если бы nullptr был отдельной сущностью вне пула чисел, используемых в качестве значения указателя - это одно. Но повсеместно используется 0 как число для обозначения этого спец. указателя. За это время могли бы и адаптировать свои компиляторы

оставили бы доступ по null pointer.

Так это же UB, а UB в программах не бывает.

«…он если есть, то его сразу нет».

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

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

Сишечка — это просто культ боли

Нет, C — это просто инструмент. А тем, кто инструмент воспинимает, как «культ боли», думаю, стоит эту проблему (проблему восприятия) решать с соответствующими специалистами. С психологами или с психиатОрами — там сами (с ними, да) разберётесь. ;))

Вообще, перекладывать свою собственную проблему выбора рабочего инструмента — это само по себе проблема, которую, по моему мнению, индивиду стоит решать со специалистами «в области головы».

А уж когда он (индивид) склонен к внешнему локусу контроля — к поиску и к видению причин своих проблем вовне — тем более.

В общем, если вам по тем или иным причинам не нравится «сишечка» — выбирайте в качестве своего рабочего инструмента то, что вам нравится.

И хватит ныть! :))

В общем, если вам по тем или иным причинам не нравится «сишечка» — выбирайте в качестве своего рабочего инструмента то, что вам нравится.

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

А мы всё ещё про работу, или уже про «общее развитие»??.. ;))

А мы всё ещё про работу, или уже про «общее развитие»?

Команда зига говорит пока версии 1.0 нет, пишите себе in-house утилиты для работы.

C — это просто инструмент

Как и палка-копалка, камень скребок и лучина. Тут это, прогресс случился, с компиляторами с железом и вообще CS и сишечка всему этому не соответствует. Она для своих 70-х уже так себе была с её единственной идеей - «сойдёт даже такое лишь бы с ассемблером не пердолиться». Сишников как-будто в музее вычислительной техники заперли где они проспали последние лет 30 в обнимку с PDP-ой. И это не эстетические требования, реальные задачи тоже усложнились и требования к софту и такой параметр как технологичность у сишки вообще будет отрицательный.

И хватит ныть! :))

«А чё не как в сишечке, ничё не понятно», «А чё друст не даёт говнякать как я привык», «А чё они лезут, это всё политика» - действительно хватит, вы инженеры или кто? Что это за психозы и истерики, что только не приплетут лишь бы не учиться.

качество реализации STL, по крайней мере у GNU не позволяет больше им пользоваться

Не флейма ради, но можно ли попродробнее (даже и в отдельном треде)? Речь же о libstdc++, которым много кто пользуется.

«А чё не как в сишечке, ничё не понятно», «А чё друст не даёт говнякать как я привык», «А чё они лезут, это всё политика» - действительно хватит, вы инженеры или кто? Что это за психозы и истерики, что только не приплетут лишь бы не учиться.

Что за бред??..

Большая часть лоровской «критики», по смыслу, сводится к этому, вот у них и спрашивай(и у себя по-видимому). Политику gns приплетает, прям в этом треде, а, ну да, ещё в расте гоуту не той системы

Нет, C — это просто инструмент.

Нет. Си – это очень дерьмовый инструмент, и очень здоровая часть обучения использованию этого инструмента сводится к заучиванию ситуаций, приводящих к отстрелу жопы (напомню, раздел J.2 Undefined Behaviour в стандарте занимает 13 страниц), и тренировкам их избегать. И если бы для этого были реальные весомые причины, вопросов бы не было, но причин-то нет. По примерам как недавно появившихся языков (Nim, Zig, Rust), так и древних мамонтов (Pascal, Forth), никакой особенной производительностью код на Си не отличается.

На любую же критику этого инструмента и предложения заменить его чем-то более адекватным слетается толпа дедов-пердедов, познавших боль использования Сишечки, с воплями «нинужна», «вы просто не осилили Си», «надо уметь им пользоваться», et cetera. Вот это я и называю Культом Боли: деды страдали и нам завещали. В принципе, я не буду против, если поциентов типа Iron_Bug отведут к психиатру, но вряд ли это поможет. Проще просто дать им умереть от старости, потому что новые поколения, судя по всему, эту сишечку с его пердолевом в гробу видали.

Если касательно того, что произошло недавно - собрали с gcc11 с -fsanitize=address бинарь, запустили на системе с gcc14 и оно упало задетектив heap buffer overflow. Точный лог не сохранил
Если касательно поломок с std::string - то тут всё просто: классы, в которые std:string раскрывается менялись и в зависимости от -std при передаче его в аргументах изменится сигнатура функции.
Если у библиотеки в API была одна версия стандарта, а использующий её софт пересобрался с другой, то они не слинкуются, но это ещё мелочи
Если пересобрать библиотеку с более новой версией стандарта (пересобрать после обновления компилятора, например), то уже слинкованный с ней софт отвалится

Да ты просто завидуешь. Ты же вроде на Haskell пишешь, а там даже signed int переполнить нельзя

Да ты просто завидуешь. Ты же вроде на Haskell пишешь, а там даже signed int переполнить нельзя

Можно. Разрешаю :3

ghci> maxBound :: Int
9223372036854775807
ghci> (maxBound :: Int) + 1
-9223372036854775808

А вот кстати, в хаскеле даже гоуту есть https://hackage.haskell.org/package/GotoT-transformers-1.0.0.1/docs/Control-Monad-Trans-Goto.html 0_0, вот чёрт, получается он даже ближе к железу чем рачт

О, вот оно как… Ну и зачем тогда нужен этот Haskell если есть божественная пара C и C++? Чистые функции я и там и тут могу писать. В плюсах относительно недавно завезли концепты, пайп оператор и рэнжи – ну сказка же, разве не так? Монады? Эмммм, я не знаю что это такое.

Ну все, переписываем весь эмбедед на хаскель. <troll mode>Я правда боюсь что дефолтный эмбедер не разберется как сделать сайд эффект, типа изменения состояния регистра)))</troll mode>

О, вот оно как… Ну и зачем тогда нужен этот Haskell если есть божественная пара C и C++?

Потому что в Haskell целочисленное переполнение не являются UB и компилятор не обосрёт тебе весь код.

Монады? Эмммм, я не знаю что это такое.

Отлично! Значит Haskell тебе не нужен.

Я правда боюсь что дефолтный эмбедер не разберется как сделать сайд эффект, типа изменения состояния регистра)))</troll mode>

Как мы убедились в этом треде, дефолтный эмбедер не разберётся даже в сишечке и расставляет volatile по коду в случайном порядке, пока тот не заработает. А потом ноет, что ему компилятор код переоптимизировал :(((

Потому что в Haskell целочисленное переполнение не являются UB и компилятор не обосрёт тебе весь код.

Кто не рискует, тот не пьет шампанское.

Отлично! Значит Haskell тебе не нужен.

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

вот у них и спрашивай(и у себя по-видимому)

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

В плюсах относительно недавно завезли концепты, пайп оператор и рэнжи

Оно всё сырое и трындец какое уродливое, рэнжи тормозят - с другой стороны, конечно- а что в плюсах прямое (

Справедливости ради я признаюсь, что когда я начинал писать под МК и не знал про volatile, я очень удивлялся что флаги, которые я дергаю в прерываниях, «магическим» образом были вырезаны. После 5 минут гуглежки я нашел нужный пункт стандарта про volatile.

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

Гы, так уже, весь не весь, но в НАСА ембедед хаскелем генерируют https://github.com/Copilot-Language/copilot выглядит как-то так:

module Main where

import Language.Copilot
import qualified Prelude as P

-- If the majority of the engine temperature probes exeeds 250 degrees, then
-- the cooler is engaged and remains engaged until the majority of the engine
-- temperature probes drop to 250 or below.  Otherwise, trigger an immediate
-- shutdown of the engine.

engineMonitor :: Spec
engineMonitor = do
  trigger "shutoff" (not ok) [arg maj]

  where
  vals     = [ externW8 "tmp_probe_0" two51
             , externW8 "tmp_probe_1" two51
             , externW8 "tmp_probe_2" zero]
  exceed   = map (> 250) vals
  maj      = majority exceed
  checkMaj = aMajority exceed maj
  ok       = alwaysBeen ((maj && checkMaj) ==> extern "cooler" cooler)

  two51  = Just $ [251, 251] P.++ repeat (250 :: Word8)
  zero   = Just $ repeat (0 :: Word8)
  cooler = Just $ [True, True] P.++ repeat False

main :: IO ()
main = interpret 10 engineMonitor

мне вот даже больше нравится чем плюсово-растовые закорючки.

У меня один знакомый переписывал свой код для HPC под пайп операторы, он сказал что в производительности разницы особо не заметил, но зато читаемость того, что происходит с данными, возрастает в разы.

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

Если пересобрать библиотеку с более новой версией стандарта (пересобрать после обновления компилятора, например), то уже слинкованный с ней софт отвалится

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

Если касательно того, что произошло недавно - собрали с gcc11 с -fsanitize=address бинарь, запустили на системе с gcc14 и оно упало задетектив heap buffer overflow.

Тут сложно сказать наверняка, что пошло не так, но в целом я понял, что претензии не к качеству самой libstdc++, а к использованию ее в «неоднозначных» с точки зрения ABI ситуациях.

Рекомендую посмотреть на -static-lib{gcc,stdc++,*san} у компилятора — может помочь, но ситуация, когда одна бинарник, слинкованный с libstdc++ одной версии, вызывает код в библиотеке, собранной/слинкованной с другой версией libstdc++, — это явно не проблема авторов гнутой libstdc++.

В этом случае преимущество у libcxx от llvm ровно одно — их не бывает больше одной в системе со всеми вытекающими плюсами и минусами.

Ну тут вроде как чисто high level API, я так понимаю extern "cooler" cooler это вызов low-level API, которое скорее всего на сях.

мне вот даже больше нравится чем плюсово-растовые закорючки.

Ну код на хаскелле достаточно чистый обычно. Хотя, для меня объявления two51, zero, cooler кажутся легкой магией, хотя возможно это от незнания языка.

Rust для моих CH32V003 упомянул

Ну для таких маленьких. Rust скорее и не к чему. Тут ядро совсем обрезано, да же в рамках всей серии. А задачи явно укладываются в пару страниц кода.

Если говорить про Rust и RISC-V, то тут достаточно хорошо. Хотя всегда найдутся подводные камни. Для WCH, это, например, атрибут WCH-Interrupt-fast, который ещё поддержать надо. Тут да же gcc без патча не пойдёт. А об стоковом OpenOCD и ещё сложнее говорить. (хотя давно не проверял состояние дел).

При всех этих минусах разработка для RISC-V может быть очень интересной. С.м. https://1000os.seiya.me/en/ там запуск этой микро ОС для RISC-V 32 прямо в QEMU

Rust же для микроконтроллеров интересен попыткой создать единый подход для всех устройств. Где есть svd2rust. Набор hal для многих микроконтроллеров. В том числе и https://github.com/ch32-rs/ch32-hal

Но вот Borow Checker и толстый итоговый код может свести с ума. И это явно не то, с чего надо начинать изучать Rust.

А я не уверен, что стоит вот так, просто, взять и сменить язык, на котором писал уже, на новый совсем для меня…

Стоит просто ради развития. Даже небольшой опыт разработки простых консольных утилит на Rust после Си будет полезным. Меняет подход к написанию API.

Пару примеров.

Пару лет назад понадобилась кроссплатформенная (Linux/Windows) консольная утилита для указания распределения RAM/Flash для CH32V307. Потратил два дня. 80% времени дизассемблер кода от WCH. И пару часов для написания кода на rust. Понятно, что кинуть пару булков не проблема. Но тот-же Patern Matching и система обработки ошибок делает код совсем коротким:

    fn get_ram_flash_id(&self) -> Result<u8, WchLinkError> {
        const CMD_GET_RAM_FLASH: [u8; 4] = [0x81, 0x0D, 0x01, 0x04];
        self.dev
            .write_bulk(0x1, &CMD_GET_RAM_FLASH, DEFAULT_TIMEOUT)?;

        let mut buf = [0u8; 4];
        let buf_size = self.dev.read_bulk(0x81, &mut buf, DEFAULT_TIMEOUT)?;
        if buf_size != 4 {
            return Err(WchLinkError::WrongResultPacket);
        };
        log::trace!("Result RAM/Flash: {:02X?}", &buf[0..buf_size]);

        match buf {
            [0x82, 0x0D, 0x01, x] => Ok(x),
            [0x81, 0x55, 0x01, 0x01] => Err(WchLinkError::MagicErrorCode),
            _ => Err(WchLinkError::WrongResultPacket),
        }
    }

Второй пример. От нечего делать переписывал sunxi-fel на Rust. Задача, разобраться как работает. В проекте несколько слоёв абстракций:

• AwUsb - Отправка приём больших сообщений разбитых на пакеты Allwinner USB.
• AWFel - Набор команд для FEL (чтение/запись памяти, выполнение кода)
• Device - платформо зависимый набор команд, часть из которых отправляет код в память, запускает его, и считывает результат.

Код написан на Си, а слои перемешены просто ужасно. Префиксы некоторых функций явно не из того слоя. Rust при этом по рукам даёт активно за такое.

мой неокрепший мозг, привыкший к императивности, был взорван

А если покопаться в памяти, можно вспомнить момент, когда мозг, привыкший к математическим y=x^2 был взорван императивным x=x+1.

Стоит просто ради развития

Нет, не стоит: я не в том возрасте уже, что бы «ковыряться от делать нечего», просто чтобы узнать что-то новое. Моё любопытство давно уже утолено... :)

Даже небольшой опыт разработки простых консольных утилит на Rust после Си будет полезным.

Не будет: я не пишу консольные утилиты, нет нужды.

Есть желание и необходимость «переехать» с «мелкоконтроллеров» от Microchip на мелких же «китайчат», с неизменным направлением на мелкую автоматизацию. ВСЁ.

Меняет подход к написанию API.

Не хочу менять свой «подход к написанию API»: как не писал, так и дальше планирую не писать. :)

От нечего делать переписывал

У меня есть чего делать. Всегда. :)

Ещё бы время на всё, что хочется поделать...

Ну для таких маленьких. Rust скорее и не к чему.

Тоже прихожу к мысли «остаться на С», по целому ряду причин...

А задачи явно укладываются в пару страниц кода.

Ну... Не факт, но...

Rust же для микроконтроллеров интересен попыткой создать единый подход для всех устройств

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

И это явно не то, с чего надо начинать изучать Rust

Да всё, что я прочитал здесь, и не только — не то, «с чего надо начинать изучать Rust». :)

Не увидел я весомых аргументов в пользу «надо изучать Rust!»... :)

В генте после обновления компилятора старый софт еще ни разу не рассыхался.

У меня рассыпался ТРИЖДЫ. Рассыпакется не от обновления компилятора, а когда начинается пересборка с новым компилятором (не важно, библиотеки или зависимого софта - сигнатура меняется)

Рекомендую посмотреть на -static-lib{gcc,stdc++,*san} у компилятора

Не уверен, что поможет, потому что библиотеку asan'а я притаскивал с машины, на которой делался билд.
-static-libstdc++ должно помочь по идее, если вообще поддерживается

Нет, не стоит: я не в том возрасте уже, что бы «ковыряться от делать нечего», просто чтобы узнать что-то новое. Моё любопытство давно уже утолено… :)

Да ладно. Я тоже не молодой. Наоборот, надо больше мозг нагружать.

У меня есть чего делать. Всегда. :)

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

Не увидел я весомых аргументов в пользу «надо изучать Rust!»… :)

На счёт «надо»: не надо.

Но я не пожалел потраченного времени. Мне было просто интересно. И свою нишу в моих пет проектах он занял.

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

rust для rv32e вполне себе рабочий инструмент.

Собрал rust-код в виде библиотеки функций. Прилинковал и вызвал в основном проекте на Си.

Что даст rust по сравнению с Си:

• Компактные суммтипы. Например, результат fn get_ram_flash_id(&self) -> Result<u8, WchLinkError> будет возвращён в одном регистре. Компилятор будет использовать свободные биты и значения для сжатия.
• На суммтипах можно делать компактные стейт машины. С меньшим числом строк кода, и без возможности не обработать какое-то из состояний (или обработай всё, или не скомпилируется). При этом состояния могут хранить данные.
• Полная обработка ошибок. Например, self.dev.read_bulk(...)?; за счёт символа ? или вернёт успешный результат вызова, или выйдет из это функции прокинув ошибку наверх. А если решил обработать ошибку, то будь любезен, учти в коде все варианты (или обработай всё, или не скомпилируется).
• match шикарен.
• Офигенные макросы для кодогенерации.
• const функции для создания константных данных.
• Слайсы (ссылка на часть массива + размер) как часть типов языка.
• Мощный Language Server.
• Статический анализатор (clippy) подскажет как исправить, а что-то и сам подправит.
• Встроенные тесты.
• Инструменты для создания rust-обвязки для Си кода.
• и т.д.

Из всего, я бы на первое место для Embedded поставил обработку ошибок. Она реально шикарна.

Но я так понимаю, главное:

Моё любопытство давно уже утолено… :)

Мы, похоже, далековато отошли от темы, но я отвечу, потому как считаю, что подобная проблема выбора — «Как жить дальше? И чем?..» — рано или поздно (хотя «поздно» для меня — просто фигура речи), так или иначе встаёт если и не перед каждым, то перед многими.

Да ладно. Я тоже не молодой.

Это бывает. :) Постоянно и у большинства. :))

Но я имел в виду возраст не только «календарный»...

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

Так что теперь меня при выборе того или иного пути, того или иного занятия или, как вот сейчас, «инструмента» для реализации моих «хотелок» для меня имеет большое значение ответ на мой же себе «простой» вопрос — «Зачем??..». Зачем и для чего я хочу вот это и вот так, зачем мне изучать новый для меня язык программирования, и т.д. И мне очень важен мой ответ: не хочу тратить время бессмысленно, потому как заканчивается оно очень внезапно. Знаю уже... :)

Вот и в случае с Rust у меня нет ответа на этот вопрос, хотя и С мне, по сути, придётся не только и не столько вспоминать, сколько изучать заново, так давно я на нём писал...

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

Наоборот, надо больше мозг нагружать.

Да, надо, и мне — в особенности. Но у меня и для меня есть много и других, более приятных и полезных для меня способов это делать, с более понятными и приятными перспективами и результатами от этого процесса, в отличие от изучения нового для меня языка программирования... ;)

Дети большие, внук маленький, играть в компутер не тянет, смотреть телик не могу, интересные сериалы пересмотрел.

Почти так же, да. Только телевизор я давным-давно прекратил. :)

Отдыхать как-то вечерами надо.

От чего?? Я не устал, у меня другой психотип...

Так что книги, хобби и немного программирования для себя.

:)

А работать без останова хватит. Своё я отпахал.

Ой ли?? ;))

Вопрос риторический, просто напомнило кое-что из своего... ;)

rust для rv32e вполне себе рабочий инструмент.

Возможно. Но это не убеждает меня начать изучение нового для меня языка «с нуля». «Не аргумент», в общем.

Не так много на нём уже написано для интересующих меня «мелкокитайцев»... Не на чем учиться... В отличие от С.

Что даст rust по сравнению с Си:

Мне — ничего. Хотя бы потому, что:

для таких маленьких. Rust скорее и не к чему

:))

А вот С вполне «к чему»... :)

Из всего, я бы на первое место для Embedded поставил обработку ошибок. Она реально шикарна.

В моём случае — очень «мелкого» «embedded» — это «не играет».

Но я так понимаю, главное:

Моё любопытство давно уже утолено… :)

Ну, не самое главное, но очень значимо: свою тягу к «абстрактному познанию» я давно в основном и по большей части утолил, а ответа на мой вопрос «Зачем??» в случае с Rust я так и не увидел.

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

Вот, как-то так... :)

Нет. Хуже того, ты сам не понял, что там написано.

Этот кусок стандарта привел тебе я, и я знал ради каких я фраз его тебе привожу, так что пока все так и осталось, ты фантазируешь и отказываешься видеть то, что не укладывается в твои фантазии…

Также замечу, что в этот спор стандарт подтянул ты сам, хотя о нем речь не шла ни разу, намек понял…?

rust для rv32e вполне себе рабочий инструмент.

Вот только лет через пять решил ты пересобрать проект на расте и вдруг обнаружил, что там все поменялось, ибо он не особо ответственен в плане поддержки своих предыдущих версий (вроде ж был прицендент что в расте классы были, аж пол года просучествовали). А также при попытке запихать компилятор в железку - это может и не получиться, потому что толсто и сложно…

Что даст rust по сравнению с Си:

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

Собственно, я Раст вижу, например, как язык для написания движка браузера, но к железкам я б его не использовал (пет-проекты и иже с ним не берем в расчет)

Нет. Хуже того, ты сам не понял, что там написано.

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

Как я тебя сразу-то раскусил…)))))

ибо ты побанил (или с твоей подачи) мои сообщения,

Я тут никого не банил. Все вопросы к модераторам.

Этот кусок стандарта привел тебе я, и я знал ради каких я фраз его тебе привожу

Надеюсь, ради фраз про абстрактную машину языка? Потому что там это написано, хоть ты и продолжаешь её отрицать.

был взорван императивным x=x+1.

Вот поэтому учат на Паскале. Где x=x+1 ложь, а x:=x+1 читается как «записать в x значение x+1». А потом при переходе на Си «теперь запомните, что = пишется как ==, а := пишется как =».

Сишечка — это просто культ боли

Нет, C — это просто инструмент.

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

Вот это тебя попердолило!

К слову, кроме как на спам я тут ни разу модерам не жаловался.

Да ладно, чел в своём праве... :)

Да и на что тут жаловаться-то?? Дискутируем, морды друг другу не бьём. ;))

https://codeberg.org/mergiraf/mergiraf/src/branch/main/src/supported_langs.rs#L740

        LangProfile {
            name: "C/C++",
            alternate_names: &["C", "C++"],
            extensions: vec![
                "c", "h", "cc", "hh", "cpp", "hpp", "cxx", "hxx", "c++", "h++", "mpp", "cppm",
                "ixx", "tcc",
            ],
            file_names: vec![],
            language: tree_sitter_cpp::LANGUAGE.into(),
...

Они не знают, что это разные языки?
Исправил: https://codeberg.org/mergiraf/mergiraf/pulls/634. 🧐

при наличии парсера для TS

Не понял, можно подробнее тут?

https://tree-sitter.github.io/tree-sitter.

The following parsers can be found in the upstream organization:
…
A list of known parsers can be found in the wiki.