Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TOML for Modern C++

marzer.github.io

Post reply on HN
Print view View original

41–48 of 48 posts

Re: TOML for Modern C++

#41

Post by ameixaseca »

pansa2 wrote: 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?

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.

Re: TOML for Modern C++

#42

Post by jdashg »

TuxSH wrote: post #39

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.

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.

Re: TOML for Modern C++

#43

Post by jdashg »

rpasquay wrote: post #34

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 ) (*el)++; else if constexpr (toml::is_string ) el = "five"sv; }); } I thought constexpr would work at compile time but how can the compile here inside a loop "know" when t…

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.

Re: TOML for Modern C++

#44

Post by marzer »

jdashg wrote: post #43
rpasquay wrote: post #34

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 ) (*el)++; else if constexpr (toml::is_string ) el = "five"sv; }); } I thought constexpr would work at compile time but how can the compile here inside a loop "know" when t…

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.

Yup, nailed it

Re: TOML for Modern C++

#45

Post by rumanator »

paulddraper wrote: post #15
pansa2 wrote: 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…

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

Re: TOML for Modern C++

#46

Post by rumanator »

joshuamorton wrote: post #24
paulddraper wrote: post #22

Earlier quoted context omitted.

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.

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

Re: TOML for Modern C++

#47

Post by joshuamorton »

rumanator wrote: post #46
joshuamorton wrote: post #24

Earlier quoted context omitted.

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.

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

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

Re: TOML for Modern C++

#48

Post by rpasquay »

jdashg wrote: post #43
rpasquay wrote: post #34

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 ) (*el)++; else if constexpr (toml::is_string ) el = "five"sv; }); } I thought constexpr would work at compile time but how can the compile here inside a loop "know" when t…

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.

Thank you for the explanation!
Post reply on HN