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

Current hardware trends make C++ exceptions harder to justify

open-std.org

Post reply on HN
Print view View original

341–350 of 516 posts

Re: Current hardware trends make C++ exceptions harder to justify

#341

Post by kllrnohj »

jawilson2 wrote: post #319
PaulDavisThe1st wrote: post #193

Earlier quoted context omitted.

Again, most experienced C++ programmers would say that even a 0.1% "normal" failure rate indicates a situation that should not be handled by exceptions. You seem to be describing a style of programming where there's a bunch of work to be done, most efforts to do the work will succeed, a few will predictably (albeit randomly, perhaps) fail. While I would concede that you might conclude that exceptions are the perfect…

If our system (algo trading) throws an exception, we collect core dumps from all threads, error messages go to all of our dashboards, and the system waits for a graceful restart. Exceptions almost always are due to something that should NEVER happen, and we will push out a fix ASAP. It is "exceptional" because we expect the call rate to be 0.00000%. I keep reading how terrible exceptions are, and the examples are alm…

Do you do that because that's how you want the language to work or because that's how the performance constraints required you to design your system?

Your argument seems to be that "well, yeah, of course exceptions should suck, you shouldn't ever use them" and just... being happy with that? The purpose of the paper is to say "hey, maybe exceptions shouldn't be a dumpster fire piece of hot garbage?"

Re: Current hardware trends make C++ exceptions harder to justify

#342

Post by tokumei »

gumby wrote: post #191

I find this paper quite unconvincing. Exceptions are exceptional so in principle it doesn't matter (within reason) how long it takes to throw one as long as it costs nothing not to do so. So measuring the cost of repeated throws IMHO doesn't cast light on any useful case, and the approaches that add runtime cost for the path not taken, even Herb Sutter's, are not acceptable. His code transformation example is simply…

I much prefer using a Result type now, even in C++. Makes it easier to reason about the code in my opinion.

Re: Current hardware trends make C++ exceptions harder to justify

#343

Post by catskul2 »

gumby wrote: post #243
JoeAltmaier wrote: post #213

Earlier quoted context omitted.

But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. I deplore that - its side-effects writ large. But those that use it, find it reasonable and sensible. It's become hard to distinguish right and wrong when it comes to CPU optimization. Different versions of the 'same' CPU can have wildly different sweet spots.

> But there's a design pattern where nearly everything is returned as an exception. shudder The worst of cargo cults!

Is "cargo cult" really what you mean here. It doesn't seem to fit.

Re: Current hardware trends make C++ exceptions harder to justify

#344

Post by zozbot234 »

Koshkin wrote: post #322
zozbot234 wrote: post #295

Earlier quoted context omitted.

Lambda is designed to be a zero-overhead feature. In the worst case, it's the same as passing an additional void* ctx argument to a plain old function, which is the most common pattern in C/pre-lambda C++.

But it's not. A lambda is merely syntactic sugar for an object (a functional) and as such it can carry a state (the term is 'closure' in this case); depending on what is being captured, its creation can even involve a heap allocation.

Not sure I get your point - the exact same is true of a C function which is passed a void* ctx object, since those objects have to be allocated and their lifecycle has to be managed. It's still a zero overhead feature.

Re: Current hardware trends make C++ exceptions harder to justify

#345

Post by Koshkin »

zabzonk wrote: post #301
Koshkin wrote: post #160

Earlier quoted context omitted.

You are right. That's why in good old languages they were called 'procedures.'

And those languages were badly designed. Which is why we don't have "procedures" or "subroutines" in modern programming languages" - just functions.

Well that's unfortunate. I suspect the fault lies with C, the early versions of which did not have the 'void' keyword, and 'int' was assumed as the default return type - which also meant that when such "function" did not include a 'return' statement it "returned" whatever garbage was left in the register. Instead of adding the keyword 'void' (to be abused later as the empty arg list) they could have added 'proc' instead, but that would have complicated the parsing, and so they went with the 'void' pseudo-type as an indication of the fact that the function is not really a function but a procedure.

Re: Current hardware trends make C++ exceptions harder to justify

#346

Post by ncmncm »

Koshkin wrote: post #322
zozbot234 wrote: post #295

Earlier quoted context omitted.

Lambda is designed to be a zero-overhead feature. In the worst case, it's the same as passing an additional void* ctx argument to a plain old function, which is the most common pattern in C/pre-lambda C++.

But it's not. A lambda is merely syntactic sugar for an object (a functional) and as such it can carry a state (the term is 'closure' in this case); depending on what is being captured, its creation can even involve a heap allocation.

It is: "zero-overhead" is defined to mean you could not open-code it yourself any better.

If you specify a capture-by-copy, you have specified a copy. If that copy involves an allocation, you have specified an allocation. There is exactly zero extra overhead: in the overwhelmingly most common uses, not even a call through a pointer.

The good news is that the compiler knows all about lambdas, so can optimize the hell out of them.

Re: Current hardware trends make C++ exceptions harder to justify

#347

Post by synergy20 »

Koshkin wrote: post #270
synergy20 wrote: post #32

Earlier quoted context omitted.

you can still set a static flag or something in ctor then check it, but you can't do anything about dtor indeed if you need throw there.

Except you are not supposed to throw in a destructor.

https://www.cs.technion.ac.il/users/yechiel/c++-faq/dtors-sh... but what if dtor fails(e.g. can't release a resource), is the by-default action terminate or ignore?

Re: Current hardware trends make C++ exceptions harder to justify

#348

Post by jstimpfle »

wvenable wrote: post #136
jstimpfle wrote: post #116

Earlier quoted context omitted.

> Exceptions come naturally from the realization that you mostly have to propagate errors to where they can be suitably handled or logged. I agree of course that errors must be handled and logged as appropriate, but the implication that this has to happen by popping from the call stack is not justified at all.

Logging can be done but I can't see how you could handle errors. If I'm processing 10 transactions and transaction 8 fails, needs to be retried a couple of times before being skipped for 9, I don't know how you'd do that other than going up the stack to where you're looping over the transaction list.

Not everything is a transaction; and not all transactions are processed serially in non-overlappend time slices. Most systems will process multiple pieces of work concurrently (and can't just throw a new OS thread at each of them).

The implication is that you can't just back out of a call stack like in a quickly hacked-up script. Stack frames aren't containers for whole transactions. Rather, pieces of work are tracked in explicitly allocated data structures, and worked on during more than 1 function call. The exception model is not compatible with this.

Re: Current hardware trends make C++ exceptions harder to justify

#349

Post by ncmncm »

erwincoumans wrote: post #268
TillE wrote: post #200

Earlier quoted context omitted.

"Modern C++ bad" is such a weird HN meme, fortunately it's not an opinion I see a lot elsewhere. Old C++ was awful, the new stuff makes it actually usable. Personally I like how even in embedded code where you don't want to include the standard library, you can still efficiently use language constructs like constexpr, lambdas, etc.

I didn't mean to say "modern C++ is bad", but I'd prefer a small subset that I can be sure no surprises happen: no hidden memory allocations and such. In fact, we use modern C++ and Eigen and CppAd Codegen in some of our projects: the generated C code by tracing a full sim step is about 5 times faster, likely due to no memory allocations and cache friendly memory access.

Careful coding to get runtime properties you value is just careful coding. It is not a language subset, and there is strictly negative value in a subset "closer to C".

When coding carefully, you can still take full advantage of all of the most powerful features of the language without penalty. Maybe you watch your cache footprint, and use memory supplied by the caller, and avoid branches that would often be mis-predicted. That's just programming.

Re: Current hardware trends make C++ exceptions harder to justify

#350

Post by TheMonarchist »

kllrnohj wrote: post #331
mcguire wrote: post #177

Earlier quoted context omitted.

" Java's checked exceptions are generally regarded as a mistake. " By people who do not want to believe that errors are part of a system's API and prefer to just write the happy path and let any exception kill the process. And who don't mind getting called at 2:00 am because a dependency buried deep in a subsystem threw an exception that you'd never heard of before.

Errors are part of the system's API, but Java's checked exceptions aren't really that. Case in point, the many checked exceptions in the Java standard library that are never, ever thrown. Ever. Such as ByteArrayOutputStream#close(). In fact the docs on that method even say it doesn't do anything, and won't throw an exception. But there's still a checked exception that you have to handle, because it came from the inte…

> Like maybe checked exceptions in C++ would work

https://en.cppreference.com/w/cpp/language/except_spec

Post reply on HN