GCC 11.1.0 build errors

[Valmar33]

https://invent.kde.org/-/snippets/1655

Errors of interest are:

/tmp/makepkg/decaf-emu-git/src/decaf-emu/libraries/cpptoml/include/cpptoml.h:1033:52: error: ‘numeric_limits’ is not a member of ‘std’
 1033 |         if (static_cast<uint64_t>(v->get()) > std::numeric_limits<T>::max())
      |                                                    ^~~~~~~~~~~~~~
/tmp/makepkg/decaf-emu-git/src/decaf-emu/libraries/cpptoml/include/cpptoml.h:1033:68: error: expected primary-expression before ‘>’ token
 1033 |         if (static_cast<uint64_t>(v->get()) > std::numeric_limits<T>::max())
      |                                                                    ^
/tmp/makepkg/decaf-emu-git/src/decaf-emu/libraries/cpptoml/include/cpptoml.h:1033:71: error: ‘::max’ has not been declared; did you mean ‘std::max’?
 1033 |         if (static_cast<uint64_t>(v->get()) > std::numeric_limits<T>::max())
      |                                                                       ^~~
      |                                                                       std::max

[richmattes]

Seeing the same on Fedora 34 on the v0.1.1 tag and on master. Reproduce with:

docker run --rm=true -it fedora:34 /bin/bash
# Inside docker image
dnf install -y gcc-c++ git cmake
git clone https://github.com/skystrife/cpptoml.git
cmake -B cpptoml-build -S cpptoml
cmake --build cpptoml-build

Adding #include <limits> too include/cpptoml.h fixes the issue, as addressed in #123

[acarrillo]

Can confirm, GCC 9.4.0 against C++17. In my codebase I just include <limits> before including <cpptoml.h>

#include <limits>
#include <cpptoml.h>

[jwmelto]

It's a simple fix; just

#include <limits>

in cpptoml.h ... why is this still open?

[xparq]

why is this still open?

Check the commit history, that's your answer. :)

I'm checking out this fork, for instance: https://github.com/asdetrefle/toml, with lots of very useful improvements (incl. closing the API gap with the fantastic TOML++, which I'm trying to replace with something lighter), and an informative README clarifying how it differs etc.

[marzer]

@xparq

incl. closing the API gap with the fantastic TOML++, which I'm trying to replace with something lighter

Which elements of toml++ do you find to be too 'heavy'? I have gone to great lengths to keep #include and template instantiation burden as low as possible, and there's lots of switches to turn things off if you don't need them. Happy to hear more suggestions in that direction if you have some :)

[xparq]

[Update: some denoising + clarif.]

@marzer

Which elements of toml++ do you find to be too 'heavy'?

It's just my use case, I guess. The TOML spec itself is a bit too much. And the (combined) TOML++ header for my config loader (for which even e.g. a few hundred lines of a decent .ini reader could be a viable alternative) is 3x the size of my entire app currently. :)

BTW, I've disabled the formatters and the exceptions, and tried both header-only and compiled. Anything more I could try?
(Oh, but wait, just checked: the TOML++ compilation time isn't really an issue after all. I mean despite my relatively small app the build is so slow already that even removing TOML++ entirely doesn't make much of a difference...)

Having said, I do have some minor feature requests/suggestions (for another issues, if I get to it). IOW, TOML (or a faithfully conforming implementation, like yours) is not only a bit too much here, but it still doesn't even quite cover all my needs.

Anyway, TOML++ is a fantastic project, great job! 👍