The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Опубликован набор компиляторов LLVM 19

17.09.2024 23:08

После шести месяцев разработки представлен релиз проекта LLVM 19.1.0, развивающего инструментарий (компиляторы, оптимизаторы и генераторы кода), компилирующий программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован в машинный код для заданной целевой платформы или использован JIT-компилятором для формирования машинных инструкций непосредственно во время выполнения программы. На базе технологий LLVM проектом развивается компилятор Clang, поддерживающий языки программирования C, C++ и Objective-C. Начиная с прошлой ветки проект перешёл на новую схему формирования номеров версий, в соответствии с которой нулевой выпуск ("N.0") используется в процессе разработки, а первая стабильная версия снабжается номером "N.1".

Среди улучшений в Clang 19:

  • Добавлены возможности, определённые в Си-стандарте C23:
    • поддержка использования спецификатора constexpr для определения объектов;
    • макросы INFINITY, NAN, FLT_NORM_MAX, DBL_NORM_MAX и LDBL_NORM_MAX во float.h;
    • механизм "#embed" для интеграции бинарных ресурсов;
    • тип char8_t для строк и символов в UTF-8.
  • Обеспечена реализация всех возможностей, определённых в стандарте C++17. Завершающим звеном стало включение поддержки элементов для сопоставления параметров шаблона с совместимыми аргументами, которые были отключены по умолчанию из-за имевшихся проблем с совместимостью.
  • В режиме C++14 включена по умолчанию поддержка функции delete с указанием размера (sized deallocation),
  • Добавлены возможности, связанные со стандартом C++20: встроенные функции __is_layout_compatible и __is_pointer_interconvertible_base_of; полная поддержка выражений для импорта модулей; начальная поддержка автоматического определения типов аргументов шаблона класса для создаваемых при помощи шаблонов псевдонимов типов (CTAD для Alias Template).
  • Добавлены возможности, связанные со стандартом C++20: продление времени жизни временных объектов в циклах, перебирающих диапазоны; переносимые предположения; ослабление ограничений для constexpr и отключение диагностики "-Winvalid-constexpr"; поддержка статических и явных функций-членов объектов с одинаковыми списками параметров.
  • Добавлены возможности, связанные с будущим стандартом C++2с (C++26): индексирование пакета параметров в шаблонах; синтаксис '= delete("причина")'; атрибуты для структурированных привязок; запрет на привязку возвращаемого glvalue к временному значению; тривиальные бесконечные циклы без неопределенного поведения; вывод ошибки при удалении указателя на неполный тип; применение ограничений в выражениях свёртки ("...").
  • Добавлены новые флаги компилятора:
    • "-fsanitize=implicit-bitfield-conversion" для проверки неявного усечения и изменения знака при работе с битовыми полями.
    • "-fsanitize=implicit-integer-conversion" для проверки неявных преобразований целых чисел.
    • "-Wmissing-designated-field-initializers" для выявления отсутствующих инициализаторов полей.
    • "-fexperimental-modules-reduced-bmi" для включения урезанного BMI (Binary Module Interface) для именованных модулей C++20, позволяющего использовать стандартные модули C++.
    • "-fexperimental-late-parse-attribute" для включения позднего парсинга атрибутов в специфичных контекстах, например, атрибута counted_by.
    • "-fseparate-named-sections" для создания отдельных уникальных секций для глобальных символов в именованных специальных секциях.
    • "-fms-define-stdc" для совместимости STDC с MSVC.
    • "-Wc++23-compat" и "-Wc++2c-compat" - группы предупреждений для упрощения миграции на C++23 и C++26.
    • "-fdisable-block-signature-string" для отключения генерации строки с подписью для блоков.
    • "-fpointer-tbaa" для пометки несовместимых указателей, используя анализ алиасов на основе типов (TBAA).
  • Добавлены новые атрибуты: sized_by, counted_by_or_null, nonblocking, nonallocating, blocking, allocating, sized_by_or_null, amdgpu_max_num_work_groups(x, y, z).
  • Добавлены новые встроенные функции: __builtin_readsteadycounter, __builtin_popcountg, __builtin_clzg, __builtin_ctzg, __is_bitwise_cloneable.
  • Расширены средства диагностики и статического анализа, добавлены новые проверки.

Основные новшества LLVM 19:

  • В бэкенде для архитектуры RISC-V добавлена экспериментальная поддержка расширений Zabha (атомарные операции с памятью), Ssqosid, Ssnpm, Smnpm, Smmpm, Sspm и Supm (использование масок для указателей), Zba, Zbb, Zbs. Стабилизирована поддержка расширений Ztso, Zabha, Zaamo и Zalrsc.
  • В бэкенд для архитектуры AArch64 добавлена поддержка процессоров Cortex-R82AE, Cortex-A78AE, Cortex-A520AE, Cortex-A720AE, Cortex-A725, Cortex-X925, Neoverse-N3, Neoverse-V3 и Neoverse-V3AE.
  • В бэкенд для архитектуры ARM добавлена поддержка процессора Cortex-R52+.
  • Улучшены бэкенды для архитектур X86, LoongArch, WebAssembly, MIPS, PowerPC и AMDGPU.
  • Расширены возможности компоновщика LLD. Добавлены новые виды перемещений (relocations): CREL, GNU_PROPERTY_AARCH64_FEATURE_PAUTH, R_AARCH64_AUTH_ABS64 и R_AARCH64_AUTH_RELATIVE. Добавлен параметр "--compress-sections <section-glib>={none,zlib,zstd}[:level]" для выбора алгоритма сжатия секций.
  • В библиотеке Libc++ продолжена реализация возможностей стандартов C++20, C++23 и C++26.
  • C 3.6 до З.8 повышены требования к версии Python, необходимой для сборки LLVM.


 
  1. Главная ссылка к новости (https://discourse.llvm.org/t/l...)
  2. OpenNews: Доступен набор компиляторов LLVM 18
  3. OpenNews: Обеспечена возможность сборки ядра Linux в окружении macOS с LLVM
  4. OpenNews: Опубликованы результаты аудита безопасности кодовой базы LLVM
  5. OpenNews: Проект LLVM меняет схему нумерации версий
  6. OpenNews: Релиз набора компиляторов GCC 14
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/61882-llvm
Ключевые слова: llvm, clang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (63) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 23:21, 17/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +5 +/
    > механизм "#embed" для интеграции бинарных ресурсов;

    Джва года ждал.

     
     
  • 2.20, Аноним (20), 04:08, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    Там уже было, сам лично делал, только там нужно было делать финты пистоном.

    С23 очень годные изменения привнёс, второе пришествие С11.

     
     
  • 3.53, Аноним (53), 12:13, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Усложнять чистосишку тоже не надо.
     
  • 2.58, Аноним (58), 13:13, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    #embed "/etc/shadow"
     
     
  • 3.85, Аноним (-), 19:40, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • –1 +/
    > #embed "/etc/shadow"

    Билдуете под рутом? Ну так вам и надо тогда! Скажите спасибо что не "rm -rf /usr /bin/wtflol" в makefile :)

     

  • 1.4, Аноним (4), 23:53, 17/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +1 +/
    Предпочитаю классику c99.
     
     
  • 2.8, Вы забыли заполнить поле Name (?), 00:22, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +6 +/
    классика - это с89
     
     
  • 3.43, Аноним (43), 10:01, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • –12 +/
    Платформозависимый int – главное достижение человечества. Надо по рукам бить тех, кто тащит, например, uint64_t на 8-бит микруху. Код должен быть написан так, чтобы типы были без фиксированного размера. Тогда код будет на любой архитектуре работать оптимально.
     
     
  • 4.46, Аноним (-), 10:37, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +4 +/
    > Платформозависимый int – главное достижение человечества. Надо по рукам бить тех, кто тащит, например, uint64_t на 8-бит микруху.

    А кто ему запретит)?
    Это же не компилятор других языков, который будет лупить по рукам за кривой код.


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

    Отличная идея!
    int main(void) {
        int a = +2147483647;
        int b = a + 1;
        return 0;
    }
    выдает разные значения на разных платформах в зависимости от размера типа.


     
     
  • 5.54, Admino (ok), 12:14, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +6 +/
    > выдает разные значения на разных платформах в зависимости от размера типа.

    Сей код значений не выдаёт.

     
     
  • 6.78, Bottle (?), 14:23, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • –1 +/
    Хорошо, он забыл написать printf, но ты понял его мысль, а это главное.
     
  • 5.86, Аноним (-), 19:42, 19/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/



    Отличная идея!
    int main(void) {
        int a = +2147483647;
        int b = a + 1;
        return 0;
    }
    выдает разные значения на разных платформах в зависимости от размера типа.



    Этот код вроде бы везде только возвращает ОС нулевой код возврата и отваливает в туман. Вон то оптимизатор вообще может в ноль грохнуть. Side effects же нет.
     
  • 4.47, Аноним (43), 10:55, 18/09/2024 [^] [^^] [^^^] [ответить]  [] []     [к модератору]
  • +/
    > Отличная идея!

    Так у вас пример архитектурозависимого кода. Диды умещали в 256 всё необходимое, даже игры делали. Что изменилось? Люди обленились и не оптимизируют логически переменные.
    Да, некоторые переменные должны вмещать большие данные. Вот их, как единичные исключения, делать фиксированными.

     
     
  • 5.52, trolleybus (?), 11:17, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +1 +/
    > Диды умещали в 256 всё необходимое, даже игры делали.

    Так вот то, что в 256 помещается, и надо делать uint8_t. Кроме этого, есть всякие uint_least8_t, uint_fast8_t для оптимизации по скорости.

     
  • 5.57, i (??), 12:42, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    очень смешно
     
  • 5.68, _ (??), 19:01, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    >Диды умещали в 256 всё необходимое, даже игры делали.

    На Радио86 \ Микроша \ Sinclair *\ Yemaha MSX  int был 8 bit - surprise bro!

    >Что изменилось?

    На том, из чего ты накропал свой гениальный пост int - 64 bit ...

    >Люди обленились и не оптимизируют логически переменные.

    И правильно, пусть вон - ChatGPT с Copilot напрягаются! :)

     
     
  • 6.74, Аноним (74), 10:42, 19/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    int не может быть 8 бит даже в Нарнии, даже в Гаррипоттере, даже в C89.

    >На том, из чего ты накропал свой гениальный пост int - 64 bit ...

    Модель ILP64 встречалась на том, что давно в музее, поэтому нет, не 64 битный у него инт.

     
     
  • 7.91, _ (??), 23:49, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    > int не может быть 8 бит даже в Нарнии, даже в Гаррипоттере, даже в C89.

    Ну да - не может, лопухнулся :)
    Я его (Си) на такой технике почти не встречал, там BASIC + Asm и это всё что надо :)

     
  • 6.75, n00by (ok), 13:13, 19/09/2024 [^] [^^] [^^^] [ответить]  [] []     [к модератору]
  • +/
    >>Диды умещали в 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 object

    Page 38 HiSoft ZX C User Manual

    https://worldofspectrum.org/pub/sinclair/games-info/h/HiSoftC.pdf


     
     
  • 7.90, _ (??), 23:46, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Да лопухнулся я, чего там. Надо больше пить :)
     
  • 6.87, Аноним (-), 19:46, 19/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    >> Диды умещали в 256 всё необходимое, даже игры делали.
    > На Радио86 \ Микроша \ Sinclair *\ Yemaha MSX  int был 8 bit - surprise bro!

    Про int в стандарте сказано не менее 16 бит. Так что если у вас было вон то, это не по стандарту и сами там с своим самопалом разбирайтесь. На сях вон тех не особо програмили так то. В основном выбор был из васика да ассеблирования в машинных кодах.

    > На том, из чего ты накропал свой гениальный пост int - 64 bit ...

    Это без гарантий, мягко говоря.

    >> Люди обленились и не оптимизируют логически переменные.
    > И правильно, пусть вон - ChatGPT с Copilot напрягаются! :)

    Ну как бы рутинную работу на машины спихнуть - почему бы и нет? Машины для этого и делали.

     
  • 4.69, nc (ok), 23:04, 18/09/2024 [^] [^^] [^^^] [ответить]  [] []     [к модератору]
  • +1 +/
    Вообще говоря типы без фиксированного размера это частный случай трейтов. Т.е. мы говорим  "нам здесь нужен какой-то целочисленный тип с такими-то свойствами" и компилятор сам выводит этот тип. Если язык в явном виде поддерживает такое - это замечательно. Но Си поддерживает нечто очень урезанное (не вывод типа а платформозависимость), просто потому что так сложилось исторически, что плохо.
     
     
  • 5.71, Аноним (-), 00:37, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Дайте пожалуйста определение трейтов на С. Или вы не понимаете что такое трейты или я чего-то не понял.
     
  • 5.79, Bottle (?), 14:27, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +1 +/
    Это не случай трейтов. Это называется по другому: беззубый комитет стандартизаторов пытался написать стандарт, который будет соответствовать всем коммерческим компиляторам. А различия в компиляторах обусловлены тем, что Ритчи стучал своим слоником по PDP-11, так и не написав точную спецификацию языка, а лишь обрывочные фантазии.
     
  • 4.89, Аноним (89), 20:30, 19/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    Намного лучше когда, получив обрубленый int, код втихаря делает подляну - обруби... большой текст свёрнут, показать
     

  • 1.24, Аноним (24), 05:23, 18/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +/
    Самый адекватный СИшный компилер. У gcc, например, нет clangd.
     
     
  • 2.25, Хру (?), 07:06, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • –2 +/
    Так возьми и запили! Будет gccd и благодарность в примечаниях к выпуску. А так же очередь из рекрутеров из топ-компаний планеты :)
     
     
  • 3.61, Аноним (61), 16:23, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +1 +/
    > Так возьми и запили!

    Моей квалификации хеллоувротщика не хватит, увы.

     
  • 3.72, Аноним (-), 00:40, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Есть cmake. Хотя мне не нравится. Я хоть и любитель, вообще не Си программист, но могу запилить. Просто компилятор, который исследует изменение в файлах и начинает компиляцию? Это реально нужно?
     
     
  • 4.82, Аноним (-), 18:44, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Если я не верно понял - дайте пожалуйста определение clangd.
     
     
  • 5.92, _ (??), 23:55, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    О LSP слышал? Дык вот: clangd is a language server implementation.
     
  • 2.26, Аноним (26), 07:28, 18/09/2024 [^] [^^] [^^^] [ответить]  [] []     [к модератору]
  • –1 +/
    > У gcc, например, нет clangd.

    И не нужно.

     
     
  • 3.62, Аноним (61), 16:23, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Если писать хеллоуврот в nano может и не нужно.
     
  • 2.50, 12yoexpert (ok), 11:09, 18/09/2024 [^] [^^] [^^^] [ответить]  [] []     [к модератору]
  • –2 +/
    самый адекватный для копирастов, лицензия какбэ намекает
     
     
  • 3.63, Аноним (61), 16:24, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Тебя как программиста (если ты таковой) лицензия должна волновать в самую последнюю очередь.
     
     
  • 4.65, Аноним (-), 16:48, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Свободное Сообщество, FSF и GNU с тобой не согласны.
     
  • 2.55, Walker (??), 12:18, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    Они всё у GCC слизали!
     
     
  • 3.56, Аноним (56), 12:41, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • –2 +/
    > Они всё у GCC слизали!

    Что именно? Огласите список!

    Они создавались со свободной лицензией, как противовес раковому GCC.
    Чтобы не зависеть от левой (слегка погрызаной) пятки фанатиков, которым аж в 2009 году пришлось публиковать GCC Runtime Library Exception - без которых был спор является ли результат компиляции derivative work или нет.
    gnu.org/licenses/gcc-exception-3.1.html

     
     
  • 4.66, Аноним (-), 17:12, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • –2 +/
    1 1990-е гг корпорасты наивно полагали, что поскольку есть C , то чистая Сишк... большой текст свёрнут, показать
     
     
  • 5.70, Аноним (-), 23:14, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Какое господство гну Тогда они даже однопроцентниками не были Аппл боялась лиц... большой текст свёрнут, показать
     
  • 3.64, Аноним (61), 16:25, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • –2 +/
    Это не важно. Важно что они предоставляют фишки, которых нет у гцц. А лицензии волнуют только вахтеров.
     
     
  • 4.81, Аноним (-), 18:42, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    И какие же это фишки?
     

  • 1.27, хрю (?), 07:54, 18/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • –2 +/
    https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2809r3.html

    2024-03-21 !!! @Trivial infinite loops are not Undefined Behavior@ - далеки чуваки от народа, ой как далеки.

     
     
  • 2.29, Страуструп (?), 08:28, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Errorsoft, дело в том что не моя проблема, программисты пишут кривые оптимизаторы. Было дело ядро линукс не смогли собрать из за оптимизации в какой то новой GCC с флагом -o2.
     
     
  • 3.40, letsmac (ok), 09:42, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +1 +/
    С флагом -O2 GCC много чего не собирается. Питон недавно пробовал собрать на плате с arm7 с -O2  - не вышло.
     
     
  • 4.83, Аноним (-), 18:46, 19/09/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.34, n00by (ok), 09:16, 18/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +4 +/
    > В режиме 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.

     
     
  • 2.59, Вы забыли заполнить поле Name (?), 15:23, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Ну давай теперь покажи как язык с гц быстрее ручного управления, только на реальном примере.
     
     
  • 3.76, n00by (ok), 13:22, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • –1 +/
    >> кто верует в ... "free() всегда быстрее сборщика мусора"
    > Ну давай теперь покажи как язык с гц быстрее ручного управления, только
    > на реальном примере.

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

    Например, у меня на гитхапе лежит ВМ OCaml со сжимающим сборщиком мусора, и интерпретатор Рефал с автоматическим управлением памятью, что можно считать частным случаем сборщика мусора.

    Они есть и работают.

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

     

  • 1.35, Аноним123 (?), 09:31, 18/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +/
    >В режиме C++14 включена по умолчанию поддержка функции delete с указанием размера (sized deallocation),

    Кто-нибудь понял зачем это надо?

     
     
  • 2.38, Аноним (-), 09:33, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Бьёрн Страуструп об этом знает?
     
  • 2.39, Аноним123 (?), 09:34, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +1 +/
    Сам спашиваю и сам отвечаю:
    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.
     
     
  • 3.77, n00by (ok), 13:36, 19/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Помимо этого, есть вопрос "архитектуры". Допустим, получили от пользователя некое число n и аллоцировали n байт. Теперь это n хранится в двух местах: в менеджере кучи и в приложении. Зачем хранить джважды? С одной стороны, если уж хранится, можно было бы при освобождении проверять размер, отлавливать часть мелких ошибок. С другой, можно писать свой простейший аллокатор через mmap() и munmap().
     
     
  • 4.84, Аноним (-), 18:52, 19/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    Давно не имел дело с С++. Удивлен что появился сборщик мусора. А две ссылки нужны именно для его адекватной работы. В C# точно также 2 ссылки, но для более простого понимания придумали сказку о поколениях объектов - можете почитать.
     
     
  • 5.93, n00by (ok), 08:45, 20/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +1 +/
    Не две ссылки, а дважды хранится размер блока в куче. А "сборщик мусора" в плюсах всегда "был", как и в Си - кому нужен, те писали сами или брали BoehmGC.
     
  • 4.88, Аноним (-), 20:25, 19/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    И почитать можно в книге CLR via C#, Рихтера вроде
     

  • 1.42, Аноним (42), 09:53, 18/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • –1 +/
    Почему такой жирный сорс? Сколько там линухов вместили?
     
     
  • 2.60, Вы забыли заполнить поле Name (?), 15:24, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Там внутри жирный сотрудник анб.
     

  • 1.44, Аноним (43), 10:18, 18/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    > тип char8_t для строк и символов в UTF-8.

    Зачем вводить отдельное название для восьмибитного unsigned int?

     
     
  • 2.45, Аноним (43), 10:23, 18/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • –2 +/
    Смешнее этого, что пример не работает отсюда: https://en.cppreference.com/w/c/string/multibyte/char8_t
    Gcc с поддержкой c23 ругается на тип. Изменил на char – работает.
    В общем, любители свежевыжатого фреша придумывают лишние абстракции. Второй C++ не нужен.
     
     
  • 3.48, Аноним (-), 11:01, 18/09/2024 [^] [^^] [^^^] [ответить]      [к модератору]
  • +2 +/
    > char8_t

    гарантировано unsigned.
    А вот обычный char - как повезет.
    Напр. в gcc он по умолчанию signed, но не на всех платформах (можно настраивать через -funsigned-char, -fsigned-char)

    Так что это не "придумывают лишние абстракции", это приведение типа к однозначному поведению.
    Потому что в стандарте не удосужились описать каким должен быть char.

    > Gcc с поддержкой c23 ругается на тип.

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

     
  • 2.73, Аноним (-), 00:48, 19/09/2024 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    Потому что ты есть типы зависящие от платформы, а это независящий от платформы. Он будет работать одинаково на разных платформах.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру