
TOML for Modern C++ - marzer
https://marzer.github.io/tomlplusplus/
======
usefulcat
What are the advantages of this library over, say
[https://github.com/ToruNiina/toml11](https://github.com/ToruNiina/toml11) ?

~~~
marzer
I actually tried using toml11 before writing toml++, and my main gripe with it
was the complexity. It does a _lot_, and I found it to be pretty unergonomic
to actually use.

That, and it's not as configurable (e.g. no support for exception-less).

------
rpasquay
I'm a bit surprised by this snippet from the "Traversing and manipulating
data" example:

    
    
      for (auto& elem : *arr) {
          // visitation helps deal with the polymorphic nature of TOML data
          elem.visit([=](auto&& el) noexcept
          {
              if constexpr (toml::is_number<decltype(el)>)
                  (*el)++;
              else if constexpr (toml::is_string<decltype(el)>)
                  el = "five"sv;
          });
      }
    

I thought constexpr would work at compile time but how can the compile here
inside a loop "know" when this labmda will encounter an int or a string ?

~~~
jdashg
It's tricky but I think visit is being passed a generic (templated) lambda,
which is statically instantiated for each type that a node might be. (Once for
int, once for string, etc) Since the type is static per template
instantiation, constexpr works here.

~~~
rpasquay
Thank you for the explanation!

------
TuxSH
Hm, it looks like it is using things like std::vector and streams, etc.

So it does actually require exceptions and RTTI/still forces linkage against
throwing functions, etc.

~~~
jdashg
In no-exception builds, exceptions become crashes. RTTI is barely used
anywhere in the STL.

As an example, Firefox uses STL without RTTI or exceptions.

------
pansa2
> C++17

> Works with or without exceptions

Is anyone using C++17 features with exceptions disabled? I thought the “no
exceptions” people were generally only using C++ as C-with-classes?

~~~
paulddraper
Yes, plenty, including Google.

If anything exceptions are declining in popularity, due to non-obvious and
non-local effects.

Exceptions are an uber-goto, _that can jump outside entire functions._ Some
people still like that, but very disciplined code bases (of which there are a
lot in C++) tend to avoid them.

At the very least, utility libraries like this one tend to err on the side of
most compatible: header only, no exceptions, user-chosen allocators, etc.

~~~
joshuamorton
> Exceptions are an uber-goto, that can jump outside entire functions. Some
> people still like that, but very disciplined code bases (of which there are
> a lot in C++) tend to avoid them.

I've never heard discipline as a reason to be exceptionless, its always been
performance related (specifically performance predictability).

~~~
paulddraper
Discipline can be mean strong performance too.

In any case, exceptions are really only a performance problem if there are
frequent. [1] Modern compilers and machines have near zero overhead for
unthrown exceptions and 20x the overhead of an if-else.

Chances are quite good that you have bigger performance problems than
exceptions.

[1] [https://stackoverflow.com/questions/13835817/are-
exceptions-...](https://stackoverflow.com/questions/13835817/are-exceptions-
in-c-really-slow)

~~~
joshuamorton
Like I said, performance predictability, not raw performance. if/else have
predictable performance characteristics, while exceptions are fast usually and
then occasionally very slow.

The idea being that in an area where you'd like performance to be predictable,
even in cases of unexpected results, Sum types or if/else give the same
performance all the time.

~~~
rumanator
> Like I said, performance predictability, not raw performance.

Your argument makes absolutely no sense. Exceptions are used to handle
exceptional events, the kind of stuff that would crash and shutdown your
program. Exceptions are used to establish sanity checkpoints where any
exceptional event can be caught and either recover from it or fail gracefully.
Performance is measured on the happy path, and exceptions fall in the exact
opposite of the happy path.

~~~
joshuamorton
There are cases where you want exceptional performance to _also_ have
predictable characteristics. I don't know why that doesn't make sense.

------
haolez
I don't get why C++ programmers like to keep the namespace prefixes around.
I'd just add lots of "using ..." statements and make my code more readable.
What's the chance of conflicts anyway when you are already dealing with a tiny
fraction of the code in the current file?

~~~
mikepurvis
Besides the header issue mentioned in the sibling, sometimes the context is
important too, for an example from Python, no one would `from os.path import
join`— you always use `os.path.join` in its entirety.

~~~
pfranz
:shrug: I've done that quite a bit. This randomly selected popular Python
library does it, too[1]. The example for `os.walk` literally has `from os.path
import join, getsize`[2]. The docs seem to back this up[3]:

"Remember, there is nothing wrong with using `from package import
specific_submodule!` In fact, this is the recommended notation unless the
importing module needs to use submodules with the same name from different
packages."

I haven't dealt with a lot of C++ code but I feel like I see a lot of `using
namespace ...` and haven't seen much `using ...;` (which I think is more
readable/acceptable)

[1]
[https://github.com/psf/requests/blob/df918c066fa275abc2bb0c9...](https://github.com/psf/requests/blob/df918c066fa275abc2bb0c960647dc064d136a01/requests/utils.py#L22)

[2]
[https://docs.python.org/3/library/os.html#os.walk](https://docs.python.org/3/library/os.html#os.walk)

[3] [https://docs.python.org/3/tutorial/modules.html#importing-
fr...](https://docs.python.org/3/tutorial/modules.html#importing-from-a-
package)

