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

Древней версии gcc?

Да. К сожалению из-за требования c++ в gcc и отсутствия какого-либо современного аналога cfront gcc поверх сишки бутстрапится только через старую версию

Это какие? Расскажи же нам!

Обычно это realtime окружения.
Рзнообразные микроконтроллеры и драйвера, где пропущенное событие это тоже потеря данных
Софт связанный с виртуальной реальностью, где ты если не успел уложиться в 8 или 11 миллисекунд кадра - на экране будет неверное изображение и пользователя может начать укачивать
Софт, работающий с железом напрямую, например управление каким-нибудь промышленным роботом, где замешка может спровоцировать сбой процесса и аппаратные поломки.
Софт, работающий со звуком, когда если ты вовремя не выдал новый буффер с сэмплами, то будет треск или другие артефакты
То есть в обоих случаях, что софт обосрался и насрал память, что софт просрал тайминг - его задача считается не выполненной, пусть и последствия могут отличаться

Так что, с высоты своего опыта, держался бы я от Qt подальше, и сэкономленное время потратил бы на отладку wine-совместимости.

Хм, проблемы с pdf не отменяет того, что всерьез рассматривать win api или что-то чисто виндовое для реализации сложных интерфейсов - это иррационально.

Если есть проблемы с pdf, то я бы не рассмотривал всерьез работу с ним в линукс.

А что на счет программ для работы с pdf из этой статьи? Вроде там прддержка подписей есть https://habr.com/ru/articles/853504/

Или из этой https://icecreamapps.com/ru/learn/besplatnyy-analog-adobe-acrobat.html

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

А https://github.com/fuhsnn/slimcc ещё не может?

This is a fork of Rui Ueyama’s chibicc with fixes and enhancements, including:

• C99 features: VLA parameters, VLA de-allocation, K&R old-style functions.
• C11 features: _Static_assert(), over-aligned locals, _Generic with qualifiers.
• C23 features: constexpr, enum:T, #embed, auto, _BitInt, nullptr, ={}
• C2Y features: named loops, if declarations, _Countof.
• defer: enable with -fdefer-ts, or use _Defer.
• WG14 proposals: __VA_TAIL__, #def #enddef.
• GNU features: inline assembly, commonly used __attribute__’s.
• MSVC features: #pragma pack, anonymous struct.
• Basic codegen optimizations (close to GCC/Clang at -O0).

What can it build?

Compiling real C projects with slimcc has been a major focus, the CI workflow now regularly build-test a healthy collection of familiar names, for bragging rights:

• Core system commands (GNU coreutils, busybox, toybox)
• Developer tools (binutils, Bash, Curl, Git, jq, wget, Zsh)
• Programming languages (Python, Go, Lua, Perl, Ruby, PHP, Ocaml, Zig)
• Gamedev/graphics libraries (SDL3, glfw, stb, raylib, sokol)
• Critical infrastructure softwares (Redis, Valkey, Nginx, PostgreSQL)

Сейчас эти проблемы актуальны?

всерьез рассматривать win api или что-то чисто виндовое для реализации сложных интерфейсов - это иррационально.

Это голословное и неадекватное утверждение, мне скучно его комментировать.

А что на счет программ для работы с pdf из этой статьи? Вроде там прддержка подписей есть

Я должен поработать тестировщиком ПО, на каждую программу написать отчет с анализом? Беглый взгляд показывает, что там сравнивается бесплатный функционал Adobe Acrobat Reader с платными аналогами. Хотя, это объяснимо.

Вот Master PDF Editor вижу, что на Qt. Отличия от MFC минимальные, а головная боль от Qt максимальная. Нейронка говорит, версия Qt5.9 появилась в 2017 году, с прекращением поддержки три года спустя. У авторов программы не хватило сил и желания что-то со своим Qt сделать.

Прямо сейчас? Без понятия. Полгода назад были.

Наверно может, просто tcc - первое, что пришло в голову

как я уже выше писал, этот самый 5.9 может просто развалиться в современном окруженнии. Так что единственное, на что они могут надеяться - обновить qt до 5.15 или 6. Но если с этим есть какие-то проблемы, то finita la comedia

как я уже выше писал, этот самый 5.9 может просто развалиться в современном окруженнии. Так что единственное, на что они могут надеяться - обновить qt до 5.15 или 6. Но если с этим есть какие-то проблемы, то finita la comedia

У Qt проблемы на всех уровнях. Начиная с мутных лицензий, через разъехавшийся лейаут на дробном масштабировании, к крэшам на вейланд-билдах.

его гугел очень активно продвигал в 2000х.

Какой еще гугель? Вы что не помните как гугл-поиск выглядел в 2000х? И его юзали потому что он был пустой (без рекламы) и только внизу Gooooooooooooooooogle.

Какие программы ты проверял?

Это голословное и неадекватное утверждение, мне скучно его комментировать.

Скучно, потому что win api для qml ни разу не конкурент

Я должен поработать тестировщиком ПО, на каждую программу написать отчет с анализом? Беглый взгляд показывает, что там сравнивается бесплатный функционал Adobe Acrobat Reader с платными аналогами. Хотя, это объяснимо.

Если ты утверждаешь, что ничего кроме акрабата не работает, то должен был проверить это ничего.

Вот Master PDF Editor вижу, что на Qt. Отличия от MFC минимальные

Ты понимаешь, что я тебе пытаюсь донести? Я про сложные дизайнерские интерфейсы.

У авторов программы не хватило сил и желания что-то со своим Qt сделать.

Ну и вывод какой? Разрабы решили забить на переход на новый qt. Ииииии?

Если ты утверждаешь, что ничего кроме акрабата не работает

Лолшто?

Okular, Evince.

его гугел очень активно продвигал в 2000х.

Какой еще гугель? Вы что не помните как гугл-поиск выглядел в 2000х? И его юзали потому что он был пустой (без рекламы) и только внизу Gooooooooooooooooogle.

Компания гугель, балда. Среди его работников пердон был особенно популярен, они потом это растащили по Долине, а оттуда за пару лет он растёкся по всей индустрии.

У тебя память ограничена что-ли?

Вот же, мой вопрос:

И далее вопрос: нет нативных программ для Linux, которые позволяют подписывать свои pdf-документы и проверять достоверность подписи чужих pdf-документов?

Твой ответ:

Такие программы есть, но GUI в них нет.

Далее я привел статьи и спросил, мол эти тоже не осиливают создание и проверку подписи? Ты такой: ну я не тестироващик, все дела. Т.е. ты точно не знаешь получется.

Далее я привел статьи и спросил, мол эти тоже не осиливают создание и проверку подписи? Ты такой: ну я не тестироващик, все дела. Т.е. ты точно не знаешь получется.

Если цитируешь, цитируй полностью. Я сказал, что можно сделать пайплайн, к которому понадобятся линуксовые драйверы крипто-токенов, и к которому понадобится выбирать гуи-тулкит. Master PDF Editor и есть результат «можно сделать». И он просит деньги за свое использование. Он требует пройти квест по поиску линуксовых драйверов к крипто-токену. Извини — он не конкурент бесплатному функционалу Adobe Acrobat Reader. И ввиду поиска драйверов будет проще взять wine и виндовз-едишен любой программы из списка. Я понимаю, что создатели Master PDF Editor хотели сделать кросс-платформенный продукт. И понимаю, что Qt-тулкитом в итоге оказались сыты по горло.

Если цитируешь, цитируй полностью. Я сказал, что можно сделать пайплайн, к которому понадобятся линуксовые драйверы крипто-токенов, и к которому понадобится выбирать гуи-тулкит. Master PDF Editor и есть результат «можно сделать».

Т.е. ты теперь принципиально не будешь называть Master PDF Editor программой с GUI, которая позволяет позволяет подписывать свои pdf-документы и проверять достоверность подписи чужих pdf-документов

потому что ранее заявил:

Такие программы есть, но GUI в них нет.

И вместо этого будешь использовать термин гуи-тулкит?

Мне в принципе плевать, как ты не хочешь признавать неправоту.

Однако пока я вижу так:

Есть нативные программы под Linux с GUI, авторы котрых по крайней мере заявляют поддержку работы с подписями, работоспособность которых или ее отсутствие ты не проверял, однако утверждаешь, что акробат проще и лучше (в вайн). Тогда как, что точно проще (в случае, когда нужен именно акробат), так это использовать его на винде.

При этом эту логику про отсутствие в Linux нормальной (с твоих слов) возможности работать с pdf нативными средствами, ты за каким то бесом притянул как контраргумент моему утверждению про отсутствие внятных альтернатив для Qt в том числе по критерию возможности реализации дизайна любой сложности.

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

И таким образом если хочешь обсудить, что там не так с Qt, ок, если хочешь продолжать тереть об pdf, давай без меня.

Есть нативные программы под Linux с GUI, авторы котрых по крайней мере заявляют поддержку работы с подписями

Убедил. Я признаю, что есть программы под Linux с GUI для подписывания и верификации PDF.

Плюсы Master PDF Editor:

• есть версия под линукс
• широкий функционал, включая электронную подпись и верификацию

Минусы Master PDF Editor:

• имеет в зависимостях Qt5 (там qt5.15, про 5.9 я оказался неправ, и стабильность соотв. лучше).
• разработчики тратят время на поддержку шести пакетов для разных версий линукс. В дополнение к версиям под виндовз и макос.
• USD $79.95 each лицензия

Среди его работников пердон был особенно популярен,

Потому что простой, вот поэтому популярен. Почему куча полезного софта (не какие то там дубли переделки а реально нового) под go? И при том гошники не орут из каждой щели.

Вы где-то ошиблись, флаг O3 использовали?

Я лично проверил, а у Вас нет различия при разных вариантах printf…

Да и фундаментально то, что вы представили, не является адекватным. Просто на заполнении чар массива попробуйте, если с printf не получается и не забываем O3 флаг. Попробуйте clang, но у меня разницы особо не видно (может компилятор слишком старый, я не знаю, тут смотреть нужно). Обратите внимание, что у Вас программа долго выполняется (у меня на виртуалке в 1,5-2 раза быстрее на интеле 12400) - попробуйте time использовать.

Можно пример программы на Си, где каждая команда транслируется в команду на асм?

char i = 100; или goto a;

Не можешь. Как минимум, объявления функций в стиле K&R давно выкинули. А ещё триграфы. А ещё штуки типа gets(). Ну и прочего по мелочи.

Проверь поддерживается даже:

int my_foo(a, b) char a; char b; { return a + b; }

И гцц и clang оба по миллиону строк. Легковесный, угу.

https://ru.wikipedia.org/wiki/Tiny_C_Compiler#:~:text=Tiny%20C%20Compiler%20%E2%80%94%20%C2%AB%D0%BA%D1%80%D0%BE%D1%88%D0%B5%D1%87%D0%BD%D1%8B%D0%B9%20%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80,%2C%20x86%2D64%20%D0%B8%20ARM.&text=%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82%20%D0%B2%20%D0%9E%D0%A1%20Linux%2C%20KolibriOS,%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%80%D0%B0%D0%BD%D1%8F%D0%B5%D1%82%D1%81%D1%8F%20%D0%BF%D0%BE%20%D0%BB%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D0%B8%20GNU%20LGPL. 100kB - слабо…??

Кстати, оба написаны почему-то не на Си.

gcc точно почти полностью на Си написан и фронт на Ада вроде, а остальное все вкусовщина и дектуется реальностью…

Я перестаю понимать, что ты вообще несёшь. Volatile к «аномальности» всё ещё не имеет отношения.

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

Это ты путаешь, по-моему, уже нарочно…

Программы не «научились» оптимизировать, а разработаны оптимизации, которые приводят к порой некорректному выполнению программы = появился volatile (так им еще и Не рекомендовали злоупотреблять и правили баги связанные с ним, даже в С17)…

У тебя с формальной логикой проблемы…

PS не путай понятия корректно «написанная программа на языке С» и «корректно скомпилированная/исполняемая программа»

легковесный компилятор

И гцц и clang оба по миллиону строк. Легковесный, угу.

Вот тебе пример моих слов более наглядный:

https://github.com/xorvoid/sectorc

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

В кодировке base64 он выглядит так:

6gUAwAdoADAfaAAgBzH/6DABPfQYdQXoJQHr8+gjAVOJP+gSALDDqluB+9lQdeAG/zdoAEAfy+gI AegFAYnYg/hNdFuE9nQNsOiqiwcp+IPoAqvr4j3/FXUG6OUAquvXPVgYdQXoJgDrGj0C2nUGV+gb AOsF6CgA68Ow6apYKfiD6AKrifgp8CaJRP7rrOg4ALiFwKu4D4Srq1fonP9ewz2N/HUV6JoA6BkA ieu4iQRQuIs26IAAWKvD6AcAieu4iQbrc4nd6HkA6HYA6DgAHg4fvq8Bra052HQGhcB19h/DrVCw UKroWQDoGwC4WZGrW4D/wHUMuDnIq7i4AKu4AA+ridirH8M9jfx1COgzALiLBOucg/j4dQXorf/r JIP49nUI6BwAuI0G6wyE0nQFsLiq6wa4iwarAduJ2KvrA+gAAOhLADwgfvkx2zHJPDkPnsI8IH4S weEIiMFr2wqD6DABw+gqAOvqicg9Ly90Dj0qL3QSPSkoD5TGidjD6BAAPAp1+eu86Ln/g/jDdfjr slIx9osEMQQ8O3QUuAACMdLNFIDkgHX0PDt1BIkEMcBaw/v/A8H9/yvB+v/34fb/I8FMAAvBLgAz wYQA0+CaANP4jwCUwHf/lcAMAJzADgCfwIUAnsCZAJ3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAVao=

разработчики тратят время на поддержку шести пакетов для разных версий линукс. В дополнение к версиям под виндовз и макос.

А почему тратить время на поддержку под linux - это минус, а на поддержку win/mac - это не минус?

Можно пример программы на Си, где каждая команда транслируется в команду на асм?

char i = 100; или goto a;

Я просил пример программы, а не отдельных команд.

https://godbolt.org/z/esa54j7o4

Можно узнать, куда делись эти 100 и goto здесь?

int my_foo(a, b) char a; char b; { return a + b; }

Нет. Новыми компиляторами это не собирается.

gcc точно почти полностью на Си написан и фронт на Ада вроде

gcc написан на C++. На Ада там не написано ничего кроме кусков gnat.

Вот тебе пример моих слов более наглядный:

https://github.com/xorvoid/sectorc

компилятор Си, написанный на ассемблере x86-16 и умещающийся в загрузочный сектор 512 байт машины x86.

Это компилятор достаточно малого подмножества языка Си, а не языка Си целиком.

Если ли что-то ещё, что ты знаешь? Потому что про язык Си ты не знаешь примерно ничего.

дектуется

Я тебе фолиантом Розенталя по щщам надектую как-нибудь!

А почему тратить время на поддержку под linux - это минус, а на поддержку win/mac - это не минус?

Вопрос не в поддержке линукс и win/mac. Вопрос в кросс-платформенном десктопном приложении. Ошибочное мнение, это что для этого нужен Qt. Кросс-платформенное приложение получается, если ты делаешь приложение на user32.dll/gdi32.dll/тп. 1) Отладил его под виндовз. 2) Убедился, что запускается в макоси через популярный wine-шелл. 3) Убедился, что запускается на линуксе через популярный wine-шелл. 4) Релизишь.

Это не так, ибо компилятор С++ сложнее чем у Си и в эмбдед это проблема, ты попадаешь на непредвиденные баги, поэтому видишь «железка» - пиши на Си…

Не один раз видел как люди на работах пишут на C++ под stm32, в том числе я сам работал в месте где пишут на плюсах под стмки. Это кстати удобнее, потому что в большинстве случаев не надо «закатывать солнце вручную» и позволяет использовать фишки плюсов (мы использовали С++20).

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

Ошибочное мнение, это что для этого нужен Qt

Кросс-платформенное приложение получается, если ты делаешь приложение на user32.dll/gdi32.dll/тп. 1) Отладил его под виндовз. 2) Убедился, что запускается в макоси через популярный wine-шелл. 3) Убедился, что запускается на линуксе через популярный wine-шелл. 4) Релизишь.

Ладно, я тебя услышал. Тут мы не сойдемся. Т.к. для тебя вид приложений под wine - приемлемо, для меня нет.

Я просил пример программы, а не отдельных команд.

Ты можешь просить что угодно, но я пишу ровно про это…

Можно узнать, куда делись эти 100 и goto здесь?

туда же куда при аналогичных командах из асм, очевидно…

Нет. Новыми компиляторами это не собирается.

Проверь и не фантазируй, я тебе про это уже писал, твои фантазии - только твое дело:

#include <stdio.h>

int my_foo(a, b)

char a;

char b;

{

return a + b; 

}

int main()

{

printf("%d\n",my_foo(1,2));

return 0;

}

даже так работает на удивление:

gcc -Wall -Wextra -pedantic -std=c23 2.c

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

gcc написан на C++. На Ада там не написано ничего кроме кусков gnat.

иди в исходники, ты меня утомил…

Это компилятор достаточно малого подмножества языка Си, а не языка Си целиком.

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

Если ли что-то ещё, что ты знаешь? Потому что про язык Си ты не знаешь примерно ничего.

Твоего языка Си я точно не знаю (который ты себе навыдумывал) и знать не хочу, ты код скомпилировать готовый не можешь, о чем тут говорить…

Я тебе фолиантом Розенталя по щщам надектую как-нибудь!

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

И щщи, пожалуй - твоя генетическая особенность, ты в этом разбираешься, как я посмотрю, клоун…

PS

Если ли

Бери фолиант и долби себе в «щщи» - тебе не привыкать…

8 битное железо не трогаем

Трогаем-трогаем. На AVR удобно порты и сервисы делать через теймплейты. И в целом код инкапсулировать в классы. Результирующий бинарь был плюс-минус пара байт относительно Си-подхода.

Хозяин барин. Просто сейчас условная ATMega и STM32F4 стоят +- одинаково, но в F4 мы ещё сверху получаем DSP и большую частоту камня. С другими сериями ценовая категория +- та же, но фарша в STM32 больше.

Но в целом я с вами согласен:

И в целом код инкапсулировать в классы. Результирующий бинарь был плюс-минус пара байт относительно Си-подхода.

А по скорости работы и в размере используемых ресурсов во сколько проиграл?))

Там не так много плюсов, сколько минусов появляется. Помимо порой магии в режиме отладки появляется излишнее потребление ресурсов/снижение скорости работы, да и при мне на f407 у одного индивидуума стека не хватило… Так что если удобно что-то оформить классом, на мой взгляд, лучше взять Си и структуру с таблицей виртуальных функций например.

Ну да, сишечники реально тупые :(

Даже мне их тут троллировать надоело. Это как младенцев пинать.

Ну попробовал попинать и пиналка сломалась…??? Оказался ты клоуном, который простой код не может скомпилировать, да и смысл написанного слабо улавливает…

PS Твоей подружке u-235 привеД…

Какой ещё магии? Может тебе лучше отлежаться?

Я писал под F1, F3 и F4 на плюсах и ни разу не было никакой «магии при дебаге», излишнем потреблении ресурсов или нехватки стека. Перед тем, как готовить, стоит сначала научиться готовить – почитайте статьи, покурите манулы, спросите у LLM на худой конец.

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

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

А по скорости работы и в размере используемых ресурсов во сколько проиграл?))

Шаблоны. Шаблоны жи есь.

namespace mcu {
	template<uint8_t R, uint8_t B>
	class MyPin
	{
	public:
	static void dirIn() { _SFR_IO8(R-1) &= ~(_BV(B)); }
	static void dirOut() { _SFR_IO8(R-1) |= _BV(B); }
	static bool get() { return _SFR_IO8(R) & _BV(B); }
	static void set() { _SFR_IO8(R) |= _BV(B); };
	static void clear() { _SFR_IO8(R) &= ~(_BV(B)); }
	static void flip() { _SFR_IO8(R) ^= _BV(B); }
	static void write(bool v) { v ? set() : clear(); }
	
	static bool read() { return _SFR_IO8(R-2) & _BV(B); }
	};
}
...	
	using MyPinB0 = MyPin<PORTB_ID, PORTB0>;
	using MyPinB1 = MyPin<PORTB_ID, PORTB1>;
	using MyPinB2 = MyPin<PORTB_ID, PORTB2>;
	using MyPinB3 = MyPin<PORTB_ID, PORTB3>;
...
	using Buzzer = BuzzerImpl<mcu::MyPinD3>;
	using SegmentG = mcu::MyPinB1;
	using SegmentP = mcu::MyPinB5;

	using CommonOne = mcu::MyPinC1;
	using CommonTwo = mcu::MyPinC2;
	using CommonThree = mcu::MyPinC3;
	using CommonFour = mcu::MyPinC0;
...
	// real code:
	SegmentF::dirOut();
	SegmentG::dirOut();
	SegmentP::dirOut();
			
	CommonOne::dirOut();
	CommonTwo::dirOut();
	CommonThree::dirOut();
	CommonFour::dirOut();

Я писал под F1, F3 и F4 на плюсах и ни разу не было никакой «магии при дебаге», излишнем потреблении ресурсов или нехватки стека. Перед тем, как готовить, стоит сначала научиться готовить – почитайте статьи, покурите манулы, спросите у LLM на худой конец.

Не исключено, что у Вас магии не было, я сам плюсы под МК не приемлю, просто наблюдал как человек в итоге дебажился через логи, т.к. все вроде работало, а в дебагере чушь…

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

ну не так там и сложно выходит, тем более, что сверхестественного там ничего нет (все ядро линукса так написано), тут на вкус и цвет короче, но на Си работает быстрее…

Шаблоны. Шаблоны жи есь.

Ну так и в Си - макросы же есть… Тут вкус, цвет и какая производительность/размер нужен/возможен.

туда же куда при аналогичных командах из асм, очевидно…

Правда? Потому что компилятор их выкинул.

Проверь и не фантазируй, я тебе про это уже писал, твои фантазии - только твое дело:

$ clang -std=c23 kr.c 
kr.c:3:12: error: unknown type name 'a'
    3 | int my_foo(a, b)
      |            ^
kr.c:3:15: error: unknown type name 'b'
    3 | int my_foo(a, b)
      |               ^
kr.c:3:17: error: expected ';' after top level declarator
    3 | int my_foo(a, b)
      |                 ^
      |                 ;
kr.c:6:1: error: expected identifier or '('
    6 | {
      | ^
4 errors generated.

Тыдымц тыдымц. Что ты там писал?

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

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

Бери фолиант и долби себе в «щщи» - тебе не привыкать…

Вот это полыхает! Отличненько!

Ну так и в Си - макросы же есть…

Не все макросы одинаково полезны. Я вроде так и не дождался комментария на свои вот такие цифры с четвертой страницы:

$ hyperfine ./testc
Benchmark 1: ./testc
  Time (mean ± σ):     12.305 s ±  0.034 s    [User: 12.288 s, System: 0.015 s]
  Range (min … max):   12.254 s … 12.345 s    10 runs

$ hyperfine ./testzig
Benchmark 1: ./testzig
  Time (mean ± σ):      4.250 s ±  0.004 s    [User: 4.237 s, System: 0.012 s]
  Range (min … max):    4.243 s …  4.256 s    10 runs

Правда? Потому что компилятор их выкинул.

ты глупость сморозил

clang -std=c23 kr.c

Тыдымц тыдымц. Что ты там писал?

Я ж говорю, что ты там в своих фантазиях живешь, если на gcc копипастой скомпилировать не можешь, то хоть номер стандарта соответствующий коду проставь… В твоем случае это:

clang -std=c99 kr.c

так уже должно заработать, рука-лицо…

Вот это полыхает! Отличненько!

Ты там здоров вообще, алеша?

Не все макросы одинаково полезны.

Эту ну прям субъективщина субъективная…

Я вроде так и не дождался комментария на свои вот такие цифры с четвертой страницы:

Видимо не мне писали или я пропустил… Что это и о чем разговор?

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

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

тут на вкус и цвет короче, но на Си работает быстрее…

Вот тут я поинтересуюсь потому что не уверен. А как runtime виртуальная таблица может быть быстрее (мы же говорим про скорость исполнения) чем compile time dispatching на концептах и темплейтах? Выше вам уже писали пример кода для класса Pin на плюсах. Виртуальная таблица с указателями это же и pointer inderection и inderect jump, а в случае использовании темплейтов нужная реализация «вставится» в код при компиляции.

то хоть номер стандарта соответствующий коду проставь… В твоем случае это: clang -std=c99 kr.c так уже должно заработать, рука-лицо…

Mergiraf -- новый движок разрешения конфликтов в коде (комментарий)

gcc -Wall -Wextra -pedantic -std=c23 2.c

Тут комментировать – только портить

Я ж говорю, что ты там в своих фантазиях живешь, если на gcc копипастой скомпилировать не можеш

clang -std=c99 kr.c

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

Ты там здоров вообще, алеша?

100%! И знаю как volatile пользоваться. А ты – нет.