Header-only TOML config file parser and serializer for C++17 (and later!).

banner
Releases C++17 C++20 TOML MIT license CircleCI Mentioned in Awesome C++

toml++ homepage

This README is fine, but the toml++ homepage is better.


Library features

  • Header-only
  • Supports the latest TOML release (v1.0.0), plus optional support for some unreleased TOML language features
  • C++17 (plus some C++20 features where available, e.g. experimental support for char8_t strings)
  • Proper UTF-8 handling (incl. BOM)
  • Works with or without exceptions
  • Doesn't require RTTI
  • First-class support for serializing to JSON
  • Tested on Clang (6+), GCC (7+) and MSVC (VS2019)
  • Tested on x64, x86 and ARM

Basic usage

The following example favours brevity. If you'd prefer full API documentation and lots of specific code snippets instead, visit the project homepage

Given a TOML file configuration.toml containing the following:

[library]
name = "toml++"
authors = ["Mark Gillard <[email protected]>"]

[dependencies]
cpp = 17

Reading it in C++ is easy with toml++:

#include <toml.hpp>
#include <fstream> //required for toml::parse_file()

auto config = toml::parse_file( "configuration.toml" );

// get key-value pairs
std::string_view library_name = config["library"]["name"].value_or(""sv);
std::string_view library_author = config["library"]["authors"][0].value_or(""sv);
int64_t depends_on_cpp_version = config["dependencies"]["cpp"].value_or(0);

// modify the data
config.insert_or_assign("alternatives", toml::array{
    "cpptoml",
    "toml11",
    "Boost.TOML"
});

// iterate & visit over the data
for (auto&& [k, v] : config)
{
    v.visit([](auto& node) noexcept
    {
        std::cout << node << "\n";
        if constexpr (toml::is_string<decltype(node)>)
            do_something_with_string_values(node);
    });
}

// re-serialize as TOML
std::cout << config << "\n";

// re-serialize as JSON
std::cout << toml::json_formatter{ config } << "\n";

You'll find some more code examples in the examples directory, and plenty more as part of the API documentation.


Adding toml++ to your project

toml++ comes in two flavours: Single-header and Regular. The API is the same for both.

🍦 Single-header flavour

  1. Drop toml.hpp wherever you like in your source tree
  2. There is no step two

🍨 Regular flavour

  1. Add tomlplusplus/include to your include paths
  2. #include <toml++/toml.h>

Conan

Add tomlplusplus/2.3.0 to your conanfile.
This adds the single-header version by default, but you can specify the regular version using "multiple_headers": True.

DDS

Add tomlpp to your package.json5, e.g.:

depends: [
    'tomlpp^2.3.0',
]

What is DDS?

Vcpkg

vcpkg install tomlplusplus

Other environments and package managers

toml++ is a fairly new project and I'm not up-to-speed with all of the available packaging and integration options in the modern C++ ecosystem. I'm also a cmake novice, for better or worse. If there's an integration option missing be assured that I fully support it being added, and welcome pull requests!


Configuration

A number of configurable options are exposed in the form of preprocessor #defines. Most likely you won't need to mess with these at all, but if you do, set them before including toml++.

Option Type Default Description
TOML_HEADER_ONLY boolean 1 Disable this to explicitly control where toml++'s implementation is compiled (e.g. as part of a library).
TOML_API define undefined API annotation to add to public symbols (e.g. __declspec(dllexport) on Windows).
TOML_ASSERT(expr) function macro assert(expr)
(or undefined)
Sets the assert function used by the library.
TOML_CONFIG_HEADER string literal undefined Includes the given header file before the rest of the library.
TOML_EXCEPTIONS boolean per your compiler's settings Sets whether the library uses exceptions.
TOML_IMPLEMENTATION define undefined Define this to enable compilation of the library's implementation. Meaningless if TOML_HEADER_ONLY is 1.
TOML_LARGE_FILES boolean 0 Uses 32-bit integers for line and column indices (instead of 16-bit).
TOML_OPTIONAL_TYPE type name undefined Overrides the optional<T> type used by the library if you need something better than std::optional.
TOML_PARSER boolean 1 Disable this to prevent inclusion of the parser-related parts of the library if you don't need them.
TOML_SMALL_FLOAT_TYPE type name undefined If your codebase has an additional 'small' float type (e.g. half-precision), this tells toml++ about it.
TOML_SMALL_INT_TYPE type name undefined If your codebase has an additional 'small' integer type (e.g. 24-bits), this tells toml++ about it.
TOML_UNRELEASED_FEATURES boolean 0 Enables support for unreleased TOML language features not yet part of a numbered version.
TOML_WINDOWS_COMPAT boolean 1 on Windows Enables support for transparent conversion between wide and narrow strings in some places when building for Windows.

A number of these have ABI implications; the library uses inline namespaces to prevent you from accidentally linking incompatible combinations together.


TOML Language Support

At any given time the library aims to support whatever the most recently-released version of TOML is, with opt-in support for a number of unreleased features from the TOML master and some sane cherry-picks from the TOML issues list where the discussion strongly indicates inclusion in a near-future release.

The library advertises the most recent numbered language version it fully supports via the preprocessor defines TOML_LANG_MAJOR, TOML_LANG_MINOR and TOML_LANG_PATCH.

🔸 Unreleased language features:

  • #516: Allow newlines and trailing commas in inline tables
  • #562: Allow hex floating-point values
  • #644: Support + in key names
  • #671: Local time of day format should support 09:30 as opposed to 09:30:00
  • #687: Relax bare key restrictions to allow additional unicode characters
  • #709: Include an \xHH escape code sequence

#define TOML_UNRELEASED_FEATURES 1 to enable these features (see Configuration).

🔹 TOML v1.0.0:

All features supported, including:

  • #356: Allow leading zeros in the exponent part of a float
  • #567: Control characters are not permitted in comments
  • #571: Allow raw tabs inside strings
  • #665: Make arrays heterogeneous
  • #766: Allow comments before commas in arrays

🔹 TOML v0.5.0:

All features supported.


Contributing

Contributions are very welcome! Either by reporting issues or submitting pull requests. If you wish to submit a pull request, please see CONTRIBUTING for all the details you need to get going.


License and Attribution

toml++ is licensed under the terms of the MIT license - see LICENSE.

UTF-8 decoding is performed using a state machine based on Bjoern Hoehrmann's 'Flexible and Economical UTF-8 Decoder'.

With thanks to:


Contact

For bug reports and feature requests please consider using the issues system here on GitHub. For anything else though you're welcome to reach out via other means. In order of likely response time:

Owner
Mark Gillard
Australian in Finland. I write code. Some of it is alright.
Mark Gillard
Comments
  • build(meson): Update path for .pc and .cmake files

    build(meson): Update path for .pc and .cmake files

    This changes install directories to more common ones: .pc --> share/pkgconfig to lib/pkgconfig and libdata/pkgconfig on FreeBSD hosts .cmake --> share/cmake to lib/cmake

  • Copying nodes

    Copying nodes

    Is your feature request related to a problem? Please describe. I am currently in the process of replacing a json library with your toml library, and I have encountered this issue a couple times, where I needed to make a copy of a node. In the first case, I was able to do a move. In other cases, I need a copy. Specifically, I have a table with one element that is an array. I want to be able to copy that array to a second element in that table.

    Existing table: [table] foo = [1, 2, 3]

    In pseudo-code: auto *array = table.get("foo"); table["bar"] = *array;

    Describe the solution you'd like I am pretty that I can accomplish this by manually iterating over the elements in the toml::node.

    Describe alternatives you've considered I was surprised to find that copy constructors were deleted.

    Additional context Are there, or will there be any plans to include node copying in the future?

  • Deserialization of arrays into std::vector and std::map

    Deserialization of arrays into std::vector and std::map

    A few ideas:

    Idea 1:

    Signature = [ 0x44, 0x4F, 0x53, 0x00 ]
    

    Deserialize into std::vector<uint8_t> or std::vector<uint16_t> or std::vector<uint32_t> or std::vector<uint64_t> or their signed counterparts?

    Idea 2:

    Signature = [ 'M', 'S', 'C', 'F' ]
    

    Deserialize into std::string or std::wstring or std::vector<char> or std::vector<wchar_t>? I understand this one might be a problem because there is no guarantee that each array index will correspond to a single character.

    Idea 3:

    DenominationTable = { 33 = 1000, 30 = 100, 32 = 500, 34 = 2000 }
    

    Deserialize into std::map<string, int> or std::map<wstring, int>?

    Please let me know what you think.

  • Failure to compile with intel compiler on linux

    Failure to compile with intel compiler on linux

    Environment

    toml++ version and/or commit hash:
    toml.hpp v2.3.0 [9be51e4]

    Compiler:
    icpc (ICC) 19.1.0.166 20191121 icpc (ICC) 19.0.0.117 20180804

    gcc backend: 7.4.0 (also tried 9.3.0)

    C++ standard mode (e.g. 17, 20, 'latest'):
    17

    Target arch (e.g. x64):
    x64 (linux)

    Library configuration overrides:
    None

    Relevant compilation flags:
    -std=c++17

    Describe the bug

    Compiling a simple test program with icpc fails, complaining about issues with TOML_ALWAYS_INLINE. The same example works fine when compiling with gcc (the same version used as the backend for icpc). Other versions of gcc on the backend similarly fail.

    In file included from test.cpp(3):
    % icpc test.cpp -std=c++17
    toml.hpp(1119): error #77: this declaration has no storage class or type specifier
      	TOML_ALWAYS_INLINE
    ... [[hundreds of lines of errors]]
    

    Steps to reproduce (or a small repro code sample)

    #include <iostream>
    #include <fstream> //required for parse_file()
    #include "toml.hpp"
    
    int main(int argc, char** argv)
    {
        toml::table tbl;
        try
        {
            tbl = toml::parse_file(argv[1]);
            std::cout << tbl << "\n";
        }
        catch (const toml::parse_error& err)
        {
            std::cerr << "Parsing failed:\n" << err << "\n";
            return 1;
        }
    
        return 0;
    }
    

    Additional information

    Forcing #define TOML_ALWAYS_INLINE __forceinline will compile with no errors, but fail to link.

    /tmp/icpcJYElhL.o: In function `toml::v2::default_formatter<char>::print(toml::v2::table const&)':
    test.cpp:(.text._ZN4toml2v217default_formatterIcE5printERKNS0_5tableE[_ZN4toml2v217default_formatterIcE5printERKNS0_5tableE]+0x50): undefined reference to `toml::v2::node::type() const'
    ... [[et al.]]
    
  • Is the

    Is the "multiple_headers" Conan option working?

    Environment

    toml++ version and/or commit hash:2.3.0

    Compiler:AppleClang 12

    C++ standard mode (e.g. 17, 20, 'latest'):17

    Target arch (e.g. x64):x64

    Library configuration overrides:

    Relevant compilation flags:

    Describe the bug

    I may about to be a waste of your time but I'm at a loss. I'm trying to get toml++ through Conan and I wanted to have to separate smaller headers rather than the amalgamated header. Because I'm using Conan, I used the multiple_headers options set to True but it seems I only ever got the single header file.

    I'm still a beginner with Conan so it's probably something stupid I'm doing incorrectly but I don't know what. I've tried a couple different things already, all leading to the same outcome. I've made sure to do conan remove tomlplusplus between every attempt to make sure I'm "starting fresh"...

    Steps to reproduce (or a small repro code sample)

    Because I'm also using CMake, I first tried to include toml++ like so:

    conan_cmake_run(REQUIRES
                        tomlplusplus/2.3.0
                    OPTIONS
                        tomlplusplus:multiple_headers=True
                    BUILD missing
                    BASIC_SETUP)
    

    but that didn't appear to work. I ended up with just the single file ~/.conan/data/tomlplusplus/2.3.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/toml.hpp. I also tried conan install . from the command line with both a conanfile.txt and a conanfile.py but neither had the desired effect.

    Here's the conanfile.txt I tried:

    [requires]
    tomlplusplus/2.3.0
    
    [options]
    tomlplusplus:multiple_headers=True
    

    and the conanfile.py I tried:

    from conans import ConanFile, CMake
    
    class TomlPlusPlusConan(ConanFile):
       settings = "os", "compiler", "build_type", "arch"
       requires = "tomlplusplus/2.3.0"
       generators = "cmake"
       default_options = {"tomlplusplus:multiple_headers": True}
    

    Additional information

    Regardless of the mechanism through which Conan is triggered, I always end up with a conaninfo.txt file that looks like this:

    [settings]
        arch=x86_64
        build_type=Release
        compiler=apple-clang
        compiler.libcxx=libc++
        compiler.version=10.0
        os=Macos
    
    [requires]
        tomlplusplus/2.Y.Z
    
    [options]
    
    [full_settings]
        arch=x86_64
        build_type=Release
        compiler=apple-clang
        compiler.libcxx=libc++
        compiler.version=10.0
        os=Macos
    
    [full_requires]
        tomlplusplus/2.3.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    
    [full_options]
        tomlplusplus:multiple_headers=True
    
    [recipe_hash]
    
    [env]
    

    and I always end up with a single file toml.hpp in the folder ~/.conan/data/tomlplusplus/2.3.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include.

    Again, it's probably something stupid on my part due to my inexperience with Conan but after a couple of hours fiddling with this, filing an issue is the best I could think of...

  • Add implicit conversion operators from node to node_view

    Add implicit conversion operators from node to node_view

    Hello! I've made a couple of changes to loosen restrictions on the use of node_view. Primarily, I added implicit conversion operators from node to node_view (const and mutable variants). Also, I re-enabled the move assignment operator on node_view.

    This was motivated by me running into trouble while trying to write code to traverse a table procedurally. Basically, I wanted to do something like this:

    toml::node_view<const toml::node> child = myTable;
    for (auto key : keyPath)
    {
        child = child[key];
    }
    

    where I'm descending into a table using a list of keys in keyPath.

    In opting to do this by adding implicit conversion operators (as opposed to e.g. adding a constructor on node_view, or explicit conversion functions), I was guided by std::string, which similarly has an implicit conversion to std::string_view. String views are always const, but here I wanted to allow either const or non-const node_views so I added both.

    I also found that statements like child = child[key] above want the move assignment operator, which was disabled. I didn't see any reason for that to be disabled, especially considering that copy assignment is enabled, so I turned it back on.

    I'm open to discussion on this if there are other ways you'd prefer to accomplish this, though. 🙂

    Pre-merge checklist

    • [x] I've read CONTRIBUTING.md
    • [ ] I've added new test cases to verify my change
    • [x] I've regenerated toml.hpp (how-to)
    • [ ] I've updated any affected documentation (didn't do this as I don't have Doxygen installed)
    • [ ] I've rebuilt and run the tests with at least one of:
      • [ ] Clang 6 or higher
      • [ ] GCC 7 or higher
      • [x] Visual Studio 2019
    • [x] I've forever enshrined myself in glory by adding myself to the list of contributors in README.md
  • C++20 MSVC Syntax Error [CMake]

    C++20 MSVC Syntax Error [CMake]

    Environment

    Compiler:
    MSVC

    C++ standard mode (e.g. 17, 20, 'latest'):
    C++20

    Target arch (e.g. x64):
    x64

    Exceptions enabled:
    I am using the default (/EHsc) Exceptions

    Relevant toml++ configuration customizations:
    No overrides are used

    Relevant compilation flags:
    None

    Describe the bug

    Syntax/Unknown-Type/Traits errors.

    toml.hpp(8103): error C2589: '(': illegal token on right side of '::'
    toml.hpp(8612): note: see reference to function template instantiation 'int64_t toml::impl::abi_impl_noex::parser::parse_integer<16>(void) noexcept' being compiled
    toml.hpp(8103): error C2062: type 'unknown-type' unexpected
    toml.hpp(8103): error C2144: syntax error: 'unknown-type' should be preceded by '('
    toml.hpp(8103): error C2059: syntax error: ')'
    toml.hpp(8104): error C2143: syntax error: missing ';' before '{'
    toml.hpp(8104): error C2059: syntax error: ','
    toml.hpp(8104): error C2059: syntax error: ')'
    toml.hpp(8104): error C2059: syntax error: 'return'
    toml.hpp(8104): error C2059: syntax error: '}'
    toml.hpp(8108): error C2059: syntax error: 'if'
    toml.hpp(8108): error C2653: 'traits': is not a class or namespace name
    toml.hpp(8110): error C2059: syntax error: 'else'
    toml.hpp(8112): error C2059: syntax error: '}'
    toml.hpp(8112): error C2143: syntax error: missing ';' before '}'
    

    Steps to reproduce (or a small repro code sample)

    Include it in any source file.

    Additional information

    Screenshots of the compiler error: image

  • tipi.build support for tomlplusplus

    tipi.build support for tomlplusplus

    Hello from tipi.build :D,

    I just added tipi support to your project and was wondering if you'd like to merge so everyone gets a new way of using your cool project.

    If there's any issue with this I'll be happy to sort it out

    Best from Zürich, Yannic / pysco68

    Pre-merge checklist

    • [x] I've read CONTRIBUTING.md
    • [x] I've rebased my changes against the current HEAD of origin/master (if necessary)
    • [x] I've added new test cases to verify my change (added a CI job which uses the tipi-ubuntu docker container)
    • [ ] ~~I've regenerated toml.hpp~~
    • [x] I've updated any affected documentation
    • [x] I've rebuilt and run the tests with at least one of:
      • [x] Clang 6 or higher
      • [ ] GCC 7 or higher
      • [x] MSVC 19.20 (Visual Studio 2019) or higher
    • [ ] ~~I've added my name to the list of contributors in README.md~~
  • Update value at path

    Update value at path

    Is your feature request related to a problem? Please describe. It would be very useful to be able to insert or modify a value at a particular path, essentially the inverse of the at_path(...).value_or(...) method chain.

    Describe the solution you'd like Something like tbl.at_path(...).insert_or_update(...). At the moment it seems like I would need to parse the path string myself to find the correct parent table to then call insert_or_assign, which is unfortunate since the path-parsing code already exists in the library. Or is there a canonical way of doing this already that I'm missing?

  • Improve `node` and `node_view` interfaces

    Improve `node` and `node_view` interfaces

    Is your feature request related to a problem? Please describe. The node_view could be made more similar to a std::optional to enhance usability. Also, there's no clean way to extract a generic "number" which can be floating or integer: currently I have to do

    if (node.is_floating_point()) {
        return node.as_floating_point()->get();
    }
    else if (node.is_integer()) {
        return node.as_integer()->get();
    }
    else {
        ....
    }
    

    I know that there's a .is_number() member function, It would be great to have a way to directly extract the number, for example:

    if (node.is_number()) {
        return node.get_number();
    } else {
        ....
    } 
    

    In general, it would be great to have a shorter way to get values from a node

    Describe the solution you'd like I think it would be useful to:

    • make node_view more like optional: it currently has a .value_or() member function, but not a throwing .value(), nor a .has_value(), for example.
    • equip node with a member function which return the number it contains, whether it is an integer or a floating point
    • equip node with a member function which returns the value directly or inside an (eventually empty) optional or node_view (which in my opinion are more expressive than a pointer)

    Describe alternatives you've considered For the second issue, an alternative could be make .as_floating_point()->get() implicitly convert the underlying integer, making the following code work:

    if (node.is_number()) {
        return node.as_floating_point()->get();
    }
    
  • Array of tables output

    Array of tables output

    If I have this input:

    [[Winter]]
    December = [
       { Sunday = 6 },
       { Monday = 7 }
    ]
    January = [
       { Sunday = 6 },
       { Monday = 7 }
    ]
    [[Spring]]
    March = [
       { Sunday = 6 },
       { Monday = 7 }
    ]
    April = [
       { Sunday = 6 },
       { Monday = 7 }
    ]
    

    with this program:

    #include <fstream>
    #include <iostream>
    #include <toml.hpp>
    
    int main() {
       auto config = toml::parse_file( "configuration.toml" );
       std::cout << config << std::endl;
       return 0;
    }
    

    I get this result:

    [[Spring]]
    April = [ { Sunday = 6 }, { Monday = 7 } ]
    March = [ { Sunday = 6 }, { Monday = 7 } ]
    
    [[Winter]]
    December = [ { Sunday = 6 }, { Monday = 7 } ]
    January = [ { Sunday = 6 }, { Monday = 7 } ]
    

    is it possible to get something closer to the input?

  • Fail to build when imported from a module unit purview

    Fail to build when imported from a module unit purview

    — This problem is reported here more as a backlog than as a real problem. It shouldn't really concern people who don't use state-of-the-art compilers with C++ modules. Nevertheless, @marzer asked me to flag it as a problem to look into at some point.


    Commit: c6deadf61db048feda3998041af8021244368671

    Compiler:
    Microsoft Visual C++ 14.32.31326 / May 10, 2022

    C++ standard mode:
    23

    Target arch:
    x64

    tomlplusplus will flag C2872 should we try to use it when it is imported from a module unit purview:

    import <sstream>;
    import <iostream>;
    
    export module uniform; // purview begin...
    import "toml.hpp";     // import inside uniform's purview...
    
    using namespace std::string_view_literals;
    
    int main()
    {
      static constexpr std::string_view some_toml = R"(
        [library]
        name = "toml++"
        authors = ["Mark Gillard <[email protected]>"]
        cpp = 17
      )"sv;
    
      try
      {
        // parse directly from a string view:
        {
          toml::table tbl = toml::parse(some_toml);
          std::cout << tbl << "\n";
        }
    
        // parse from a string stream:
        {
          std::stringstream ss{ std::string{ some_toml } };
          toml::table tbl = toml::parse(ss); // Error! C2872!
          std::cout << tbl << "\n";
        }
      }
      catch (const toml::parse_error& err)
      {
        std::cerr << "Parsing failed:\n" << err << "\n";
        return 1;
      }
    
      return 0;
    }
    
    > Error C2079 'toml::v3::impl::impl_ex::parser::root' uses undefined class 'toml::v3::table'
    
  • Event interface / SAX

    Event interface / SAX

    Is your feature request related to a problem? Please describe. I'd like to consume the input file on the go, without having to create an intermediate DOM representation.

    Describe the solution you'd like A SAX-like parser interface.

    Additional context This would make it easier to use in some memory constrained situations.

  • iterator proxy pair ought to decay to value semantics on demand

    iterator proxy pair ought to decay to value semantics on demand

    Lots of generic STL code would always do:

    for(auto &i : container)
    

    This prevents the value copy of items being iterated. You have proxy pair in place to prevent this occurring for:

    for(auto i : container)
    

    Firstly, any compiler which is not MSVC will elide that copy under optimisation if i never escapes or is modified. So your proxy optimisation probably doesn't actually save much, except on MSVC.

    Meanwhile, the lack of value sematics for the second for loop causes much generic code to break. If the code asked for a copy, it expects an as-if copy. If you wish to retain your proxy, you ought to have it implicitly convert to a value type upon demand in order to retain expected semantics.

  • Preservation of comments and whitespace

    Preservation of comments and whitespace

    Firstly, this is one of those very few libraries I've used where I don't think I'd have done much different myself. Well, possibly I'd have made it always non-throwing. Well done on that, and thank you for making it open source.

    Another thing that I would have done is optional comment and whitespace preservation, such that if you read in a TOML file, and then write it out, comments and whitespace are preserved. This is useful because I'm using your library a bit like how clang-tidy or doxygen do things, where you can dump out a default TOML config, hand edit it, or supply TOML delta files to merge against the default TOML config, and so on. Therefore, dumping out the post-merge TOML file, with all comments also merged, would be ideal.

    For this to work right, you'd need to retain comments and whitespace as an attribute of the first node following the comment. Then, if the node gets replaced by a merge, one could retain the existing comment and whitespace, or replace it with the new comment and whitespace etc.

    I'd personally make this opt-in, as plenty of people don't want to waste CPU nor memory on comments and whitespace. My thanks in advance to you for your consideration!

Simple .INI file parser in C, good for embedded systems

inih (INI Not Invented Here) inih (INI Not Invented Here) is a simple .INI file parser written in C. It's only a couple of pages of code, and it was d

Oct 3, 2022
ini file parser

Iniparser 4 I - Overview This modules offers parsing of ini files from the C level. See a complete documentation in HTML format, from this directory o

Sep 25, 2022
Small configuration file parser library for C.

libConfuse Introduction Documentation Examples Build & Install Origin & References Introduction libConfuse is a configuration file parser library writ

Sep 20, 2022
This is a header only C++ version of inih.

inih This is a header only C++ version of inih. inih (INI Not Invented Here) is a simple .INI file parser written in C. It's only a couple of pages of

Sep 23, 2022
C++20 single-header library for embedding INI configs

ini-config A single-header library that converts INI-formatted string literals to a key-value pair list at compile-time. Requires C++20; tested on gcc

Jun 21, 2022
A fast and easy to configure alternative to neofetch written in C and configured using Lua
A fast and easy to configure alternative to neofetch written in C and configured using Lua

lcfetch A fast and easy to configure alternative to neofetch written in C and configured using Lua (still in a very early stage)! IMPORTANT: I'm a new

Jul 29, 2022
Cross-platform C++ library providing a simple API to read and write INI-style configuration files

simpleini A cross-platform library that provides a simple API to read and write INI-style configuration files. It supports data files in ASCII, MBCS a

Sep 24, 2022
Header-only TOML config file parser and serializer for C++17 (and later!).
Header-only TOML config file parser and serializer for C++17 (and later!).

toml++ homepage ✨ This README is fine, but the toml++ homepage is better. ✨ Library features Header-only Supports the latest TOML release (v1.0.0), pl

Sep 28, 2022
a header-file-only, JSON parser serializer in C++

PicoJSON - a C++ JSON parser / serializer Copyright © 2009-2010 Cybozu Labs, Inc. Copyright © 2011-2015 Kazuho Oku Licensed under 2-clause BSD license

Sep 27, 2022
Config and tools for config of tasmota devices from mysql database

tasmota-sql Tools for management of tasmota devices based on mysql. The tasconfig command can load config from tasmota and store in sql, or load from

Jan 8, 2022
A header only C++11 library for parsing TOML

tinytoml A header only C++11 library for parsing TOML. This parser is based on TOML v0.4.0. This library is distributed under simplified BSD License.

Jun 8, 2022
cpptoml is a header-only library for parsing TOML

cpptoml A header-only library for parsing TOML configuration files. Targets: TOML v0.5.0 as of August 2018. This includes support for the new DateTime

Sep 29, 2022
A generator of JSON parser & serializer C++ code from structure header files

JSON-CPP-gen This is a program that parses C++ structures from a header file and automatically generates C++ code capable of serializing said structur

Aug 20, 2022
BLLIP reranking parser (also known as Charniak-Johnson parser, Charniak parser, Brown reranking parser) See http://pypi.python.org/pypi/bllipparser/ for Python module.

BLLIP Reranking Parser Copyright Mark Johnson, Eugene Charniak, 24th November 2005 --- August 2006 We request acknowledgement in any publications that

Aug 15, 2022
BLLIP reranking parser (also known as Charniak-Johnson parser, Charniak parser, Brown reranking parser)
BLLIP reranking parser (also known as Charniak-Johnson parser, Charniak parser, Brown reranking parser)

BLLIP reranking parser (also known as Charniak-Johnson parser, Charniak parser, Brown reranking parser)

Aug 15, 2022
ring-span lite - A C++yy-like ring_span type for C++98, C++11 and later in a single-file header-only library

ring-span lite: A circular buffer view for C++98 and later Contents Example usage In a nutshell Dependencies Installation Synopsis Reported to work wi

Aug 23, 2022
C++20's jthread for C++11 and later in a single-file header-only library
C++20's jthread for C++11 and later in a single-file header-only library

jthread lite: C++20's jthread for C++11 and later A work in its infancy. Suggested by Peter Featherstone. Contents Example usage In a nutshell License

Aug 24, 2022
expected lite - Expected objects in C++11 and later in a single-file header-only library

expected lite: expected objects for C++11 and later expected lite is a single-file header-only library for objects that either represent a valid value

Sep 28, 2022
gsl-lite – A single-file header-only version of ISO C++ Guidelines Support Library (GSL) for C++98, C++11, and later

gsl-lite: Guidelines Support Library for C++98, C++11 up metadata build packages try online gsl-lite is an implementation of the C++ Core Guidelines S

Sep 20, 2022
optional lite - A C++17-like optional, a nullable object for C++98, C++11 and later in a single-file header-only library

optional lite: A single-file header-only version of a C++17-like optional, a nullable object for C++98, C++11 and later Contents Example usage In a nu

Aug 10, 2022