4 ms·

> since they behave poorly across library boundaries on many platforms thanks to the lack of properly standardized ABI, The same also holds for, say, std::stri

by Ace17 9y ago

> since they behave poorly across library boundaries on many platforms thanks to the lack of properly standardized ABI, The same also holds for, say, std::string. You can't pass them across library boundaries without a unified ABI. More generally, you can't pass anything STL-ish between library boundaries. Why make a special case for C++ exceptions?

jchw 9y ago
Because throwing an exception can bubble across library boundaries, including over C-style APIs that are fully compatible across library boundaries.
- mhh__ 9y ago
  If your C-api throws and then doesn't handle exceptions, then it's not a C api, it just happens to use the C ABI.
  - jchw 9y ago
    It's more complicated than that, though, because a C library seldom controls the callstack. Exception throwing is viral. A valid example would be using a pure, fully ANSI C library with no dependencies in a C++ program, but then, in a callback PASSED to C APIs, accidentally allowing an exception to leak. Then, your runtime will try to unwind the stack and can implode on itself. There's definitely more valid cases where this can happen, but since C APIs generally do rely on callbacks for many things, it seems like a logical one. Another case would be C-style dispatch tables like SDLs RW interfaces. Implementing them to interact with C++ classes could definitely cause problems. Of course, happening to use the C ABI is a valid use case that actually works if you really only use the C ABIs, but once a single exception is raised all bets are off. This kind of sucks.
    - mhh__ 9y ago
      I said not handling the exception, not that one shouldn't use exceptions. Handling, here, could also mean using callbacks so the C code (using the api) can customize things. If you expose a C api, using C++ code that involves exceptions, then the exceptions should all be handled (caught) inside the C++ code. This means that should the runtime start unwinding, it will not terminate the program.
      - jchw 9y ago
        Of course. I understand that. But I am arguing that this kind of sucks. I don't think that it was necessarily avoidable. But for a feature that's seldom used in the standard library and for the stated reasons, a lot of other libraries, it kind of sucks. There's also other reasons I don't like exceptions, but I'll admit many of them are no longer an issue anymore. On 32 bit Windows, if you were using GCC, which was pretty likely if you were trying to do modern C++ at the time, exceptions were limited to SJLJ and DWARF2 based exceptions which both had their own problems. For one, I'd prefer my production binaries didn't require DWARF2 CFI data. Luckily I believe nowadays in 64bit you can use SEH since it isn't covered by the Borland patent for its AMD64 implementation (do I have that right?) But I digress. If exceptions were the default and didn't have these issues, I think it would be much better. But since at least some of the issues are still relevant, you simply cannot always use exceptions depending on your needs. And that has an effect on the ecosystem that has led to a lot of mature libraries avoiding them entirely. I'm definitely not saying you can't use exceptions, just outlining why I don't and why I believe the greater C++ ecosystem isn't all on board for them.
        mhh__ 9y ago
        I can't really comment on the GCC windows stuff: I do software on Linux, and if I'm on windows then I use VC++ (Or a good programming instead e.g. F#/C# usually). VC++ is modern enough, so the above issue don't even apply very much. C++ works(TM) with exceptions, AFAIK the vast majority of the ecosystem would use them (Some people e.g. Google and Qt, can't due to existing code). RAII is only really intended to work with exceptions (No return values from constructors, unless! you bodge your own (which you could do, if you were a big organisation)) Edit: Just checked, SEH has been in GCC (64bit) since ~4.8

by Ace17 9y ago

jchw 9y ago

Because throwing an exception can bubble across library boundaries, including over C-style APIs that are fully compatible across library boundaries.

mhh__ 9y ago
If your C-api throws and then doesn't handle exceptions, then it's not a C api, it just happens to use the C ABI.
- jchw 9y ago
  It's more complicated than that, though, because a C library seldom controls the callstack. Exception throwing is viral. A valid example would be using a pure, fully ANSI C library with no dependencies in a C++ program, but then, in a callback PASSED to C APIs, accidentally allowing an exception to leak. Then, your runtime will try to unwind the stack and can implode on itself. There's definitely more valid cases where this can happen, but since C APIs generally do rely on callbacks for many things, it seems like a logical one. Another case would be C-style dispatch tables like SDLs RW interfaces. Implementing them to interact with C++ classes could definitely cause problems. Of course, happening to use the C ABI is a valid use case that actually works if you really only use the C ABIs, but once a single exception is raised all bets are off. This kind of sucks.
  - mhh__ 9y ago
    I said not handling the exception, not that one shouldn't use exceptions. Handling, here, could also mean using callbacks so the C code (using the api) can customize things. If you expose a C api, using C++ code that involves exceptions, then the exceptions should all be handled (caught) inside the C++ code. This means that should the runtime start unwinding, it will not terminate the program.
    - jchw 9y ago
      Of course. I understand that. But I am arguing that this kind of sucks. I don't think that it was necessarily avoidable. But for a feature that's seldom used in the standard library and for the stated reasons, a lot of other libraries, it kind of sucks. There's also other reasons I don't like exceptions, but I'll admit many of them are no longer an issue anymore. On 32 bit Windows, if you were using GCC, which was pretty likely if you were trying to do modern C++ at the time, exceptions were limited to SJLJ and DWARF2 based exceptions which both had their own problems. For one, I'd prefer my production binaries didn't require DWARF2 CFI data. Luckily I believe nowadays in 64bit you can use SEH since it isn't covered by the Borland patent for its AMD64 implementation (do I have that right?) But I digress. If exceptions were the default and didn't have these issues, I think it would be much better. But since at least some of the issues are still relevant, you simply cannot always use exceptions depending on your needs. And that has an effect on the ecosystem that has led to a lot of mature libraries avoiding them entirely. I'm definitely not saying you can't use exceptions, just outlining why I don't and why I believe the greater C++ ecosystem isn't all on board for them.
      - mhh__ 9y ago
        I can't really comment on the GCC windows stuff: I do software on Linux, and if I'm on windows then I use VC++ (Or a good programming instead e.g. F#/C# usually). VC++ is modern enough, so the above issue don't even apply very much. C++ works(TM) with exceptions, AFAIK the vast majority of the ecosystem would use them (Some people e.g. Google and Qt, can't due to existing code). RAII is only really intended to work with exceptions (No return values from constructors, unless! you bodge your own (which you could do, if you were a big organisation)) Edit: Just checked, SEH has been in GCC (64bit) since ~4.8