Это header-only (~405 KB) C++20 библиотека в духе C++20 Ranges, Python IterTools, итераторов Rust и других, и предоставляет набор функций, в целом эквивалентный C++20 Ranges, но использует немного другую модель итерации, основанную на курсорах, а не итераторах.
Курсоры Flux - это обобщение индексов массивов, в то время как итераторы STL - обобщение указателей массивов.
Возможности:

• большой выбор алгоритмов и адаптеров последовательностей для создания мощных (?) и эффективных конвейеров данных;
• более высокая безопасность по сравнению со стандартными итераторами;
• более простое использование в распространённых случаях, особенно при определении собственных последовательностей и адаптеров;
• более эффективное выполнение некоторых распространённых операций;
• совместимость с существующими стандартными библиотечными типами и концептами.

Документация: https://tristanbrindle.com/flux/index.html
Код: https://github.com/tcbrindle/flux
Лицензия: Boost 1.0.
Пример:

constexpr auto result = flux::ints()                        // 0,1,2,3,...
                         .filter(flux::pred::even)          // 0,2,4,6,...
                         .map([](int i) { return i * 2; })  // 0,4,8,12,...
                         .take(3)                           // 0,4,8
                         .sum();                            // 12

static_assert(result == 12);

Он же в Compiler Explorer: https://flux.godbolt.org/z/KKcEbYnTx.

Проект от автора библиотеки NanoRange – C++20 Ranges для C++17.

StringZilla – SIMD- и SWAR-оптимизированная библиотека для C++ (с биндингами для языков C, JavaScript (модуль Node.js), Python, Rust и Swift) для быстрых строковых операций: поиск подстрок и набора символов (прямой и обратный), сортировка, расстояние Левенштейна, расстояние Хэмминга и других. Однако, функциональность не одинакова для всех языков.
Проект распространяется по лицензии Apache-2.0.

( читать дальше... )

>>> Подробности

Недавно на Github появился репозиторий операционной системы Gloire. Gloire использует ядро Ironclad, написанное на языке программирования Ada, и пользовательское окружение GNU. На сайте, посвященном Ironclad, написано что оно находится в процессе «формальной верификации».

( читать дальше... )

>>> Подробности

Вышел очередной релиз Thalassa CMS, сочетающей генератор статического HTML и CGI-программу для поддержки пользовательских комментариев. Thalassa CMS написана на C++ и, по заявлению автора, не имеет внешних зависимостей, не использует СУБД и не генерирует страниц со скриптами.

( читать дальше... )

>>> Подробности

24 января, после почти четырёхлетней паузы, состоялся выпуск 1.0.0 header-only SIMD-оптимизированной библиотеки для C++ GLM (OpenGL Mathematics), основанной на спецификациях GLSL (pdf) (OpenGL Shading Language).

( читать дальше... )

>>> Подробности

В названии, конечно, отсылка к фильму Spring, Summer, Fall, Winter… and Spring.

Обещал накатить вброс по Emacs, ибо как писали постом выше, народ заскучал. Речь идет о продолжении топика Жизнь после Emacs.

Вообще, суть моего мессенжа, пожалуй, точнее всего передает это короткое видео :).

Но если все же попытаться раскрыть суть чуть подробнее. Да, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки. Никакие элементы архаики, сохранившиеся в Emacs не могут преуменьшить те уникальные преимущества, которых больше нигде нет. Тут дело не в том, что в других редакторах/IDE они хуже или, скажем, они пока недоработанные. Их просто нет.

Итак, в продолжении темы предыдущей серии, я перешел на 1,5 года на VS Code.

Плюсы:

1. Производительность UI, который рендерится на GPU.
2. Производительность JavaScript (спасибо Electron/NodeJS/V8).
3. Вменяемый API.

Минусы:

1. Не keyboard-centric. Некоторые вещи вообще без мыши не сделать, что раздражает.
2. Хотите переименовать текущий файл? Вам нужен плагин для этого! В Emacs это была бы просто небольшая функция - кинул в конфиг и всего делов. Тут же 8 плагинов, половина из них заброшена в 2015-м, другая половина помимо необходимой функции добавляет еще 100500 других. Доков нет, докстрингов нет, что кто-то другой будет открывать код плагина и в мыслях не было. Спасибо, если есть ридми, пусть и не обновляемая много лет, и уже не релевантная коду.
3. Культура разработки. Вне официального кода от Microsoft ее нет (см. выше). Писать плагины на ClojureScript возможно, но не вполне натурально (как проба пера, например advanced-navigation-cljs). Да, есть еще joyride. API неплох, да, но многие вещи гвоздями прибиты и всего не настроишь.

Наверное, основной вопрос в плане конфигурации VS Code по сравнению с Emacs в том, что для Emacs можно было не особо переключаясь из контекста текущей деятельности быстренько перейти в .emacs, что-то там подправить и вернуться к основной задаче. В VS Code флоу совсем иной. Если ты вдруг понял, что тебе нужно что-то доконфигурировать, ты понимаешь, что либо на это нужно просто забить, либо мысленно сказать что-то вроде, «ну что ж, а теперь девочки и мальчики мы все бросаем и осваиваем/вспоминаем специальность «конфигуратор/плагинописатель» для VS Code», ибо быстренько что-то подхачить там не выйдет. Например, тебе дополнительно нужен инстанс среды для тестирования изменений плагина. Плагин дописывается, отлаживается и потом устанавливается в рабочую среду. Если же, ко всему прочему, это не твой плагин (что почти всегда), то нужно понимать, что вникать придется долго, ибо комментариев и докстрингов нет примерно никогда (за исключением собственно описания API от Microsoft).

При этом, всегда надеяться на то, что все будет «просто работать» нельзя. У меня например, после очередного обновления как-то отваливалась Calva (Clojure IDE) и edamagit (Magit for VSCode). Опять же, в Emacs у меня тоже были случаи, когда достаточно мейнстримовые плагины приходили с ошибками после очередного обновления. И в этой ситуации всегда можно быстренько это на лету починить, зарепортить багу или сразу прислать пулрек мейнтейнеру.

По итогу, решил попробовать NeoVim, ибо тоже в теории гибкая расширяемая среда, да и вообще, интересно и полезно из бочки вылезти, посмотреть, что в мире вимеров происходит.

Плюсы:

1. Производительность UI, для чего делаются отдельно UI клиенты. Я по итогу выбрал neovim-qt
2. Производительность Lua. Чуть хуже, чем JavaScript, но сильно лучше EmacsLisp. Впрочем, про производительность UI на относительно больших файлах будет ниже оговорка.
3. Fennel - Lisp, работающий на Lua прекрасен. Это дает в чем-то схожий флоу конфигурации, что и в Emacs, когда поведение меняется на лету (см. подробнее: conjure)
4. Сопоставимая с Emacs экосистема. Например, Magit (для Emacs), Edamagit (для VSCode) и NeoGit (для NeoVim) работают почти одинаково.

Минусы:

1. Модальность. Для кого-то это плюс, я ее не люблю. Я настраивал конфигурацию без модальности. Но тут периодически натыкаешься на ограничение возможностей Vim по тонкой настройке.
2. Менее удобная работа с Fennel, чем то, что предоставляет Emacs для EmacsLisp. На самом деле, они, конечно, не сопоставимы. Т.е. NeoVim не может быть такой же удобной IDE для Fennel как Emacs для EmacsLisp, уже по причине невозможности такой же интроспекции.
3. Довольно причудливый API, многие вещи прибиты гвоздями еще со времен царя-гороха. Например, для некоторой функциональности нет полноценных функций, которые можно было бы вызвать через API, есть только хоткеи, т.е. приходится эмулировать их нажатие для вызова этих функций. Ситуация прежде всего в NeoVim постепенно меняется к лучшему, но до API Emacs пропасть неизмеримых размеров.

Но вот то, что реально заставило меня отказаться от пути использовать NeoVim и планомерно конфигурировать его в соответствии со своими предпочтениями, это то, что на больших файлах он стал повисать прям конкретно на десятки секунд. В Neovim Qt это очень сильно сказывалось. В Neovide лучше, но там нет антиалиасинга. А хотелось бы. В консольной версии аналогично. Отключил все плагины - ситуация не сильно поменялась. И максимальным шоком стало то, что Emacs с этим файлом спокойно работал. Подвисал, да, но на доли секунд.

Про Lapce и Helix, наверное, пока говорить рано, они довольно экспериментальные еще.

В общем, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки.

Эта статья является продолжением предыдущей публикации, в которой описывается разработка сетевой библиотеки на C++20. В данном продолжении акцент сделан на более детальном описании разработки алгоритма Raft и его интеграции с сетевой библиотекой.

( читать дальше... )

Представляю Вашему вниманию разработанную мной первую версию мультимедийной библиотеки Little DirectMedia Layer, сокращённо LDL.

Библиотека написана на С++ 98 стандарта, что позволяет компилировать ее начиная с Visual C++ 6.0. Код распространяется на условиях Boost Software License 1.0. Но библиотека не ограничивает программистов в выборе стандарта языка C++, программист может использовать любой современный стандарт языка. Я придерживаюсь философии downgrade — это использование старых устройств и софта в повседневной жизни, когда компании не поддерживают свои же «устаревшие» операционные системы или устройства, увеличивая с каждой новой версией своего продукта системные требования, или прекращают поддержку девайса. Миллиарды устройств по всему миру ежесекундно перемалывают миллиарды инструкций неоптимизированного кода.

В этом году я выступил на конференции С++ 2023 с докладом «Вперед в прошлое, или Разрабатываем фреймворк под Windows 95 в 2023 году».

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

В самом начале процесса разработки я и не предполагал, что данная библиотека вообще возможна. Но при практической реализации прототипа, добавляя строчку за строчкой в фундамент будущей библиотеки, убеждался в возможности ее создания и практическом применении.

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

Возможности библиотеки:

• поддержка Linux Debian 3 и выше (обеспечена нативная сборка);
• поддержка Windows 95 — Windows 11;
• простое API для работы с 2D графикой;
• загрузка множества графических форматов (bmp, png, tga, jpg);
• кроссплатформенное API над окнами и событиями ОС;
• для аппаратного ускорения графики используется OpenGL 1.2 и
• OpenGL 3.3, присутствует поддержка обработки графики только на ЦПУ, если отсутствует аппаратное ускорение;
• рендер может быть выбран динамически при загрузке приложения;
• единое API для всех систем — напиши один раз и компилируй везде!
• воспроизведение звука;
• динамическая и статическая линковка.

Планы на будущее:

• поточное воспроизведение звука;
• вывод текста с поддержкой библиотеки freetype;
• дополнительные рендеры Direct3D 9, 10, 11;
• API для работы с потоками;
• встроенная поддержка API для работы с сетью;
• портирование фреймворка на другие платформы: Android, IOS, MacOs.

Ссылки:

• Репозиторий проекта с описанием по сборке
• Примеры программ
• Презентация доклада
• Предыдущее обсуждение на ЛОРе

>>> Подробности

Прошивка для поддержки видеокарт NVIDIA включена в ветку 6.7 ядра Linux. Это решение позволит разработчикам nouveau в целом не волноваться с реклокингом для новых видеокарт (начиная с 20xx (NV160 family (Turing) серии видеокарт до последней 40xx ((Ada Lovelace))). По умолчанию эта фича будет включена только для видеокарт серии 40xx. Если же вы хотите попробовать её для других поколений устройств NVIDIA, необходимо в параметрах запуска ядра указать параметр nouveau.config=NvGspRm=1.

( читать дальше... )

>>> Оригинал

https://gitlab.kitware.com/cmake/cmake/-/issues/18355

5 лет и эта issue закрыта!

обсуждение и где я увидел эту новость:

https://www.reddit.com/r/cpp/comments/16y9qv2/cmake_c_modules_support_in_328/?share_id=zmiaFsJ_WEOoKPFD4IT-Q&utm_content=1&utm_medium=android_app&utm_name=androidcss&utm_source=share&utm_term=13

After 5 years its finally done. Next cmake 3.28 release will support cpp modules

C++ 20 named modules are now supported by Ninja Generators and Visual Studio Generators for VS 2022 and newer, in combination with the MSVC 14.34 toolset (provided with VS 17.4) and newer, LLVM/Clang 16.0 and newer, and GCC 14 (after the 2023-09-20 daily bump) and newer.

Создал с помощью mkfifo video.jpg. Моя программа, использующая OpenCV, сохраняет туда постоянно кадры обработанного видео с камеры с помощью imwrite(«video.jpg», frame). Запустил следующую команду (192.168.0.103 - адрес моего компьютера, на котором я хочу смотреть видео, а вообще вся эта штука крутится на одноплатнике):

tail -f video.jpg | ffmpeg -i pipe: -f mjpeg -r 15 -vcodec mjpeg udp://192.168.0.103:1234

Затем на своём компьютере запускаю:

ffplay -f mjpeg udp://192.168.0.255:1234

И смотрю видео. Всё хорошо, но не устраивает задержка (где-то полсекунды) и качество.

Насколько я понимаю, главная проблема в том, что ffmpeg зачем-то перекодирует кадры из JPEG в JPEG, чем портит качество и зря тратит ресурсы. Пробую добавить -vcodec copy, но тогда получаю кучу ошибок вида

[mjpeg @ 0x7f750fc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 11 >= 11

ЧЯДНТ? Хочу использовать JPEG, потому что ресурсов на одноплатнике мало и кодировать какой-нибудь MPEG ему будет тяжело, а вот с пропускной способностью сети особо проблем нет. Хочу использовать UDP или что-то подобное, чтобы кадры бились и терялись, но видео продолжало идти, даже если с качеством связи будет не всё в порядке, ибо минимальные задержки превыше сохранности кадров.

По традиции тихо и незаметно состоялся релиз Tribler 7.13 — BitTorrent-клиента с открытым исходным кодом, разрабатываемого Делфтским Техническим Университетом (Нидерланды).

( читать дальше... )

>>> Tribler 7.13

Постоянно писать «как делать правильный код» надоедает. Поэтому для разнообразия и развлечения написал мини-книгу «60 антипаттернов для С++ программиста». Этакие вредные советы в духе «Книга для непослушных детей и их родителей».

На самом деле там, не только вредные советы, но и разбор почему они собственно вредны. Будет полезно почитать новичкам в программировании. Думаю, каждый знает кого-то, кому будет полезно почитать этот материал :). Впрочем, опытные программисты тоже смогут найти интересное для себя и узнать/освежить знания про некоторых тонкие моменты C++.

Там много букв. Приглашаю запастись кофе/энергетиком и приступать. Буду рад обсуждениям и дополнениям, основанном на вашем опыте.

Ещё я этот текст переработал для бумажного издания. Оно в подготовке для печати. Смысл там в целом тот же, но пришлось многое переделать или расписать подробнее. Ведь нельзя в бумажной книге дать 100500 ссылок на сторонние ресурсы «читать здесь про xxx подробнее». Надеюсь, успеем напечатать к осенним конференциям и будем раздавать на стенде, например по кодовым словам. Приходите на стенд и говорите, что с linux.org.ru и что там на тему бумажной книги :)

Парочка вредных советов для примера:

• Пишите ваши .h-файлы так, чтобы они зависели от других заголовков, и при этом не включайте их в свой заголовочный файл. Пусть тот, кто инклудит, догадается, какие заголовки нужно заранее заинклудить перед использованием вашего файла. Развлеките коллег квестами!
• Пишите код так, как будто его будет читать председатель жюри IOCCC и он знает, где вы живёте (чтоб приехать и вручить вам приз).

P.S. PDF, если кому-то так удобнее.

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

Продолжаю раскрывать интересную тему запуска программ нестандартными способами. В этот раз расскажу про запуск ELF-бинарника из скрипта и без записи в файловую систему.

( читать дальше... )

Привет, ЛОР!

Нашёл забавную фишку про C++. Если вкратце, можно сделать, чтобы следующий кусок кода не вываливался с ошибкой при сборке.

int main () {
  constexpr int a = f ();
  constexpr int b = f ();

  static_assert (a != b, "fail");
}

Как это сделать? Об этом написано тут: https://b.atch.se/posts/non-constant-constant-expressions/

Если вкратце, то C++ стал настолько монструозен, что разные части стандарта могут прямо друг другу противоречить, и вместе эти фичи языка дают прямо таки неожиданные результаты. В итоге, можно сделать так, чтобы функция, помеченная как constexpr, на самом деле в каждом вызове выдавала рандомное значение в зависимости от фазы луны. Если очень хочется.

P.S. первый пример из ссылки GCC сейчас обрабатывает корректно и вываливает ошибку из static_assert. Но второй ещё работает в GCC 13. Для Ъ код ниже.

namespace detail {
  struct A {
    constexpr A () { }
    friend constexpr int adl_flag (A);
  };

  template<class Tag>
  struct writer {
    friend constexpr int adl_flag (Tag) {
      return 0;
    }
  };
}

template<class Tag, int = adl_flag (Tag {})>
constexpr bool is_flag_usable (int) {
  return true;
}

template<class Tag>
constexpr bool is_flag_usable (...) {
  return false;
}

template<bool B, class Tag = detail::A>
struct dependent_writer : detail::writer<Tag> { };

template<
  class Tag = detail::A,
  bool    B = is_flag_usable<Tag> (0),
  int       = sizeof (dependent_writer<B>)
>
constexpr int f () {
  return B;
}

int main () {
  constexpr int a = f ();
  constexpr int b = f ();

  static_assert (a != b, "fail");
}

22 мая, после более полутора лет разработки, состоялся выпуск 0.9.0 C++ библиотеки FINAL CUT, предназначенной для создания приложений с текстовым интерфейсом, не зависящей от библиотек ncurses, termbox или подобных, и распространяемой по лицензии LGPL-3.0.

( читать дальше... )

>>> Подробности

uni-algo - быстрая C++ (диалект C++17) header-only библиотека алгоритмов Unicode 15.0, лицензированная как MIT/Public Domain.

Изменения:

• добавлена поддержка scripts и script extensions (UAX #24);
• в реализацию сегментации текста добавлена поддержка курсора;
• оптимизировано конвертирование строк ASCII в UTF;
• в класс una::error добавлен una::error::code;
• версии в una::version преобразованы в классы;
• файл uni_algo/version.h больше не используется несколькими файлами;
• переименование UNI_ALGO_DISABLE_SHRINK_TO_FIT в UNI_ALGO_NO_SHRINK_TO_FIT;
• переименование UNI_ALGO_DISABLE_BREAK_GRAPHEME в UNI_ALGO_DISABLE_SEGMENT_GRAPHEME;
• переименование UNI_ALGO_DISABLE_BREAK_WORD в UNI_ALGO_DISABLE_SEGMENT_WORD;
• переименование функций поиска в find;
• переименование класса una::search в una::found.

>>> Подробности

rapidfuzz-cpp - быстрая, SIMD-оптимизированная библиотека на языке C++, реализующая несколько алгоритмов нечёткого сравнения строк и вычисления метрик:

• Левенштейна и Дамероу - Левенштейна;
• Хэмминга;
• Indel;
• Джаро и Джаро - Винклера;
• и некоторых других.

RapidFuzz - основанная на rapidfuzz-cpp библиотека для языка Python.

Лицензия: MIT.

( читать дальше... )

>>> Подробности

Приветствую, нуждаюсь в совете.

Надо файл перекинуть через пару NATов, свой лисапед на С/C++ я уже попробовал с какой то чужой либой, возвращающей мне параметры ната от чужого STUN сервера - вроде все не сложно, обмениваемся получаемыми параметрами от стуна через какой то сигнальный сервер (в моем случае MQTT), создаем маршрут в НАТе посылкой UDP пакета и погнали качать.

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

1. обеспечение корректности полученных данных
2. шифрование трафика

Последнее важно, но не так как первое.

Посоветуйте НЕБОЛЬШУЮ широко используемую либу под эти цели???