dlib2

dlib 2.0 – это библиотека-наследник dlib 1.x. У нее будет более тщательно продуманная архитектура и больше низкоуровневых функций.

Предыстория

dlib 1.x исторически развивалась по своему уникальному пути, не учитывая экосистему языка. Сейчас в D-сообществе все более активно используются @nogc и betterC – новые проекты должны быть совместимы между собой и базироваться на одинаковых ограничениях и подходах.

Библиотека всегда стремилась к максимальной обратимой совместимости, в результате чего при добавлении новых функций накопилось множество компромиссов, а код стал слишком запутанным. Функции, зависящие от сборщика мусора, и независимые от него функции смешались в одну кучу. Кроме того, dlib 1.x требует от пользователя слишком глубокого понимания ее архитектурных особенностей. Есть части, которые работают “из коробки”, но некоторые операции зачастую неинтуитивны, либо требуют сложной подготовительной работы для правильного выполнения, что делает их неудобными (например, dlib.filesystem.stdfs или dlib.network).

Принципы

dlib 2.0 устранит большинство недостатков классической версии dlib, включая:

  • Несовместимость с @nogc и betterC;
  • Зависимость от Phobos. Базовая функциональность библиотеки будет вынесена в отдельный пакет, который можно будет скомпилировать полностью независимо от Phobos и druntime. Phobos будет использоваться только в высокоуровневых компонентах, где по-другому сделать невозможно;
  • Мешанину из GC-зависимого и GC-независимого кода. Будут созданы отдельные слои API для betterC, @nogc и функциональности, зависящей от сборщика мусора.

Поскольку классы требуют поддержки druntime и неявной функциональности, добавляемой компилятором, все ООП-компоненты также будут существовать в отдельном слое API. Библиотека будет состоять из нескольких уровней – от минимального (betterC) до зависящего от райнтайма.

Структура API

dlib 2.0 будет состоять из нескольких слоев API:

dcore – низкоуровневый процедурный API, совместимый с betterC и минимально заменяющий стандартную библиотеку. Будет поддерживать компиляцию под x86/x86_64 (в том числе bare metal), WebAssembly и, возможно, ARM. Слой полностью автономный – его можно будет собрать без зависимости от Phobos для создания компактных приложений в стиле C.

  • Управление динамической памятью (при наличии на платформе). Пользовательские колбэки malloc/free для кастомных низкоуровневых механизмов выделения памяти;
  • Стандартный ввод/вывод, конвейеры (если доступны на платформе);
  • Низкоуровневые функции для работы с файловой системой (если доступны на платформе);
  • Кроссплатформенная математическая библиотека;
  • Линейная алгебра;
  • Основные контейнеры: динамический массив, словарь, строка.

dlib2 – объектно-ориентированный @nogc уровень, который предоставляет более высокоуровневую функциональность. Будет служить унифицированным абстрактным интерфейсом для системных API (как минимум, Unix и Windows) – для тех возможностей, которые можно и нужно реализовать без сборщика мусора D. dlib2 будет основан на dcore и @nogc-частях Phobos.

  • Потоки ввода/вывода;
  • Вычислительные потоки;
  • Виртуальная файловая система;
  • Обработка изображений;
  • Обработка аудио;
  • JSON;
  • Сеть;
  • Фреймворк привязки к библиотекам C.

dlib – слой совместимости с классическим API dlib 1.x. Пользователи смогут просто импортировать привычные им модули dlib – сохраняется совместимость с проектами, использующими старые версии библиотеки.

dlib3 – экспериментальный слой. Здесь, например, могут быть встроенные привязки к различным популярным C-библиотекам, а также абстрактный мультимедиа-интерфейс, аналогичный SDL. Также можно создать аппаратно-ускоряемый 2D-холст для вывода графики и, в перспективе, сделать свой UI-тулкит на нем – таким образом, dlib позволит создавать приложения с пользовательским интерфейсом.

Математическая библиотека

dcore предоставляет собственный пакет математических функций – dcore.math. Его цель – реализация всех стандартных функций в платформонезависимом виде, если они недоступны на целевой платформе. При компиляции dcore.math выбирает оптимальную из всех доступных реализаций (std.math, libc math, LLVM-интринсики) – пользовательский код, таким образом, будет более эффективным.

Если для компиляции библиотеки используется LDC, то везде, где возможно, используются LLVM-интринсики. В противном случае предпочтение отдается функциям из std.math, если нет флагов FreeStanding или NoPhobos. В режиме NoPhobos используются функции рантайма C. В режиме FreeStanding (bare metal) используются встроенные платформонезависимые реализации.