c3c 0.7.6

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

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

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

Вот даже не помню, что именно там не так, но что-то явно было не так.

Навскидку, нет базисной идеологии. С базисной идеологией Zig взлетит, без базисной идеологии C3 не взлетит.

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

Кстати, я думаю, если появится металлическая реализация работы с объектами (как типа шейдеры и т.п.), то в Си непременно и тут же появятся классы))))) А так, конечно, все это ООП - это слишком медленная на сегодня штука, особенно если придерживаться полностью парадигмы ООП, когда на каждый чих делаешь класс, но хотелось бы все таки иметь такую возможность, ведь не все ж задачи требуют немедленного исполнения (там производительность похоже раз в 70 падает)

Вот смотрю я на код на скрине «хело вордлда» и понимаю, что он выполняется по любому в разы медленнее чем аналогичный на Си…

Добавили б к статье сравнение по времени исполнения и стал бы ясен ответ на вопрос: «А что в реальности может противопоставить с3 всеми используемому Си, т.к. если тот код максимум на 5% дольше выполняется, то с3 имеет право на жизнь и такие заявления, а если в разы медленнее кода на Си, тогда этот язык к Си не имеет никакого отношения, т.к. с таким подходом Любой язык может примазаться к Си по тем или иным критериям соприкосновения с Си»

что опять без классов? тогда в номер версии надо минус добавить

а как же Zig? вроде бы шевелиться еще.

Си с объектами это к яблофилам.

Добавили б к статье сравнение по времени исполнения и стал бы ясен ответ на вопрос: «А что в реальности может противопоставить с3 всеми используемому Си, т.к. если тот код максимум на 5% дольше выполняется

Бэкенды от LLVM, соответственно, скорость не уступает.

Что вы знаете о Zig, кроме имени няшненького?

ls -Al ./hello_world_any 

Постеснялись? Вот не меньше сотни мегабайт, конечно жэ. Для программистов, которые любят С. Ага. АЧ0 классы «для программистов, которые любят С», не захерачили?. Без классов - не выйдет.

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

есть ещё море всякой фигни. непонятно только, нафига оно нужно.

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

Не много, но знаю что он няшный:

// C
int *arr = malloc(10 * sizeof(int));
arr[10] = 42; // UB! Выход за границы. Компилятор может не предупредить.

// Zig
var arr = try allocator.alloc(i32, 10); // `try` обрабатывает ошибку (OOM)
defer allocator.free(arr); // `defer` гарантирует освобождение

arr[10] = 42; // ОШИБКА КОМПИЛЯЦИИ! Нельзя выйти за границы.
// Правильно:
if (arr.len > 10) {
    arr[10] = 42;
} else {
    // Обработка ошибки
}

Если бы этот няшка мог собрать в 2024-м хотя бы одну программу, написанную в 2022-м - было бы ещё няшнее. А пока - нет. Он сам себя-то только при определённой фазе Луны собирает, это невозможно практически. Как так можно пейсать, ПЛЯ. 🤦

// ОШИБКА КОМПИЛЯЦИИ! Нельзя выйти за границы.

Use Microsoft Visual Basic. Глобально и надёжно, наследие мистера Гейтса как-никак. Oracle Java тоже ничё, индустриальный стандартъ.

Маленький бинарь хеллоу Ворда - это не просто эстетика и вкусовщина, хотя, почему нет? Размер бинаря - это степень ожирения рантайма, а жирный рантайм - это трудности с портированием. Сишечка хороша тем, что её рантайм минимален, легко монтируется и сишечкин бинарь запускается на любой доске через минимум телодвижений. Из-за этого свойства сишечки, и Линукс появился. Один человек смог. А вы выкатываете непортруемый прибитый гвоздями к Линуксу жыр, и говорите, что это замена Сишечки. Хер вам. Выкуси.

и не вижу причин, зачем бы мне было надо о нём знать.

От зига в восторге те когорты программистов С/С++, которые повидали некоторое дерьмо. Аналог printf(«Hello, %s!\n», username); на зиге будет быстрее, потому что парсинг формата пройдет в комптайме, и в рантайме он выведет текст не подгружая libc.so.

От зига в восторге те когорты программистов С/С++, которые повидали некоторое дерьмо.

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

а те, кто не пишет говнокод, спокойно продолжают писать на сишке и всё нормально. нет причин страдать фигнёй.

Только это не когорты программистов на C/C++, это - ламеры. А дальше - всё так, да.

а те, кто не пишет говнокод, спокойно продолжают писать на сишке и всё нормально. нет причин страдать фигнёй.

Еще там (в зиге):

• юнит-тесты из коробки
• енумы для нумерации ошибок
• сум-типы для обработки ошибок
• проброс ошибок наверх через try/catch
• работа с типами в комптайме как с переменными
• упаковка array-of-structs в struct-of-arrays
• компиляция старого кода на С и С++ под использование внутри
• особенно хорошо получается с EFI и WASM

особенно хорошо получается с EFI

Только не собирается, уже через два года. И нафиг не надо. Ничего в этом УЕФИ, кроме загрузчика, которых и так уже с избытком, не напишешь А так, да, хорошо. Только не работает.

я не заказывала никаких отчётов об абсолютно неинтересной мне фигне.

и да, есть WASM - это не Watcom Assembler, то это то, что нужно убивать прямо на месте. вот прямо сразу.

то это то, что нужно убивать прямо на месте. вот прямо сразу.

То есть javascript пусть живет, а за чистейший WASM-дистиллят убивать?)

я ничего не написала насчёт жабаскрипта. из чего такие странные выводы?

но да, дистиллят этой наркомании надо уничтожать. он особенно опасен.

Сишечка хороша тем, что её рантайм минимален,

И имя ему глибс. Он очень минимален. :)

От glibc сишечка (не c++) отвязывается не просто, а очень просто.

Ничего в этом УЕФИ, кроме загрузчика, которых и так уже с избытком, не напишешь

Целый мусль под него уже портанули. А значит, что-то да напишешь. При желании. Был бы там ещё SDL, можно было бы игрушек накидать. :)

От glibc сишечка (не c++) отвязывается не просто, а очень просто.

И что остаётся? Как, без рантайма, хотя бы взаимодействие с пользователем обеспечить?

Как-как. Как диды обеспечивали. Начать с RS - он прост. А видеоадаптера в контроллере может и не быть.

Как-как. Как диды обеспечивали. Начать с RS - он прост.

Если там операционка, то так и так надо /dev/ttyS0 открыть. Если там её нет, то понадобятся асмовые вставки. Что уже не есть Си.

Асмовские вставки там элементарные. Это всё абсолютная чепуха по сравнению с портированием например парсилки и отображайки юникода, у которой в зависимостях вся последняя Убунта со всеми апдейтами. Зачем эти дибилы юникод в язык тащат? Он же бесконечен, и требует постоянных нетривиальных обновлений. Ди-би-лы.

Зачем эти дибилы юникод в язык тащат? Он же бесконечен, и требует постоянных нетривиальных обновлений. Ди-би-лы

Погодите, а в чём конкретно зависимость заключается? Глибс от каких-то юникодных либ зависит, или как протащили?

gilbc зависит от юникода со времён Царя Гороха, со времён, когда юникодные локали появились, и все эти новомодные язычки - туда же. Одного только не понимаю. Почему тогда код

int main ()
{
 printf ("💩");
}

А в результате

Раз так, то мож хотяб в язык это тащить не надо? Не думаете?

gilbc зависит от юникода со времён Царя Гороха

Так это то понятно. Но откуда вот это:

у которой в зависимостях вся последняя Убунта со всеми апдейтами

По тому, что:

Source: glibc
Version: 2.41-6ubuntu1.2
Replaces: libc6 (<= 2.32-1)
Provides: libc-dev (= 2.41-6ubuntu1.2)
Depends: libc6 (= 2.41-6ubuntu1.2), libc-dev-bin (= 2.41-6ubuntu1.2), linux-libc
-dev, libcrypt-dev, rpcsvc-proto
Suggests: glibc-doc, manpages-dev

ЧЯНТД?

А в результате

От терминала мож зависит. Я собрал (добавив include stdio.h, который вы зачем-то забыли), и он высвечивает кусок дерьма, как и задумано. (gnome-terminal)

От терминала мож зависит.

Так вот, терминал, который сумеет нормально отобразить весь юникод, у него как раз в зависимостях и будет вся Убунта, а оторвать от Убунты, и втащить в железку это всё будет не возможно. Это называется Bloatware, товарищ. И тащить это в язык - ну, извините.

Так вот, терминал, который сумеет нормально отобразить весь юникод, у него как раз в зависимостях и будет вся Убунта,

Ну так а это тогда при чём?

Зачем эти дибилы юникод в язык тащат? Он же бесконечен, и
требует постоянных нетривиальных обновлений. Ди-би-лы.

У вас давно терминал стал частью языка? Просто не используйте юникод, делов то.

Аналог printf(«Hello, %s!\n», username); на зиге будет быстрее, потому что парсинг формата пройдет в комптайме, и в рантайме он выведет текст не подгружая libc.so.

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

В 95% случаев там будет строка, полученная через gettext() или его аналог, к которой комптайм обработку никак не присобачишь.

А в оставшихся 5% это вообще не играет никакой роли.

Правильный пиар работы с форматными строками выглядел бы так:

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

Потому что программа, в которой не требуется работать с локализованными форматными строками - это HelloWorld.

И тащить это в язык - ну, извините.

Не понимаю, кто у вас в язык затащил гноме-терминал.

В язык затащили парсинг юникода, который также сломается на более новомодных юникодных символах, и это бесконечной процесс. Эти их строки, с длиной - всё ломается, на символах, которые он не знает.

Кто заставляет им пользоваться? Тезис с зависимостями вы так и не доказали. Значит, решение простейшее: не пихайте в прогу юникод.

Кто заставляет им пользоваться?

Заставляет - не заставляет. Найдутся сенсеи, не беспокойтесь. Если язык предоставляет возможность - обязательно найдутся герои. Вон приходят тут. С++ 22, с лямбдами им, обязательно. Иначе - нельзя.

А гноме терминал там притом, что вы же сами про средства взаимодействия с пользователем меня лечили. Как вы будете отображать? 100.000 фонтов, с интернет обновлением - в контроллер. Отличное решение. Да.

Как вы будете отображать? 100.000 фонтов, с интернет обновлением - в контроллер. Отличное решение. Да.

Да просто не буду в контроллере корректно отображать юникод. Можно сделать поиск апроксимаций из АСКИ, ЕМНИП юникод даже такое поддерживает.

А в оставшихся 5% это вообще не играет никакой роли.

Как хорошо, что одна башевская утилитка «my-shorted-path» попала в эти 5%, и моя вторая утилитка «datetime-to-clipboard» попала в эти 5%. Помнится, я делал хот-фиксы для подмены битых длл на исправленные. Так-то они тоже попали в эти 5%, и сомневаюсь, что там i18n и l10n я делал бы на gettext() — просто по определению хот-фикса.

Ну, отлично. Тут товарищи гордятся юникодом, юникодными строками, юникодным отображением. Демонстрационную программу с юникодом в новость поместили. А вы такой - отличный язык, только юникод я использовать не буду. Ну, ОК. А может, если вы не будете эти хипсторкие инновации использовать, сишечки-то достаточно?

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

Наверное такие кейсы есть.

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

Вы, кстати, использовать и не использовать можете что угодно, только bloatware-runtime никуда не денется. Раз в языке юникод - это уже якорь.

Ну, ОК. А может, если вы не будете эти хипсторкие инновации использовать, сишечки-то достаточно?

Так мы про неё с вами сейчас и говорим, вроде. И «прогу» вашу я вовсе не на с3 собирал.

Вы, кстати, использовать и не использовать можете что угодно, только bloatware-runtime никуда не денется. Раз в языке юникод - это уже якорь.

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

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

Это было удивительно совершенно! На одноплатнике отказался от тормозного fish с scm-плагинами в пользу bash со своей сверхбыстрой сокращалкой пути.

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

Дело не только в форматировании printf(): комптайм отлично помогает в деле перекладывания байтов из JSON в CRUD, например.

Кто-то смог собрать актуальную версию c3? Вижу появление ошибки о отсутствии get_hash.cmake

Выполнял сборку по инструкции с сайта.

Исходники из архива?
Наверное, не положили туда https://github.com/c3lang/c3c/blob/master/git_hash.cmake.

Крестов мало не бывает)