Rust и двусвязный список

Да, на них.

Ну да, при использовании голой многопоточности нужно страдать :)

Я тоже так умею: «сегфолты — удел новичков, норм кодеры сразу пишут корректную работу с памятью»

Ага, ну т.е. разницу между compile time и runtime ошибками мы не видим, и почему 1-е лучше 2-го не понимаем.

Что ж, продолжайте писать на паскале дальше.

а написать «что такое конфетка» (ну там фичи, goals, not goals) тебе этические заморочки позволяют?

Вот задумался над этим вопросом. Ох как всё запутано. В ЛОРе ты потеряешься, т.к. нет лички, заходи в телегу, там есть канал и при нём чат: https://t.me/JAOS_OS_na_russkom_jazyke

Так-то вообще явно не хватает чего-то подобного RAII или try-with-resources. Оберон - это ископаемое, когда его делали, не понимали, что закрывать файлы в финалайзере - это беда.

И плюс к тому там можно размещать на стеке записи, но нельзя размещать о-объекты (которые из ООП). Это хочется исправить, поэтому я решил заглянуть, как обстоят дела в Расте, который прошёл по этому пути гораздо дальше. Увиденное пока не впечатляет.

Соответственно, нужно сделать концепцию владения, но не как в Расте, а как-то по-другому.

Также не хватает размещения на стеке массивов переменного размера, как в C99.

Вот такие три мелочи.

Как-то здесь начали обсуждать гипотетическую замену C++, поэтому не грех набросить ссылку на очередного убийцу, под названием Carbon:

https://github.com/carbon-language/carbon-lang

Обсуждение на Reddit-е:

https://www.reddit.com/r/cpp/comments/w2t2zn/carbon_an_experimental_successor_to_c/

PS. У самого пока не было времени ознакомиться, просто краем глаза на README посмотрел.

Взаимодействие с C++ вплоть до шаблонов - не выглядит многообещающим.

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

И сделать свой маллок-велосипед.

Какой ещё маллок-велосипед, болезный? Никакого маллока, никакого списка свободных ячеек. В самом простом случае ты вообще можешь просто вектор пересоздать через into_iter().filter(…).collect() и даже тогда это будет эффективнее чем связный список.

Тут я - мастер костылей

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

А ты когда-нибудь сам разрабатывал ЯП?

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

по-моему, это здесь называется «вызывающе неверная информация»? Которой тут на протяжении 10 моих страниц ты постоянно мусоришь, вперемежку с оскорблениями всех подряд. Взываю гнев небес на тебя.

И что? И объекты иногда удаляют. Какая трагедия, кто-то free сделал.

И всё. Это гвоздь в крышку гроба твоей идеи смухлевать, избежав итерации.

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

Так что в реале будет либо фильтрация всего списка, т.е. обход с удалением по условию, либо поиск + фильтрация.

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

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

Серьезные, общего назначения, нет.

Только вот вопрос, нужно ли быть курицей, чтобы рассуждать о вкусе яиц?

Хотя в вашем случае даже этот вопрос неуместен.

Carbon

Годно, в данном контексте очень даже. Но это

Carbon is currently an experimental project.

Ну и беглое знакомство с топиком показало, что это пока что «недо-С++» с другим синтаксисом и некоторыми переделками типа частичного type erasure в дженериках. Не вижу с ходу метапрограммирования и метаданных (аннотаций), и что там с тулингом. Если уже язык соотносится с TypeScript, то последний добавляет в JavaScript аннотации и мощный тулинг вокруг них.

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

Не вижу с ходу метапрограммирования и метаданных (аннотаций)

Как-то так: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/metaprogramming.md

:)))

Благодарю!

по-моему, это здесь называется «вызывающе неверная информация»?

Предложение сделать бенч - это «вызывающе неверная информация»? Ты с факультетом теологии не перепутал?

Взываю гнев небес на тебя.

В смысле опять стучишь модеру?

А что общего у яйца и ЯП?

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

Или мне нужно доступно изложить почему мнение den73 о языках вроде C++ и Rust-а меня не интересует и даже радует тот факт, что den73 не может их освоить?

Да, изложи.

Если бы разрабатывал, то понял бы, что слова «полное взаимодействие с X» накладывают дофигища ограничений на дизайн.

Например, у тебя есть библиотека на Карбоне и библиотека на С++.

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

даже радует тот факт, что den73 не может их освоить?

Это вообще-то клевета. Ну-ка бегом доказательство того, что я _не_могу освоить С++ в студию.

Да, изложи.

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

Но если попытаться оставаться в рамках политкорретности, то:

• он маргинал, застрявший в Lisp/TCL/Oberon, и никак (ну вот вообще никак) не влияющий на происходящее в индустрии. Так что все, что он говорит (хоть в адрес C++, хоть в адрес Rust) есть ни что иное, как «собака лает, караван идет». Более того, поскольку в силу своего развития он даже не может освоить предмет своей «критики», то для людей в теме его потуги вызывают, в лучшем случае, лишь ироническую ухмылку.

• такие как он, уж не знаю почему (собственные версии озвучивать не стану из-за привычки den73 стучать модераторам) не могут толком освоить C++ (подозреваю, что у них толком и чистый Си не так, чтобы уж). А посему, когда такие люди программируют на плюсах, то получается редкостное Г, тормознутое, жручее, текущее и падающее. Да еще и из-за завышеного ЧСВ таким персонажам хрен объяснишь как делать не нужно. Их даже Core Guidelines не заставишь прочитать, не говоря уже о том, чтобы осмыслить и принять на вооружение рекомендации оттуда. Поэтому чем меньше подобных den73 программируют на C++, тем лучше всей C++ной экосистеме.

Это вообще-то клевета.

Модератору уже пожаловались?

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

Если бы разрабатывал, то понял бы, что слова «полное взаимодействие с X» накладывают дофигища ограничений на дизайн.

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

Во-вторых, а можно полюбопытствовать что сделали в языкостроении лично вы? Может что-то уровня Pike или Ch? Может хотя бы сотня никак не связанных с вами разработчиков результатами ваших трудов воспользовалась.

Ты уже сбегал за доказательством того, что я не могу осилить C++? Есть такое понятие «отвечать за базар», его не только сержанты знают, а даже гопники. Оно, видимо, не про тебя, я правильно понимаю?

На форуме есть правила, ты должен либо их соблюдать, либо заткнуться.

сказать, что вокруг полно тупых баранов, я, наверное, могу.

den73, великие слова великих людей (нет).

Ты уже сбегал за доказательством того, что я не могу осилить C++?

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

Есть такое понятие «отвечать за базар»

Я смотрю, вы еще и бокс по переписке пытаетесь практиковать.

У тебя даже с логикой плохо, не то, что с этикой.

#define «освоить».

Если речь просто о том, чтобы его «изучить» как 4-5-6-й языки, в этом нет ничего сложного. А вот если речь о том, чтобы его начать использовать, то у тебя другая парадигма совсем. Этот язык не для тебя.

В самом простом случае

Ну да. А в сложном что?

И вот ты, на голубом глазу, предлагаешь

Ты сарказма не понял походу.

можно даже при итерации

Да куда ты собрался итерироваться по куче нод разбросанных хер пойми где? Ссылочные структуры - не про супер быструю итерацию. Это про то, чтобы за 20 медленных найти то, что тебе надо вместо того, чтобы лимонить подряд 100к, но быстрых. Это чтобы можно было быстро пришить голову к хвосту и наоборот без прохода с копированием и прочий изврат который на массивах/векторах делать дорого и стрёмно. А у вас - руст не умеет - значит это не нужно и задач где это нужно - нет. А еще кококо, системный язык. Тьфу.

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

Двусвязный список - это основная структура данных. Школьная. А у тебя язычок её не может. Связанные структуры бывают всякие разные. Не только списки. Графы. В графы руст тоже не умеет, надо костылить его через вектор? Го, вон, в циклические ссылки, говорят, не умеет. Еще один инвалид херов. Нет, что бы не делать языки которые могут, взяли тупую моду делать такие, которые не могут. А то вдруг кодерки сделают чего. Надо им не дать!

Го, вон, в циклические ссылки, говорят, не умеет.

Откуда дровишки?

Да тоже на лоре где-то срались лет 5 назад. Может что-то поменяли. Один хер, исключения так и не сделали. Зачем они нужны.

Ты сарказма не понял походу.

Т.е. когда ты предлагал удалять из середины списка без итерации по нему, это был сарказм? Ну ок, не понял значит. Значит возвращаемся к моему утверждению: вся мнимая польза вставки/удаления в середине списка списка с лихвой уйдёт в тот момент, когда будешь искать место для вставки/удаления.

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

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

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

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

Ну да. А в сложном что?

В зависимости от целей. Я тебе так-то несколько вариантов накидал, причём ни один из них не подходит на увиденный тобой «кастомный аллокатор».

Двусвязный список - это основная структура данных. Школьная.

Всё правильно написал, именно что школьная. Придумали её на заре IT, в 60х добавили её изучение на первый курс по программированию и с тех пор она передаётся из поколения в поколение людьми, которые ни наукой не занимаются, ни практически ничего сложнее курсовика не писали. Где-то в параллельной вселенной от них живут настоящие учёные, изобретающие вменяемые алгоритмы и структуры, а также простые работяги, которые может ничего и не изобретут, но по крайней мере знают что на практике применимо, а что - игрушки.

Не только списки. Графы. В графы руст тоже не умеет, надо костылить его через вектор?

Тут есть такой интересный момент: связные списки я в студенчестве делал во время всяких лабораторок. Больше не пригодились. Деревья тоже делал. А вот графы на указателях - никогда. Даже на лабораторках их всегда делают через массивы, собственно если потратить 1 минуту на обдумывание причина очевидна, нода в графе может быть вообще недостижима ниоткуда. Либо достижима по нескольким путям. Как ты собрался перечислять эти ноды? Хочешь - не хочешь, тебе придётся заводить общий контейнер содержащий все ноды графа, т.е. дополнительный список либо массив. А мы в общем-то уже выяснили, что массив предпочтительнее.

Ребят, списки применяются очень широко, но в своем intrusive варианте. O(1) на все точечные операции с низкими скрытыми константами. Выделение памяти для узлов для таких списков обычно делается из пула. ХЗ как Rust себя тут поведет. Возможно, всё будет измазано unsafe.

Графы на массивах делают только в dense варианте, когда количество ребер значительно больше количества вершин. Иначе, делают списками. Потому что память – золотая.

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

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

массив это упорядоченное множество элементов ОДНОГО типа(если не рассматривать костыли типа union), аллокированных как непрерывная область памяти.

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

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

преимущество массива - наиболее оптимальное использование памяти под N элементов типа T, максимально быстрая итерация. быстрое аллокирование/деаллокирование (поскольку на весь массив целиком).

недостатки - вставка/удаление элементов сложности O(n), фиксированный размер массива, для динамического массива, при превышении размера, переписывание всего массива в большую область памяти.

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

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

Модеру сообщил, конечно. Слово «настучать» в данном случае неуместно.

Да-да-да, ты не стукачок, ты просто порядок любишь.

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

#include <vector>
#include <list>
#include <cinttypes>
#include <iostream>
#include <chrono>
#include <cstring>

const size_t PAYLOAD_SIZE = 64;

struct Payload
{
    uint8_t data[PAYLOAD_SIZE];
};

struct List;
struct Node
{
    //Node *prev = 0;
    Node *next = 0;
    //List *parent = 0; 
    Payload payload;
};

struct List
{
    Node *first = 0;
    //Node *last = 0;
    Node& push_front(const Payload& data)
    {
        auto node = new Node();
        node->payload = data;
        //node->parent = this;
        node->next = first;
        //if (!first) last = node;
        //else first->prev = node;
        first = node;
        return *node;
    }
    ~List()
    {
        auto node = first;
        while(node)
        {
            auto next = node->next;
            delete node;
            node = next;
        }
    }
};

int main(int argc, char**argv){
    typedef std::chrono::high_resolution_clock Clock;
    if (argc != 3)
    {
        std::cout << "Usage: " << argv[0] << " type count\nwhere type = vector | list | simpliestlist"<<std::endl;
        return 0;
    }
    size_t items_count = strtoumax(argv[2], NULL, 10);
    
    
    auto t1 = Clock::now();
    if (strcmp(argv[1], "list") == 0)
    {
        std::cout<<"With std::list";
        
        std::list<Payload> list;
        for(size_t i = 0; i < items_count; i++)
            list.push_front(Payload());
    }
    else if (strcmp(argv[1], "simpliestlist") == 0)
    {
        std::cout<<"With simpliest custom list";
        
        List list;
        for(size_t i = 0; i < items_count; i++)
            list.push_front(Payload());
    }
    else if (strcmp(argv[1], "vector") == 0)
    {
        std::cout<<"With std::vector";
        std::vector<Payload> vec;
        for(size_t i = 0; i < items_count; i++)
            vec.push_back(Payload());
    }
    else
    {
        std::cerr << "Unknown type: " << argv[1]<<std::endl;
        return -1;
    }
    
    auto t2 = Clock::now();
    
    std::cout<<" allocation/deallocation of "<< items_count <<" items ("<< sizeof(Payload)<<" bytes each) took " << std::chrono::duration_cast<std::chrono::microseconds>(t2 - t1).count() << " microseconds" << std::endl;
    return 0;
}

Самый примитив, просто создание контейнера, хранящего айтемы по 64 байта каждый, добавление в него указанного пользователем количества айтемов, уничтожение контейнера. Никакого читерства типа преаллокации вектора. Никакой итерации (ну, кроме необходимой в деструкторе). Всего 3 контейнера, стандартный вектор, стандартный двусвязный список, и самый примитивный односвязный список. Так вот, до миллиона включительно вектор со всеми реаллокациями уделывает обе реализации списков. Стандартный список медленнее стандартного вектора даже при 100 млн элементов (8 сек против 6.5). Примитивнейший односвязный список на 10 млн начинает обгонять вектор, но не то что бы сильно, на 100 млн разбегается, там вектор аж на 40% медленнее чем простейший список. Вероятно если увеличивать количество элементов, наступит момент, когда реаллокация станет слишком дорогой, тогда возможно и стандартный список обгонит наконец вектор, однако 100 млн записей по 64 байта - это уже 6 гигов. Не великовато-ли для простенького контейнера? И стоит ли оно, учитывая как ушатает этот список кучу?

В общем жду критики экспертов, которые мне объяснят, что ни смотря ни на что списки всё равно нужны, Кнут с Виртом их нам завещали и мы не посрамим.

Графы на массивах делают только в dense варианте, когда количество ребер значительно больше количества вершин. Иначе, делают списками. Потому что память – золотая.

фейспалм.

Вот есть у меня вершина, и из неё выходит неизвестное количество рёбер. Может ни одного, а может и в каждую вершину. Что мне нужно для хранения? Очевидно, контейнер нужен. А что в контейнере? Ну на выбор, или 32битные индексы в массиве, или указатели 64 бита + ещё сбоку дополнительный указатель, который уже не ребро, а просто нужен чтоб все вершины графа перебирать. Что выбрать, если памяти жалко?

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

Ну да, если тебе нужен произвольный тип и ты в базовый тип добавил ссылки на предыдущий/следующий, тогда у тебя может что-то и выйдет. Но если на практике, то грузом у тебя какие-то настоящие типы, то список у тебя будет типа list<unique_ptr<Base>> и это будет аналогом vector<unique_ptr<Base>>. Кстати, не факт что vector<unique_ptr<Base>> будет медленнее чем даже список с полями next/prev в базовом классе.

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

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

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

Ты тоже по книжкам из 60х учился? Главный недостаток - не дружит с кэшем. На сраные 2 указателя всем вообще плевать.

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

Я бы сформулировал иначе. Если в «руст» не могут специалисты считающие что недостаток списка - лишние 2 указателя, то тем лучше для «руста».

Самый примитив, просто создание контейнера, хранящего айтемы по 64 байта каждый, добавление в него указанного пользователем количества айтемов, уничтожение контейнера. Никакого читерства типа преаллокации вектора. Никакой итерации (ну, кроме необходимой в деструкторе). Всего 3 контейнера, стандартный вектор, стандартный двусвязный список, и самый примитивный односвязный список. Так вот, до миллиона включительно вектор со всеми реаллокациями уделывает обе реализации списков.

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

в данном случае списки тормозят на new.

заполни списки/массивы свои 10 тыс элементов(это время не мерить), и мерь время мильона вставок/удалений например первого элемента списка и массива. список брать std:list.

удаляемый из списка элемент не деалокируй. удалил из списка, вставил обратно. чтобы не было new/delete

заполни списки/массивы свои 10 тыс элементов(это время не мерить), и мерь время мильона вставок/удалений например первого элемента списка и массива. список брать std:list.

Даже тут не смог. Гугли кольцевые массивы. std::deque. И вставляй/удаляй хоть первый, хоть последний элементы.

Даже тут не смог. Гугли кольцевые массивы. std::deque. И вставляй/удаляй хоть первый, хоть последний элементы.

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

и врубись уже, что массивы и списки,это не про с++ вообще. и не про руст. а про типы данных.

ты сначала смоги. удаляй тогда второй элемент или третий.

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

И, кстати, если будешь брать std::list то тоже полная жопа будет: видишь ли, в пейлоаде нету полей для указателя, а нода - внутренняя структура листа. Так что в предложенном тобой варианте ноды для списка будут точно так же постоянно аллоцироваться/освобождаться, так что опять будешь замерять new/delete, в то время как вектор будет просто в выделенной памяти один кусок переписывать и 1 указатель увеличивать/умкеньшать. В моём бенчмарке обрабатывалось как раз самое сложное для массива - реаллокация при росте.

причем тут вообще массивы, если deque - это типа кольцевая очередь.

Это массив. Один из вариантов массива. Заметь, если бы ты не подгонял условие, а просто предлагал бы замерять LIFO, можно было бы обойтись обычным вектором, добавлять/удалять конец. Но коль скоро ты мухлюешь, ну вот тебе чуть другая реализация, deque.

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

и врубись уже, что массивы и списки,это не про с++ вообще. и не про руст. а про типы данных.

Ты троллишь что ли? Вроде для тролля слишком много написал.

Там есть исключения, называются паника и для быдла запрещены. Но аристократы вполне используют, см. «Panic like a pro».

https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/metapro...

У меня по твоей ссылке почти пусто; вот тут довольно много написано https://github.com/josh11b/carbon-lang/blob/99c568e66300dd90526f706634dfdf640...

Сходу фатальный недостаток у языка обнаружить не удалось, придется язык поизучать :-)

Можно еще https://www.circle-lang.org/ упомянуть в контексте метапрограммирования. Но он закрытый. На сколько я помню, основан на clang.