Live data from Hacker News

TOML for Modern C++

marzer.github.io

21–30 of 48 posts

Re: TOML for Modern C++

#21
post #7

> 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?

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

Re: TOML for Modern C++

#22

Earlier quoted context omitted.

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

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

Re: TOML for Modern C++

#23
post #19

Earlier quoted context omitted.

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…

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?

The standard library uses exceptions, but in ways that are avoidable.

Not using exceptions does necessitate avoiding the `new` operator, or allowing your program to terminate on OOM.

[1] https://stackoverflow.com/questions/37700365/if-youre-in-the...

[2] https://news.ycombinator.com/item?id=13354027

Re: TOML for Modern C++

#24

Earlier quoted context omitted.

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

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

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.

Re: TOML for Modern C++

#25
post #7

> 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?

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.

Re: TOML for Modern C++

#26
post #3
post #2

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?

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

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; }

Re: TOML for Modern C++

#27
post #19

Earlier quoted context omitted.

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?

The standard library uses exceptions, but in ways that are avoidable. Not using exceptions does necessitate avoiding the `new` operator, or allowing your program to terminate on OOM. [1] https://stackoverflow.com/questions/37700365/if-youre-in-the... [2] https://news.ycombinator.com/item?id=13354027

Many of the large C++ projects I've been on are exceptionless, but do throw an OOM exception which is caught at a very high level. That's usually the point where a crashdump is taken and some other forensics are gathered; a decent strategy is to freeze threads (if you can), release some reserve memory and try to gather evidence. Doesn't always work . . .

Re: TOML for Modern C++

#28
post #2

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?

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.

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

Re: TOML for Modern C++

#30

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

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

Post reply on HN