Пример:

#include <stdio.h>
#define i_key int
#include "stc/vec.h"
#define i_key int
#include "stc/stack.h"
#include "stc/cspan.h"

using_cspan(intspan, const int);


void printMe(intspan container) {
    printf("%d:", (int)cspan_size(&container));
    c_foreach (e, intspan, container)
        printf(" %d", *e.ref);
    puts("");
}


int main(void)
{
    printMe( c_make(intspan, {1, 2, 3, 4}) );

    int arr[] = {1, 2, 3, 4, 5};
    printMe( (intspan)cspan_from_array(arr) );

    vec_int vec = c_make(vec_int, {1, 2, 3, 4, 5, 6});
    printMe( (intspan)cspan_from(&vec) );

    stack_int stk = c_make(stack_int, {1, 2, 3, 4, 5, 6, 7});
    printMe( (intspan)cspan_from(&stk) );

    intspan spn = c_make(intspan, {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12});
    printMe( (intspan)cspan_subspan(&spn, 2, 8) );

    // cleanup
    vec_int_drop(&vec);
    stack_int_drop(&stk);
}

Ну хер знает, чёт напомнило LibCello от Даниэля, одна из самых прикольных, но тем не менее упоротых, в хорошем смысле, C библиотек, там тоже выкрутасы на макросах будь здоров и даже сборщик мусора есть хехе :)

• https://libcello.org/

Да их куча. Форк https://github.com/rurban/ctl, например, от автора SMhasher.

библиотеки STC (header-only)
Новая основная система сборки с Meson.

Так header-only или библиотеку Мезоном собирать?

и свою реализацию регулярных выражений

Кто щупал? Что с производительностью? Если как у std::regex из сиплюсплюса, то точно не нужно! Если как у regex(3) из libc, то, может, и годно, если этим удобно пользоваться.

Так header-only или библиотеку Мезоном собирать?

Можно оба варианта, можно не собирать.

Кто щупал?

Она основана на https://swtch.com/~rsc/regexp.

https://github.com/stclib/STC/blob/master/docs/cregex_api.md

Limitations

The main goal of cregex is to be small and fast with limited but useful unicode support. In order to reach these goals, cregex currently does not support the following features (non-exhaustive list):

• In order to limit table sizes, most general UTF8 character classes are missing, like \p{L}, \p{S}, and most specific scripts like \p{Tibetan}. Some/all of these may be added in the future as an alternative source file with unicode tables to link with. Currently, only characters from from the Basic Multilingual Plane (BMP) are supported, which contains most commonly used characters (i.e. none of the «supplementary planes»).
• {n, m} syntax for repeating previous token min-max times.
• Non-capturing groups
• Lookaround and backreferences (cannot be implemented efficiently).

Что с производительностью? Если как у std::regex из сиплюсплюса, то точно не нужно!

SRELL 4.056 -- библиотека ECMAScript-совместимых регулярных выражений

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

перл-совместимые лучше

Конечно, но std::regex их тоже не поддерживает.

Да знаю я. Недавно ро работе сравнивал производительность. По сравнению с позиксными из libc все очень плохо. Если сторонняя реализация и лучше, то опять зависимости. Хотелось бы без них.

header-only

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

а как надо?))

Добавить нормальную поддержку библиотек, как это сделано в любом другом ЯП. Пора уже. Давно пора.

нормальную - это какую? Если у тебя тип известен только во время компиляции конечного софта, то библиотеку ты никак не сможешь предварительно откомпилировать. А значит header only, что в С, что в С++, что в любом другом языке.

нормальную - это какую?

Это которая вообще поддерживает такую сущность как «библиотека». В C и C++ такой сущности просто нет.

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

Кто тебе такую херню сказал?

А значит header only, что в С, что в С++, что в любом другом языке.

В других языках нет заголовочных файлов.

Кто тебе такую херню сказал?

ну вот тебе код на плюсах,

auto f(auto x) {
    return x;
}

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

В других языках нет заголовочных файлов.

а чем заголовочные файлы отличаются от незаголовочных? Ты вообще знаешь, что такое header-only библиотеки?))

Это которая вообще поддерживает такую сущность как «библиотека»

ой, извиняюсь. Ты вообще знаешь, что такое библиотеки?

давай показывай, во что ты его можешь откомпилировать.

ну окей, мы не можем это откомпилировать. Значит, этот код мы можем распространять только в исходниках. Все правильно? Ну и окей, и нафига нам заголовочные файлы для этого? Раст, например, отлично справляется без лишних сущностей.

Раст, например, отлично справляется без лишних сущностей.

бездарей-растоманов я не спрашивал. В твоем недоязыке в принципе нет аналога auto, кыш отсюда.

Либо то же самое с эквивалентным кодом на любом другом языке программирования.

Да пожалуйста:

id :: a -> a
id x = x

Код из стандартной библиотеки хачкелла, которая внезапно распространяется скомпилированной.

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

а чем заголовочные файлы отличаются от незаголовочных?

Тем что вставляются в файл как есть через директиву #include. Ваш К.О.

ой, извиняюсь. Ты вообще знаешь, что такое библиотеки?

Да. А ты – нет.

А давайте уже (или все еще) не будем делать из Си Джаву! Вон из С++ уже почти сделали, да так что пользоваться этим стало невозможно.

А давайте уже (или все еще) не будем делать из Си Джаву!

Каким образом поддержка модулей и нормальный тулинг для сборки сделает из Сей Жабу?

Вон из С++ уже почти сделали, да так что пользоваться этим стало невозможно.

У C++ и Java крайне мало общего кроме некоторых внешних признаков.

Предпочитаю mlib.

Здесь есть про производительность. https://github.com/P-p-H-d/mlib/wiki/performance

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

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

Тем что вставляются в файл как есть через директиву #include

$ cat main.c
int main(void) {}
$ cat t.c
#include "main.c"
$ gcc t.c

ты не К.О., а бездарь, не знающий о чем пишет

Бектрекинг не особо нужен-то в большинстве случаев. Если тебе регулярки всерьез нужны, то берешь pcre и имеешь счастье. А если ad hoc надо пользовательский ввод отвалидировать, то сложного не надо, из коробки возможностей выше крыши.

ты не К.О., а бездарь, не знающий о чем пишет

АХАХАХАХАХАХА ЗАТРОЛЛИРОВАЛ ВОТ ЭТО ДА ВОТ ЭТО ТЫ КРУТ

Ей богу, ты сам себя опроверг своим примером с auto выше и теперь будешь тут елозить.

Я не про контейнеры, я вот про это — https://stackoverflow.com/questions/70583395/why-is-stdregex-notoriously-much...

У Джявы есть прибитое гвоздями дерево классов и методов. Вот сейчас к С++ std::* пытаются гвоздями прибить. Пример: конструкция for (auto &it : container) работает только для контейнеров, удовлетворяющих критериям контейнера из std.

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

Скомпилируй и посмотри, что получился

Добавить нормальную поддержку библиотек

Вот заработают C++20 модули – эх, тогда заживём!

Пример: конструкция for (auto &it : container) работает только для контейнеров, удовлетворяющих критериям контейнера из std.

а что в этом плохого и где тут привязка к std? begin() и end() можно для любых типов сделать без привязки к std.

И ядро Линуха на плюсах перепишем! С модулями и RAII :)

Скомпилируй и посмотри, что получился

Я скомпилировал и посмотрел.

У хачкеля есть жирный чит, в нём параметр будет указателем, поэтому это компилируется в нормальный (для хачкеля) асм вообще без вопросов.

И ядро Линуха на плюсах перепишем!

На C3, там модули «из коробки».

begin() и end() можно для любых типов сделать без привязки к std.

Ключевое слово — _для_любых_типов_сделать_! Тип должен содержать именно это и еще оператор меньше, кажется. То есть, (вроде как) универсальная конструкция языка начинает работать с типами данных, на которые наложены архитектурные ограничения. То есть, она перестает быть универсальной. Ну так делайте тогда метод foreach в каждом контейнере, вопросов бы не было. А так, извините.

Привязка к std:: архитектурная. Я ж писал, контейнер должен соответствовать таковому из std::. А на операторе for консепты и констрейнты не прописаны, они там подразумеваемые. И это плохо.

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

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

Это буквально так.

Можно скомпилировать вариант для передачи указателя на функцию

Ичо? С точки зрения языка, это значение. Оно передаётся в функцию и возвращается из функции. Тот факт, что это компилируется в указатель, является просто деталью реализации.

Я тебе могу рассказать факт куда хуже: та функция (id x = x) на самом деле ещё и не возвращается. Хачкель компилируется в CPS, поэтому там функции завершаются jmp, а не ret. У сишников от чтения выхлопа GHC часто отрывает днище и они начинают что-то нечленораздельно лепетать в попытках осознать происходящее.

Именно поэтому скомпилированная функция не используется, если передать туда что-то кроме ф-ции?! Ты ведь понимаешь, что если все значения передавать по указателю, то проще юзать jit - быстрее будет работать

Именно поэтому скомпилированная функция не используется, если передать туда что-то кроме ф-ции?!

Что?

Ты ведь понимаешь, что если все значения передавать по указателю, то проще юзать jit - быстрее будет работать

Не понимаю. Хачкель уделывает языки с JIT по производительности.

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

По сравнению с позиксными из libc все очень плохо.

Мне больше Oniguruma нравится. И несколько диалектов регулярок, и во многих случаях уделывает PCRE2 с JIT.

поэтому там функции завершаются jmp, а не ret.

Ну шитый код как шитый код. Эти штуки мы еще в Форте видели... :)

Я выше кинул ссылку на сравнение реализаций регулярок. Чота Onigurum'ы там нет. Ну еще одна зависимость... :(

Хачкель уделывает языки с JIT по производительности.

Если с !, то может иногда и да. А так с поправкой на space gap... :(

Чота Onigurum’ы там нет.

Есть, onig. Я им, кстати, чинил CMake, надо будет SRELL туда добавить. :)

Посоны, тут гуманитарий первокурсник спрашивает. А как поставляются С++ и Rust скомпилированные библиотеки с дженериками? Или они так не умеют и никак не поставляются?
С Явой то все понятно, там типы стерли и компилятор дальше следит, чтобы левое не подсунули. С++ же компилит шаблон отдельно для каждого конкретного типа. Соответственно, у библиотеки нет шанса наперед узнать о всех возможных типах.

Да и без ! обычно уделывает. Всё норм, всё проверено. С другой стороны, жабистам обычно вообще насрать на производительность, у них одна программа – один сервер.

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

Если у тебя в хидере есть функция, допустим, template <typename X, typename A> pow(X x, A a), то в библиотеке может быть две функции, реализующие возведение в степень для вещественных и комплексных чисел, например. Вот как-то так.

А как поставляются С++ <…> скомпилированные библиотеки с дженериками?

Никак. Темплейты в C++ только в заголовочных файлах живут и инстанцируются по месту применения (т.е. создания экземпляра класса).

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

У Rust же в принципе только статическая линковка, поэтому там нет такого понятия как «скомпилированная библиотека».

если мне память не изменяет уже давно раст поддерживает динамическую линковку

https://doc.rust-lang.org/reference/linkage.html#r-link.dylib