3 ms·
> 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
by jcelerier 5y ago
> 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 https://paste.ofcode.org/gfZJwx4puVx7Uxy9a7BBU3 - don't forget those please :)
- mcguire 5y agoAre you arguing that C++ is unsuitable for massive parallel data processing tasks?
- garbagecoder 5y agoNo, 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.
- PaulDavisThe1st 5y agofor 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.
- ncmncm 5y agoIndeed, arithmetic errors are what NaN was invented for. It still works, and is fast.
- jandrese 5y agoI think he's arguing that C++ exceptions are unsuitable for parallel data processing, at least in cases where exceptions are regularly thrown.
- gpderetta 5y agoWell of course, they are slow so they are unsuitable. The issue is whether they need to be slow.
- ncmncm 5y agoThere is the red flag: "regularly thrown". "Regularly" is opposite to "exceptionally".
- jcelerier 5y agoIf 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.
- jcelerier 5y agoNo, 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 !