lokestrom/database

Purpose and Consumption

Database is a C++23 library of custom containers, string/storage primitives, algorithms, and file I/O utilities. It is consumed as a CMake subproject and linked through the Database target, defined by CMakeLists.txt. Public API is header-oriented under include/database; src/String.cpp is the visible compiled implementation unit.

Public API Boundary

Consumers include individual headers from include/database, rather than interacting with an application executable. The principal API surface is organized into:

• String and related storage: include/database/String.hpp, src/String.cpp

• Dynamic contiguous storage: include/database/Vector.hpp, include/database/TemplateFiles/Vector.tpp

• FIFO/concurrent queue facilities: include/database/Queue.hpp, include/database/TemplateFiles/Queue.tpp

• File reading/writing/editing: include/database/ReadFile.hpp, include/database/WriteFile.hpp, include/database/EditFile.hpp

Template declarations are separated from implementations in include/database/TemplateFiles, so template users must receive definitions through the public headers’ inclusion structure.

Core Data Structures

String supplies the library’s string-oriented abstraction and is the only component with a dedicated .cpp implementation (include/database/String.hpp, src/String.cpp). Vector provides generic dynamic storage and likely serves as a foundational container for higher-level types (include/database/Vector.hpp, include/database/TemplateFiles/Vector.tpp). Queue facilities include ordinary queue behavior and the documented SPSC atomic static queue family (include/database/Queue.hpp, include/database/TemplateFiles/Queue.tpp).

Generic algorithms are centralized separately from the containers in include/database/Algorythems.hpp and include/database/TemplateFiles/Algorythems.tpp.

File I/O Pipeline

The library exposes file access as distinct stages rather than a unified database engine:

1. Read data through include/database/ReadFile.hpp and its template implementation.

2. Write data through include/database/WriteFile.hpp.

3. Modify existing content through include/database/EditFile.hpp.

These APIs form the primary external-system boundary: they interact with the host filesystem, while containers and strings represent in-memory data. Their template implementations reside in include/database/TemplateFiles/ReadFile.tpp, include/database/TemplateFiles/WriteFile.tpp, and include/database/TemplateFiles/EditFile.tpp.

Error and Safety Model

Error behavior is a cross-cutting design boundary controlled by exception availability and CMake options. include/database/exceptionHandeling.hpp provides the error-handling layer; the README specifies selectable forced throwing or return-based behavior, with std::expected-style results possible. include/database/Unsafe.hpp marks a separate lower-safety interface boundary. Generic constraints and type traits are represented by include/database/concepts.hpp and include/database/traits.hpp, with implementation support in include/database/TemplateFiles/traits.tpp.

Build and Runtime Context

The project requires C++23 and CMake, with builds verified on Clang and MSVC. It is a native library with no indicated network, database-server, UI, or cloud-service runtime. Its material runtime dependencies are the C++ standard library and host filesystem access through the file utility APIs. Tests exercise key public families but are not the architectural entry point.

Dependency Shape

Higher-level file utilities and queues depend on common generic infrastructure—custom String/Vector, concepts, traits, algorithms, and error handling—rather than external frameworks. The repository’s main control flow is therefore caller-driven: a consuming program constructs library containers or invokes file operations; templates execute inline at compile time, while string functionality may link against the compiled Database library artifact.