3 ms·

I happen to believe the inverse of all of this. Yes std::exception is optional, but why not use it to root your hierarchy? The only time I've answered in the ne

I happen to believe the inverse of all of this. Yes std::exception is optional, but why not use it to root your hierarchy? The only time I've answered in the negative is when the project specifically required no standard library could be used (yes, great that it's optional!). I sympathize with C-compatible API's to simplify an interface, though it's not my first choice. Rooting hierarchies in std::exception integrates library code safely and consistently -- especially over time and code revision to both the library and your end -- because at some point after specific exceptions are all missed some `catch(std::exception)` is hit on errors from both you and the library, and a consistent `what()` call can eventually inform the user with a message.

saurik 10y ago
> I happen to believe the inverse of all of this. I will say that I didn't provide an argument for not using std::exception, nor was I trying to convince someone else not to do so; I was simply stating that C++ does not require it and a lot of code doesn't use it: it sounded like the person I was responding to was claiming that in C++ you knew everything was eventually std::exception while that wasn't the case for Java, when the exact opposite is actually true (that in C++ you can and often do run into cases where an exception is just some random data type, and in Java all exceptions fundamentally must implement Throwable as an engine constraint). I only used the fact that I don't use it as an example of someone who doesn't. FWIW, I actually use a lot of my code in environments where I can't use the standard library, so even your paragraph of why you supposedly believe the opposite of some ancillary point I wasn't trying to make you have admitted why I do what I do is valid even to you. > I sympathize with C-compatible API's to simplify an interface, though it's not my first choice. It isn't about simplifying an interface: it is because in addition to the C++ ABI being itself fundamentally brittle (due to vtable ordering), you have to remember that some people use libstdc++ while others are now annoyingly using libc++ (I blame Apple, and I have absolutely no sympathy: they have ruined what little interoperability we used to have in this ecosystem they cared absolutely nothing for), and the ABIs between popular compilers is different; so when someone uses a C++ interface for their library I spend the next three days cursing their name and adding them to my "never let this person program anything ever again" list while I waste my time pulling crazy stunts to dynamically look up mangled symbol names and working around egregious incompatibilities in basic things like "when a C++ member function returns a structure, MinGW puts the hidden structure return pointer first while MSVC puts it after the hidden this pointer". At this point I know the ABI of every major compiler on every major architecture, and I have been considering switching entirely to gcc and contributing a ton of patches that let me #pragma mark entire regions of code (due to header files) with specific calling conventions and layout ABIs, as this attitude that C++ is somehow appropriate for this purpose is creeping into more and more places as C++11 has caused more and more people to start using C++ without understanding its limits :/.

saurik 10y ago

> I happen to believe the inverse of all of this. I will say that I didn't provide an argument for not using std::exception, nor was I trying to convince someone else not to do so; I was simply stating that C++ does not require it and a lot of code doesn't use it: it sounded like the person I was responding to was claiming that in C++ you knew everything was eventually std::exception while that wasn't the case for Java, when the exact opposite is actually true (that in C++ you can and often do run into cases where an exception is just some random data type, and in Java all exceptions fundamentally must implement Throwable as an engine constraint). I only used the fact that I don't use it as an example of someone who doesn't. FWIW, I actually use a lot of my code in environments where I can't use the standard library, so even your paragraph of why you supposedly believe the opposite of some ancillary point I wasn't trying to make you have admitted why I do what I do is valid even to you. > I sympathize with C-compatible API's to simplify an interface, though it's not my first choice. It isn't about simplifying an interface: it is because in addition to the C++ ABI being itself fundamentally brittle (due to vtable ordering), you have to remember that some people use libstdc++ while others are now annoyingly using libc++ (I blame Apple, and I have absolutely no sympathy: they have ruined what little interoperability we used to have in this ecosystem they cared absolutely nothing for), and the ABIs between popular compilers is different; so when someone uses a C++ interface for their library I spend the next three days cursing their name and adding them to my "never let this person program anything ever again" list while I waste my time pulling crazy stunts to dynamically look up mangled symbol names and working around egregious incompatibilities in basic things like "when a C++ member function returns a structure, MinGW puts the hidden structure return pointer first while MSVC puts it after the hidden this pointer". At this point I know the ABI of every major compiler on every major architecture, and I have been considering switching entirely to gcc and contributing a ton of patches that let me #pragma mark entire regions of code (due to header files) with specific calling conventions and layout ABIs, as this attitude that C++ is somehow appropriate for this purpose is creeping into more and more places as C++11 has caused more and more people to start using C++ without understanding its limits :/.