Skip to content

Home

Jump to bottom
Timur Gafarov edited this page Jan 12, 2022 · 90 revisions

dlib

dlib is a collection of native D language libraries that implement common functionality (read below about our definition of "common"). It is useful for various higher-level projects - such as game engines, rendering pipelines and multimedia applications.

Currently dlib contains the following packages:

  • dlib.core - modules that are widely used by other packages
  • dlib.memory - allocators and memory management functions
  • dlib.container - containers and data structures
  • dlib.filesystem - abstract FS interface and its implementations for Windows and POSIX filesystems
  • dlib.math - linear algebra and numerical analysis (vectors, matrices, quaternions, etc.)
  • dlib.geometry - computational geometry (ray casting, primitives, intersection, etc.)
  • dlib.image - image processing (filters, color correction, FFT, HDRI, graphics formats I/O, support for 8 and 16-bit RGBA buffers and floating point operations)
  • dlib.audio - sound processing (synthesizers, audio formats I/O)
  • dlib.network - networking and web functionality
  • dlib.serialization - data serialization
  • dlib.coding - data coding and compression algorithms
  • dlib.text - text processing

Philosophy behind the project

Why dlib? Read the Rationale. There's also FAQ that explains dlib's design decisions.

Memory Management

dlib can be used both in garbage-collected and GC-free applications. Using its GC-based functionality is straightforward and D-ish, while following GC-free path requires writing more verbose code.

Note: For historical/compatibility reasons, dlib is neither betterC nor @nogc. We support GC-compatible and GC-free programming styles under one unified API, which consequently can't be constrained as @nogc.

Look Best Practices for more details on this topic.

Issue tracker

On GitHub issue tracker, we use several labels to mark bugs and improvements:

  • Breaking change. This is self-descriptive: an improvement that breaks backward compatibility;
  • Bug. A bug that should be fixed without API change;
  • Enhancement. A non-breaking improvement of existing functionality (e.g. optimization or a new feature);
  • Missing. Appears when existing functionality is removed due to regressions and needs to be rewritten, or when some implementation is not complete;
  • New functionality. Self-descriptive: a new functionality request.
Clone this wiki locally