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

[Rich Mattes]

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

[Alejandro (Alex) Carrillo]

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?

[Sz.]

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.

[Mark Gillard]

@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 :)

[Sz.]

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

It's my use case, I guess. The TOML spec itself is a bit too much. And the TOML++ include file for my config needs (compared to e.g. a few hundred lines for a decent .ini reader, which is already a viable alternative) is 3x the size of my entire app currently. :)

BTW, I've disabled the formatters and the exceptions, and tried both precompiled as a lib/obj, and now using it as a single header. Anything more I could try? Oh, but wait, compilation time is not really an issue any more: even with my small app, the C++ build is hopelessly slow anyway. TOML++, or minus (forgive the lame pun :) ), doesn't make much of a difference.

So, it's just architecture style/preference. I'm a frugalist, and hate to add stuff I don't utilize. (I build by hand, too, with BusyBox-w32's built-in make, just because it feels so good to never touch CMake. :) )

Having said all that, I do have some minor feature requests/suggestions (for another issue(s), if I get to it). (You see, TOML or TOML++ (I'll need to investigate which one) is not only a bit too much for me, but it doesn't even quite cover all my needs.)

Again, a fantastic project, great job! 👍