Current hardware trends make C++ exceptions harder to justify

Re:Current hardware trends make C++ exceptions harder to jus... by jcelerier on Tuesday February 22, 2022 @02:40PM (#30432590)

> I am the the original author, and trust me, I am describing a real world problem.

for a more-or-less niche part of "real world". The overwhelming majority of desktop GUI apps rely on some C++ system - Qt, gtkmm, Wx, Blink, Gecko, FLTK, etc etc... and it is not an issue for those, for what exceptions are commonly used for (a write failing because the user disconnected the USB drive while it was copying, a system resource limit exhausted.. things like that). As much as massive parallel data processing tasks matter, I'd really prefer my language to not side-step writing end-user apps for something that happens at $bigcompany or $bigresearchlab.

here's the list of binaries that link against libstdc++.so.6 in my /usr/bin: https://paste.ofcode.org/gfZJwx4puVx7Uxy9a7BBU3 - don't forget those please :)

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by mcguire on Tuesday February 22, 2022 @02:54PM (#30432801)

Are you arguing that C++ is unsuitable for massive parallel data processing tasks?

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by jandrese on Tuesday February 22, 2022 @03:03PM (#30432933)

I think he's arguing that C++ exceptions are unsuitable for parallel data processing, at least in cases where exceptions are regularly thrown.

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by jcelerier on Tuesday February 22, 2022 @04:33PM (#30434154)

If exceptions are regularly thrown the software has a bad design and must be fixed. Non-exceptional stuff must of course not be handled through exceptions - no exception should ever be thrown if the software operates as it is expected to.

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by ncmncm on Tuesday February 22, 2022 @03:52PM (#30433589)

There is the red flag: "regularly thrown". "Regularly" is opposite to "exceptionally".

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by gpderetta on Tuesday February 22, 2022 @03:44PM (#30433481)

Well of course, they are slow so they are unsuitable. The issue is whether they need to be slow.

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by garbagecoder on Tuesday February 22, 2022 @03:01PM (#30432900)

No, he's arguing that he'd prefer it not be if that means breaking support for end user apps which is what the OP is arguing for.

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by jcelerier on Tuesday February 22, 2022 @04:31PM (#30434133)

No, of course not. But let's not change the language in ways that benefits those use cases at the detriment of more common use cases.

Of course, if there are ways to keep more or less the same semantics, while increasing performance, by all means it should be done !

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by PaulDavisThe1st on Tuesday February 22, 2022 @03:03PM (#30432930)

for ones that throw an exception for 1% of a unit computation, perhaps yes.

But as has been noted, that's a lot of failures and exceptions may not be the appropriate mechanism to deal with this type of failure.

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by ncmncm on Wednesday February 23, 2022 @01:04AM (#30438172)

Indeed, arithmetic errors are what NaN was invented for. It still works, and is fast.

[ Parent | on HN ]