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!

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 2, 2022
A general purpose data serializer.

GPDS is a General Purpose Data Serializer implemented as a very small C++ library. It allows to serialize C++ classes to and from XML files in a gener

Dec 8, 2021
libcluon is a small and efficient, single-file and header-only library written in modern C++ to power microservices.

libcluon Linux & OSX Build (TravisCI) Win64 Build (AppVeyor) Test Coverage Coverity Analysis CII Best Practices libcluon is a small single-file, heade

Aug 26, 2022
Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockford's base32. MIT licensed with consistent, flexible API.

cppcodec Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockf

Sep 20, 2022
Zmeya is a header-only C++11 binary serialization library designed for games and performance-critical applications

Zmeya Zmeya is a header-only C++11 binary serialization library designed for games and performance-critical applications. Zmeya is not even a serializ

Jul 4, 2022
Header-only library for automatic (de)serialization of C++ types to/from JSON.

fuser 1-file header-only library for automatic (de)serialization of C++ types to/from JSON. how it works The library has a predefined set of (de)seria

Jun 4, 2022
A YAML parser and emitter in C++

yaml-cpp yaml-cpp is a YAML parser and emitter in C++ matching the YAML 1.2 spec. To get a feel for how it can be used, see the Tutorial or How to Emi

Sep 17, 2022
Utility to convert any binary file into C source that can be compiled and linked to the executable.

bin2c Utility to convert any binary file into C source that can be compiled and linked to the executable. bin2o Utility to convert any binary file int

Jul 14, 2021
Use to copy a file from an NTFS partitioned volume by reading the raw volume and parsing the NTFS structures.

ntfsDump Use to copy a file from an NTFS partitioned volume by reading the raw volume and parsing the NTFS structures. Similar to https://github.com/P

Jul 17, 2022
BRAW decoder to allow unattended, headless, conversion of *.braw files into other file formats.

BRAW Decode This is a project that uses the official Blackmagic Raw SDK to decode a *.braw file in a way that can be read by FFmpeg. The goal of the p

Jul 19, 2022
A C++11 or library for parsing and serializing JSON to and from a DOM container in memory.
A C++11 or library for parsing and serializing JSON to and from a DOM container in memory.

Branch master develop Azure Docs Drone Matrix Fuzzing --- Appveyor codecov.io Boost.JSON Overview Boost.JSON is a portable C++ library which provides

Sep 14, 2022
Sep 22, 2022
Cap'n Proto serialization/RPC system - core tools and C++ library
Cap'n Proto serialization/RPC system - core tools and C++ library

Cap'n Proto is an insanely fast data interchange format and capability-based RPC system. Think JSON, except binary. Or think Protocol Buffers, except

Sep 17, 2022
Fast Binary Encoding is ultra fast and universal serialization solution for C++, C#, Go, Java, JavaScript, Kotlin, Python, Ruby, Swift

Fast Binary Encoding (FBE) Fast Binary Encoding allows to describe any domain models, business objects, complex data structures, client/server request

Sep 14, 2022
MessagePack implementation for C and C++ / msgpack.org[C/C++]

msgpack for C/C++ It's like JSON but smaller and faster. Overview MessagePack is an efficient binary serialization format, which lets you exchange dat

Sep 21, 2022
FlatBuffers Compiler and Library in C for C

OS-X & Ubuntu: Windows: The JSON parser may change the interface for parsing union vectors in a future release which requires code generation to match

Sep 23, 2022
Experimental mutation testing tool for Swift and XCTest powered by mull
Experimental mutation testing tool for Swift and XCTest powered by mull

mull-xctest Experimental mutation testing tool for Swift and XCTest powered by mull. ⚠️ This tool is still experimental and under development. Install

Sep 5, 2022
A C++11 ASN.1 BER Encoding and Decoding Library

fast_ber A performant ASN.1 BER encoding and decoding library written in C++11 Introduction fast_ber is a small, lightweight library for BER encoding

May 22, 2022