How does config-loader compare to nlohmann/json for JSON parsing in C++?

config-loader offers multi-format support and compile-time reflection for type safety, while nlohmann/json is JSON-specific with richer JSON manipulation features. Choose config-loader for mixed-format projects, but nlohmann/json might be better for JSON-only use cases.

Can config-loader handle nested std::map structures?

Yes, it supports STL containers like std::map for key-value pairs, as mentioned in the features, but requires configuration files to use specific formats, such as attributes in XML for map keys.

What error handling does config-loader provide?

It returns Result enums like ERR_ILL_FORMED for malformed files or ERR_MISSING_FIELD for missing data, allowing basic error detection, but complex error recovery may require additional custom logic.

How to add custom data type support in config-loader?

The framework is extensible via the open/closed principle; you can define new schemas using DEFINE_SCHEMA for custom types, but extending to new file formats requires implementing new loader interfaces.

Is config-loader suitable for large configuration files?

Performance is generally good due to compile-time optimizations, but memory usage depends on the underlying parsing libraries; for very large files, the dependencies might introduce overhead.

How to integrate config-loader into a CMake project?

Clone the repository with submodules and follow the build instructions in the README, but managing dependencies like jsoncpp may require careful CMake configuration to avoid conflicts.

Does config-loader preserve comments when serializing back to files?

The README doesn't specify comment preservation; it focuses on data structure serialization, so comments and formatting are likely lost during the stringify process.

Open-Awesome

config-loader

NOASSERTIONC++v1.0

A C++17 static reflection framework for parsing configuration files (XML, JSON, YAML) into native data structures.

GitHub

249 stars40 forks0 contributors

What is config-loader?

config-loader is a C++17 static reflection framework that automatically parses configuration files (XML, JSON, YAML) into native C++ data structures. It solves the problem of writing repetitive, error-prone parsing code by using meta-programming to generate serialization interfaces from schema definitions.

Target Audience

C++ developers building applications that require flexible, type-safe configuration management, such as game engines, server software, or tools with complex settings.

Value Proposition

Developers choose config-loader for its simplicity, lightweight design, and support for multiple configuration formats without boilerplate. Its compile-time reflection ensures type safety and performance, while the extensible architecture allows easy integration into existing projects.

Overview

Simple C++ Config Loader Framework(Serialization & Reflection)

Use Cases

Best For

Loading game or application settings from XML/JSON/YAML files
Reducing boilerplate code for configuration parsing in C++ projects
Managing nested or complex configuration data structures
Ensuring type safety when reading external configuration files
Prototyping applications that require quick configuration iteration
Integrating multiple configuration formats in a single codebase

Not Ideal For

Projects constrained to C++11 or C++14 standards due to its C++17 requirement
Applications needing configuration from unsupported formats like INI or TOML
Teams prioritizing minimal dependencies or binary size over convenience, as it relies on external parsing libraries
Systems requiring dynamic schema modifications at runtime without recompilation

Pros & Cons

Pros

Compile-Time Type Safety

Uses C++17 static reflection with the DEFINE_SCHEMA macro to automatically generate parsing code, ensuring configurations map correctly to data structures without runtime type errors.

Multi-Format Flexibility

Supports XML, JSON, and YAML through dedicated load interfaces like loadXML2Obj and loadJSON2Obj, allowing developers to switch formats without rewriting parsing logic.

Minimal Boilerplate Code

Eliminates repetitive parsing code by defining schemas once; the framework handles serialization, reducing manual effort and potential bugs.

Extensible Architecture

Follows the open/closed principle, enabling new data types to be added without modifying the core framework, as highlighted in the design philosophy.

Cons

External Library Dependencies

Relies on tinyxml2, jsoncpp, and yamlcpp, which can increase project complexity and binary size, though future CMake options may allow selective inclusion.

Rigid File Format Requirements

Configuration files must adhere to standardized formats, such as specific tag names in XML, which may not align with all existing or custom configuration structures.

Limited Runtime Flexibility

Schema definitions are fixed at compile time using macros, preventing dynamic adjustments to configuration structures without recompilation.

Frequently Asked Questions

Related Projects

Magic Enum

Static reflection for enums (to string, from string, iteration) for modern C++, work with any enum type without any macro or boilerplate code

Stars6,138

Forks561

Last commit2 days ago

RTTR

C++ Reflection Library

Stars3,473

Forks486

Last commit2 years ago

Nameof

Nameof operator for modern C++, simply obtain the name of a variable, type, function, macro, and enum

Stars2,339

Forks127

Last commit8 days ago

reflect-cpp

A C++20 library for fast serialization, deserialization and validation using reflection. Supports JSON, Avro, Boost Serialization, BSON, Cap'n Proto, CBOR, Cereal, CSV, flexbuffers, msgpack, parquet, TOML, UBJSON, XML, YAML, yas / msgpack.org[C++20]

Stars1,897

Forks182

Last commit1 day ago

Community-curated · Updated weekly · 100% open source

Found a gem we're missing?

Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.

Submit a project Star on GitHub