Rationale

dlib is:

• a collection of general-purpose libraries that implement well-known standards and commonly used functionality;
• a set of tools for writing multimedia applications. It can be used (and is known to be used) as a math library and texture loader for game engines, or a prototyping platform for Computer Science research;
• a set of tools for writing GC-free applications. If the garbage collector is what stops you from using D, you may consider using dlib and follow its best practices. You'll be surprised how compact and clean GC-free code can be.

dlib is NOT:

• a complete application development framework. It doesn't include GUI, window management, input handling, etc, because there are enough popular libraries for that;
• a second standard library. We try to keep Phobos dependency low due to our memory management policy, but turning dlib into a betterC library or some sort of Phobos replacement is not our goal;
• a game/graphics engine. Instead, it provides core functionality for building one;
• an experimenting ground. We don't invent new ideas, we only make efficient implementations.

Our general principle is the following: if some concept is well-defined and has time-proven way of implementation, then this concept is considered "common" and may be included to dlib. If, on the contrary, something has no "right way" of doing it, then it considered "not common". In this case everyone should be free to experiment and make their own decisions - dlib will stay away from that.

We also adhere the following ideas:

• Our "Holy Trinity" are Performance, Portability and Usage Simplicity. They are more important than anything else;
• No dependencies, third-party libraries, bindings, wrappers, whatsoever. No one likes dependencies. We keep dlib self-sufficient to make usage, shipping and maintenance easier. dlib only depends on Phobos and system APIs like POSIX and WinAPI;
• Internal dependency between modules is minimal. If you don't need something (for example, dlib.image, dlib.serialization or dlib.network), you can throw it out;
• dlib's interfaces are platform-independent, while implementations may be not. The general principle is to allow user to write fully cross-platform code, while maintaining all the platform-dependent stuff at the backend;

dlib avoids dynamic memory allocation where possible. Where not possible, it tries to rely on user for that. dlib doesn't make resource availability checks before allocating a resource. For example, it doesn't check available memory before heap allocation, doesn't check file permissions before accessing it, and doesn't check port availability before binding it to a socket. Such checks are considered user's responsibility.

dlib is primarily a collection of libraries for different tasks. Some of them depend on others, some are autonomous. So you wonder, what's the point of putting together several libraries with completely different fields of application? Why violate KISS principle? Here're some considerations.

• dlib is somewhat biased towards computer graphics domain and tends to provide a comprehensive feature set in that field. For example, 2D/3D game engines and scientific simulation usually rely on three fundamental components: vector/matrix algebra, computational geometry and color/image processing. These include such common functionality as performance-optimized matrix inversion, geometric shape intersection tests, image file formats decoding, etc. Geometry obviously depends on vector math, and usually so does image processing (consider color-vector interoperability, FFT, convolution matrices and so on). Breaking these up to separate projects would cause nothing but a mere unjustified dependency mess. Though dlib itself is clearly not a game engine or scientific platform, it is supposed to serve as a backend for building one. You can think of it as a "batteries" for OpenGL, for instance. OpenGL by itself doesn't provide matrix math or texture loaders, and dlib fits this niche nicely.

• dlib follows the idea of generalization. Specialized image loading libraries usually are file-based, and dlib's I/O capabilities are all stream-based. This yields necessity to include stream library and filesystem abstraction as a core part of the project. The same is true for memory management: major part of dlib utilizes dynamic memory allocation, and relying on GC for that is not the best idea for performance-critical tasks, so we decided to abstract memory allocations as much as possible.

• dlib is not a single general purpose library of its kind: there is a project with the same name in C++ world, that includes numerical algorithms, image processing, data compression, threading, networking, XML, GUI and much more.