После шести месяцев разработки представлен релиз проекта LLVM 19.1.0, развивающего инструментарий (компиляторы, оптимизаторы и генераторы кода), компилирующий программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован в машинный код для заданной целевой платформы или использован JIT-компилятором для формирования машинных инструкций непосредственно во время выполнения программы. На базе технологий LLVM проектом развивается компилятор Clang, поддерживающий языки программирования C, C++ и Objective-C. Начиная с прошлой ветки проект перешёл на новую схему формирования номеров версий, в соответствии с которой нулевой выпуск ("N.0") используется в процессе разработки, а первая стабильная версия снабжается номером "N.1"...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61882
> механизм "#embed" для интеграции бинарных ресурсов;Джва года ждал.
Там уже было, сам лично делал, только там нужно было делать финты пистоном.С23 очень годные изменения привнёс, второе пришествие С11.
Усложнять чистосишку тоже не надо.
#embed "/etc/shadow"
> #embed "/etc/shadow"Билдуете под рутом? Ну так вам и надо тогда! Скажите спасибо что не "rm -rf /usr /bin/wtflol" в makefile :)
Предпочитаю классику c99.
классика - это с89
Платформозависимый int – главное достижение человечества. Надо по рукам бить тех, кто тащит, например, uint64_t на 8-бит микруху. Код должен быть написан так, чтобы типы были без фиксированного размера. Тогда код будет на любой архитектуре работать оптимально.
> Платформозависимый int – главное достижение человечества. Надо по рукам бить тех, кто тащит, например, uint64_t на 8-бит микруху.А кто ему запретит)?
Это же не компилятор других языков, который будет лупить по рукам за кривой код.
> Код должен быть написан так, чтобы типы были без фиксированного размера. Тогда код будет на любой архитектуре работать оптимально.Отличная идея!
int main(void) {
int a = +2147483647;
int b = a + 1;
return 0;
}
выдает разные значения на разных платформах в зависимости от размера типа.
> выдает разные значения на разных платформах в зависимости от размера типа.Сей код значений не выдаёт.
Хорошо, он забыл написать printf, но ты понял его мысль, а это главное.
Отличная идея!
int main(void) {
int a = +2147483647;
int b = a + 1;
return 0;
}
выдает разные значения на разных платформах в зависимости от размера типа.
Этот код вроде бы везде только возвращает ОС нулевой код возврата и отваливает в туман. Вон то оптимизатор вообще может в ноль грохнуть. Side effects же нет.
> Отличная идея!Так у вас пример архитектурозависимого кода. Диды умещали в 256 всё необходимое, даже игры делали. Что изменилось? Люди обленились и не оптимизируют логически переменные.
Да, некоторые переменные должны вмещать большие данные. Вот их, как единичные исключения, делать фиксированными.
> Диды умещали в 256 всё необходимое, даже игры делали.Так вот то, что в 256 помещается, и надо делать uint8_t. Кроме этого, есть всякие uint_least8_t, uint_fast8_t для оптимизации по скорости.
очень смешно
>Диды умещали в 256 всё необходимое, даже игры делали.На Радио86 \ Микроша \ Sinclair *\ Yemaha MSX int был 8 bit - surprise bro!
>Что изменилось?
На том, из чего ты накропал свой гениальный пост int - 64 bit ...
>Люди обленились и не оптимизируют логически переменные.
И правильно, пусть вон - ChatGPT с Copilot напрягаются! :)
int не может быть 8 бит даже в Нарнии, даже в Гаррипоттере, даже в C89.>На том, из чего ты накропал свой гениальный пост int - 64 bit ...
Модель ILP64 встречалась на том, что давно в музее, поэтому нет, не 64 битный у него инт.
> int не может быть 8 бит даже в Нарнии, даже в Гаррипоттере, даже в C89.Ну да - не может, лопухнулся :)
Я его (Си) на такой технике почти не встречал, там BASIC + Asm и это всё что надо :)
>>Диды умещали в 256 всё необходимое, даже игры делали.
> На Радио86 \ Микроша \ Sinclair *\ Yemaha MSX int был
> 8 bit - surprise bro!Storage for individual variables is allocated in the same way. regardless of whether automatic or
static storage is used. First is storage for the basic types, then for derived types:
char 1 byte
int 2 bytes, least significant byte at lower address
unsigned 2 bytes, least significant byte at lower address
pointer 2 bytes. least significant byte at lower address. Contains address of
pointed-to objectPage 38 HiSoft ZX C User Manual
https://worldofspectrum.org/pub/sinclair/games-info/h/HiSoft...
Да лопухнулся я, чего там. Надо больше пить :)
>> Диды умещали в 256 всё необходимое, даже игры делали.
> На Радио86 \ Микроша \ Sinclair *\ Yemaha MSX int был 8 bit - surprise bro!Про int в стандарте сказано не менее 16 бит. Так что если у вас было вон то, это не по стандарту и сами там с своим самопалом разбирайтесь. На сях вон тех не особо програмили так то. В основном выбор был из васика да ассеблирования в машинных кодах.
> На том, из чего ты накропал свой гениальный пост int - 64 bit ...
Это без гарантий, мягко говоря.
>> Люди обленились и не оптимизируют логически переменные.
> И правильно, пусть вон - ChatGPT с Copilot напрягаются! :)Ну как бы рутинную работу на машины спихнуть - почему бы и нет? Машины для этого и делали.
Вообще говоря типы без фиксированного размера это частный случай трейтов. Т.е. мы говорим "нам здесь нужен какой-то целочисленный тип с такими-то свойствами" и компилятор сам выводит этот тип. Если язык в явном виде поддерживает такое - это замечательно. Но Си поддерживает нечто очень урезанное (не вывод типа а платформозависимость), просто потому что так сложилось исторически, что плохо.
Дайте пожалуйста определение трейтов на С. Или вы не понимаете что такое трейты или я чего-то не понял.
Это не случай трейтов. Это называется по другому: беззубый комитет стандартизаторов пытался написать стандарт, который будет соответствовать всем коммерческим компиляторам. А различия в компиляторах обусловлены тем, что Ритчи стучал своим слоником по PDP-11, так и не написав точную спецификацию языка, а лишь обрывочные фантазии.
> Платформозависимый int – главное достижение человечества. Надо по рукам бить
> тех, кто тащит, например, uint64_t на 8-бит микруху.Намного лучше когда, получив обрубленый int, код втихаря делает подляну - обрубив вычисления - при этом может не быть никаких warning'ов, и вот вы получаете на своем 8-бит уродце - какие-то баги. Если не повезет - через годик его работы (на 8-бит AVR бывают и управляющие штуки).
В целом это ведет к НЕПОРТАБЕЛЬНОМУ коду который дико багует - и хрен поймешь где и когда. Ибо запустить на AVR ubsan тоже вроде не судьба (на cortex M легкий вариант даже можно).
А вот явное указание битности - эту проблему решает. А заодно и хайлайтит "жиртреста" с потенциально тормозной математикой или жором оперативы.
> Код должен быть написан так, чтобы типы были без фиксированного размера.
> Тогда код будет на любой архитектуре работать оптимально.Он на практике на половине вообще работать не будет - или будет дико баговать, в хучшем случае еще и далеко не сразу. А корректно сишным "int" не полузуется чуть менее чем никто, достаточно -Wconversion вкатить и подивиться сколько потенциальных фапаков в типовом коде бывает.
Самый адекватный СИшный компилер. У gcc, например, нет clangd.
Так возьми и запили! Будет gccd и благодарность в примечаниях к выпуску. А так же очередь из рекрутеров из топ-компаний планеты :)
> Так возьми и запили!Моей квалификации хеллоувротщика не хватит, увы.
Есть cmake. Хотя мне не нравится. Я хоть и любитель, вообще не Си программист, но могу запилить. Просто компилятор, который исследует изменение в файлах и начинает компиляцию? Это реально нужно?
Если я не верно понял - дайте пожалуйста определение clangd.
О LSP слышал? Дык вот: clangd is a language server implementation.
> У gcc, например, нет clangd.И не нужно.
Если писать хеллоуврот в nano может и не нужно.
самый адекватный для копирастов, лицензия какбэ намекает
Тебя как программиста (если ты таковой) лицензия должна волновать в самую последнюю очередь.
Свободное Сообщество, FSF и GNU с тобой не согласны.
Они всё у GCC слизали!
> Они всё у GCC слизали!Что именно? Огласите список!
Они создавались со свободной лицензией, как противовес раковому GCC.
Чтобы не зависеть от левой (слегка погрызаной) пятки фанатиков, которым аж в 2009 году пришлось публиковать GCC Runtime Library Exception - без которых был спор является ли результат компиляции derivative work или нет.
gnu.org/licenses/gcc-exception-3.1.html
1. 1990-е гг. корпорасты наивно полагали, что поскольку есть C++, то чистая Сишка уже не нужна. В те времена люди впадали в оргазм при упоминании ООП. Все как мантру повторяли три кита ООП: инкапсуляция, наследование, полиморфизм. Из всего этого следует второй пункт.
2. Просто все забили на чистый Си и поддержку его стандартов в своих коммерческих компиляторах. Из всего этого следует третий пункт.
3. И вот вдруг корпорасты остались у разбитого корыта. Не было компилятора Си, который бы поддерживал последние стандарты языка Си, все коммерческие компиляторы застряли на уровне ANSI С89.1990-е только Линус Торвальдс и GNU знали, что чистая Сишка - это реальная тема. В нулевые GCC, был единственным рабочим компилятором чистого Си. И тут корпорасты спохватились...
LLVM появился не от того, что его разработчики любят Си, а от того, что Apple боялась господства GNU, и поэтому она влила в один университетский проект много денег.За годы господства ООП новое поколение программистов тупо не могло написать процедурный код с его алгоритмами. На первых порах разработчики LLVM тупо копировали целые куски исходного текста из GCC, сейчас, сами конечно они в этом не признаются.
> LLVM появился не от того, что его разработчики любят Си,
> а от того, что Apple боялась господства GNU, и поэтому она влила в один университетский проект много денег.Какое господство гну? Тогда они даже однопроцентниками не были.
Аппл боялась лицензионной грязности гнурака. Причем не только эпл.
Вспомни по какой причине BSD с по настоящему свободной лицензией пришлось в срочном порядке менять компилятор и почему впоследствии появился GCC Runtime Library Exception.
Но это было неприемлемо для всех остальных свободных проектов тоже. А гнутики один раз уже замарались и больше к ним доверия не было. Поэтому в LLVM поддержали и другие участники.> На первых порах разработчики LLVM тупо копировали целые куски исходного текста из GCC
Угу... и нарушали GPL? Какой только дичи не увидишь от кекспертов...
> сейчас, сами конечно они в этом не признаются.
Давай пруфы в студию. История коммитов есть, так что показывай, что именно они сперли из гцц.
Это не важно. Важно что они предоставляют фишки, которых нет у гцц. А лицензии волнуют только вахтеров.
И какие же это фишки?
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p28...2024-03-21 !!! @Trivial infinite loops are not Undefined Behavior@ - далеки чуваки от народа, ой как далеки.
Errorsoft, дело в том что не моя проблема, программисты пишут кривые оптимизаторы. Было дело ядро линукс не смогли собрать из за оптимизации в какой то новой GCC с флагом -o2.
С флагом -O2 GCC много чего не собирается. Питон недавно пробовал собрать на плате с arm7 с -O2 - не вышло.
Я думал это только у меня так. А это у всех компиляторов такая проблема?
> В режиме C++14 включена по умолчанию поддержка функции
> delete с указанием размера (sized deallocation)Кому лень ходить по ссылке и кто верует в "Си быстрее плюсов" и "free() всегда быстрее сборщика мусора":
Modern memory allocators often allocate in size categories, and, for space efficiency reasons, do not store the size of the object near the object. Deallocation then requires searching for the size category store that contains the object. This search can be expensive, particularly as the search data structures are often not in memory caches.
Ну давай теперь покажи как язык с гц быстрее ручного управления, только на реальном примере.
>> кто верует в ... "free() всегда быстрее сборщика мусора"
> Ну давай теперь покажи как язык с гц быстрее ручного управления, только
> на реальном примере.То есть ты полагаешь, что какой-то ноунейм может меня взять на "слабо". Хорошо, поиграем по твоим правилам.
Например, у меня на гитхапе лежит ВМ OCaml со сжимающим сборщиком мусора, и интерпретатор Рефал с автоматическим управлением памятью, что можно считать частным случаем сборщика мусора.
Они есть и работают.
Ну давай теперь на выбор что-то из этого сделай с ручным управлением памятью.
>В режиме C++14 включена по умолчанию поддержка функции delete с указанием размера (sized deallocation),Кто-нибудь понял зачем это надо?
Бьёрн Страуструп об этом знает?
Сам спашиваю и сам отвечаю:
Modern memory allocators often allocate in size categories, and, for space efficiency reasons, do not store the size of the object near the object. Deallocation then requires searching for the size category store that contains the object. This search can be expensive, particularly as the search data structures are often not in memory caches.
Помимо этого, есть вопрос "архитектуры". Допустим, получили от пользователя некое число n и аллоцировали n байт. Теперь это n хранится в двух местах: в менеджере кучи и в приложении. Зачем хранить джважды? С одной стороны, если уж хранится, можно было бы при освобождении проверять размер, отлавливать часть мелких ошибок. С другой, можно писать свой простейший аллокатор через mmap() и munmap().
Давно не имел дело с С++. Удивлен что появился сборщик мусора. А две ссылки нужны именно для его адекватной работы. В C# точно также 2 ссылки, но для более простого понимания придумали сказку о поколениях объектов - можете почитать.
Не две ссылки, а дважды хранится размер блока в куче. А "сборщик мусора" в плюсах всегда "был", как и в Си - кому нужен, те писали сами или брали BoehmGC.
И почитать можно в книге CLR via C#, Рихтера вроде
Почему такой жирный сорс? Сколько там линухов вместили?
Там внутри жирный сотрудник анб.
> тип char8_t для строк и символов в UTF-8.Зачем вводить отдельное название для восьмибитного unsigned int?
Смешнее этого, что пример не работает отсюда: https://en.cppreference.com/w/c/string/multibyte/char8_t
Gcc с поддержкой c23 ругается на тип. Изменил на char – работает.
В общем, любители свежевыжатого фреша придумывают лишние абстракции. Второй C++ не нужен.
> char8_tгарантировано unsigned.
А вот обычный char - как повезет.
Напр. в gcc он по умолчанию signed, но не на всех платформах (можно настраивать через -funsigned-char, -fsigned-char)Так что это не "придумывают лишние абстракции", это приведение типа к однозначному поведению.
Потому что в стандарте не удосужились описать каким должен быть char.> Gcc с поддержкой c23 ругается на тип.
Потому что у гыцыцы поддержка с23 омно.
Просто пользуйся нормальным компилятором. Например тем, что указан в заголовке новости.
И все будет работать.
Потому что ты есть типы зависящие от платформы, а это независящий от платформы. Он будет работать одинаково на разных платформах.