TOML for Modern C++

https://marzer.github.io/tomlplusplus/

by marzer • 6 years ago

69 46 6 years ago

marzer.github.io

haolez2• 6 years ago

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?

rlp• 6 years ago

It's a header-only library, it would effectively add "using" statements anything that included the library.

haolez2• 6 years ago

Ouch. Seems like an unsolvable limitation at this point. Nice catch.

Reelin• 6 years ago

It's actually possible to avoid this!

  namespace foo::_bar {
      using namespace ::acme::widgets;
      /* internal helpers go here */
      inline namespace exports { /* public API goes here */ }
  }

  namespace foo::bar { using namespace _bar::exports; }

mikepurvis• 6 years ago

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.

tomjakubowski• 6 years ago

I agree with your point and I'm just nit picking, but `from os import path` and `path.join` is pretty acceptable too.

david2ndaccount• 6 years ago

I have definitely seen `from os.path import join` in some ugly ML github repos.

pfranz• 6 years ago

: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...

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

[3] https://docs.python.org/3/tutorial/modules.html#importing-fr...

eska• 6 years ago

You could do that in .cpp files, but it's objectively bad to do so in the header files due to namespace pollution. And now you have an inconsistency between headers and .cpp files..

LessDmesg2• 6 years ago

Why do header files even exist and why do sane languages work without them? Oh, I forgot, you cannot question The Holy Warts of Stroustrup. It's just C++. Leave all hopes of developer productivity at the door.

pansa23• 6 years ago

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?

cmrdporcupine• 6 years ago

All of Google's codebase, including Chromium, is OO C++ without exceptions.

https://google.github.io/styleguide/cppguide.html#Exceptions

userbinator• 6 years ago

In other words, that codebase is without exceptions, without exception.

pansa23• 6 years ago

Thanks - I’d seen that section before, but hadn’t noticed that elsewhere the document says “code should target C++17“.

Do you know if there are any parts of the C++17 language or standard library that are disallowed in Google’s code because those parts don’t work without exceptions?

jcelerier• 6 years ago

Let's insist on

On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

Also let's note that there are more new C++ projects being created today that at any previous point in time.

Propagating the -fno-exceptions meme is harmful to the whole community.

paulddraper4• 6 years ago

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.

pansa23• 6 years ago

Thanks. Do you know what the knock-on effects are of disabling exceptions in modern C++? Are there parts of the language or standard library that won’t work without exceptions?

joshuamorton3• 6 years ago

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).

rumanator2• 6 years ago

Yes, plenty, including Google.

Your statement is either disingenuous or entirely clueless.

The only rationale that Google presented to not use exceptions is that they use a lot of legacy code that was designed without exception handling, and thus it's problematic for then to integrate modern C++ code with old exception-free code. For Google, the only problem with exceptions is their own personal technical debt. That's it. It's in their FAQ.

Enough with this nonsense.

https://google.github.io/styleguide/cppguide.html#Exceptions

Exceptions are an uber-goto, that can jump outside entire functions.

That statement is far from being correct or an appropriate description. Exceptions are as much like goto statements as are return statements, and no one in their right mind would describe a return statement as an uber-goto statement.

Some people still like that, but very disciplined code bases (of which there are a lot in C++) tend to avoid them.

Again, that assertion makes no sense at all.

platinumrad• 6 years ago

I'm a "no exceptions, no exceptions" person. I mostly use C++ as C-with-templates, rather than C-with-classes, so C++17 is very useful to me.

jandrewrogers• 6 years ago

In my experience, few people use exceptions in systems-style code like database engines, while still using every feature of the latest versions of C++. You can essentially use all of C++17 without them if you wish, and many people do. Definitely not C-with-classes style code.

TuxSH2• 6 years ago

According to a recent talk from Herb Stutter (https://www.youtube.com/watch?v=ARYP83yNAWk), as many as 20% of users fully ban exceptions and an additional 30% ban them partially.

Even code doesn't actually reach the throwing paths, exceptions and RTTI induce a huge binary size overhead that is simply not acceptable if you have binary size constraints.

ameixaseca• 6 years ago

Low level programmers dislike exceptions because cost, high level (and some low level) programmers dislike exceptions because they make any reasoning about behaviour, resource leaking, etc impossible without looking at the full code, and even then the analysis is exponentially more difficult.

This all applies regardless of the C++ standard, of course.

usefulcat• 6 years ago

What are the advantages of this library over, say https://github.com/ToruNiina/toml11 ?

marzer3• 6 years ago

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).

rpasquay2• 6 years ago

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 ?

jdashg2• 6 years ago

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.

marzer3• 6 years ago

Yup, nailed it

rpasquay2• 6 years ago

Thank you for the explanation!

TuxSH2• 6 years ago

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.

marzer3• 6 years ago

Sure, if you want to be pedantic: it works without them when paired with standard implementations that can work without them

jdashg2• 6 years ago

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.

TOML for Modern C++

Related Stories