6 ms·

C++ projects banning exceptions is a massive blunder. We should not disable important aspects of the language that provide useful semantic features to satisfy t

C++ projects banning exceptions is a massive blunder. We should not disable important aspects of the language that provide useful semantic features to satisfy the anti-bloat superstitions of a few who remember bad C++ compilers of the 1990s. Nobody feels the need to create an exception-less variant of Java or Python, after all. A ban on C++ exceptions is a huge red flag for me. A project has to be really special if I'm going to contribute to it after it's crippled the language.

bigcheesegs 10y ago
The llvm-project is a compiler. Its developers are well aware of the true cost of exceptions.
- barrkel 10y ago
  Actually, compilers typically don't use exceptions because they don't usually abort on the first instance of a problem. Compilation has historically been an lengthy batch job, and thus reporting many errors to be fixed between iterations improves user productivity.
  - favorited 10y ago
    I think the point was that LLVM compiler infrastructure has a first-class C++ font-end. They know the ins-and-outs of language features because they are implementing standards-compliant compilers for said language.
    - barrkel 10y ago
      Most self-hosted compilers are written in languages ill-suited to compiler writing. The choice of features used is often a compromise, rather than best practice for either good compiler design or good target language use. C++ users in particular have strong concerns about things like RTTI and the overhead of exceptions not thrown. The cost of making unthrown exceptions low (near zero) is that throwing exceptions is much more expensive. This turns into a feedback loop, where C++ programs end up performing better if they never throw any exceptions because of the tradeoff. This feeds into self-hosted compilers. Thing is, certain compiler design techniques can work well with cheap unwinding: constraint solving (more common in languages with better type systems than C++), forward-looking grammar assertions with speculative parsing, IDE-integrated code completion (implement the lexer to add the cursor position as a special token, and jump out of the parser when it's found, where all the context is available to pass along). But C++'s peculiar tradeoffs may make using things like exceptions less than ideal to use for this purpose, not because exceptions are the wrong tool, but because most C++ programs are not compilers and aren't tuned for it. And OTOH, compilers written in low-level languages like C++ often twist themselves into knots to simulate things like tree pattern matching, multiple dispatch, destructuring binds, etc. Sometimes they even give up and write code generating tools.
  - strcat 10y ago
    LLVM doesn't take shortcuts like that. It's designed as a set of reusable libraries for use in all kinds of tooling. In many cases it even has to continue going after detecting errors and recording a representation of them, so that it can still produce useful information. That's an important feature for lots of tooling.
gakada 10y ago
Exceptions in C++ are rotten. void read_file_by_lines(const char* path, void (*callback)(const char* line)) { FILE* file = fopen(path, "r"); size_t length = 0; char* line = NULL; while (-1 != getline(&line, &length, file)) { callback(line); } free(line); fclose(file); } This C function should be compatible with C++. If exceptions are off, it is. If exceptions are on then it's dangerous because if an exception is thrown through callback, then the file handle and line buffer will leak. C++ exceptions are predicated on the assumption that all resources are managed using RAII. In the real world, this isn't true, especially considering that C doesn't even have RAII. Python programmers (including me) love their exceptions, because Python is a dynamic language, and exposes system resources as reference counted objects.
- pjmlp 10y ago
  This is the real issue, so many C++ features are hampered due to the drop-in compatibility with C code.
- pif 10y ago
  Your example is wrong. This function is compatible with C++ as soon as you document it as not accepting exception-throwing callbacks.
  - gakada 10y ago
    I'm sorry, I can't capture such a complicated issue with a pithy example. You will have to settle for my illustrative one. The most general definition of the restriction is that C++ code cannot throw exceptions through exception unsafe code. How do you know if your C++ function was called from exception unsafe code? You can't! So it's only ever safe to throw an exception when you are expecting it to be caught immediately i.e. you can use exceptions as glorified error codes, but not much else. In Django I can throw a Http404 exception from deep inside a view and the server will come up with a 404 response. I can assert and the client will get a 500 error but the server won't go down. This is the real power of exceptions, and God help anybody who tries to do it in C++.
  - 10y ago
pjmlp 10y ago
I agree with you, however Bjarne wanted to sneak C++ into C code, given his experience being forced to use C (there are a few interviews where he mentions this). So by having exceptions, with code that only knows about C semantics but was compiled with C++ mode, you open the door to all sorts of nasty surprises. So exceptions can cause resource leaks and other issues like being thrown in the middle of a UNIX signal. Which leads to the situation that sadly many library writers avoid them. I still enjoy using C++, but the best place for it is as infrastructure language for the bottom layer when performance requires it, then using something else on the other layers.

bigcheesegs 10y ago

The llvm-project is a compiler. Its developers are well aware of the true cost of exceptions.

barrkel 10y ago
Actually, compilers typically don't use exceptions because they don't usually abort on the first instance of a problem. Compilation has historically been an lengthy batch job, and thus reporting many errors to be fixed between iterations improves user productivity.
- favorited 10y ago
  I think the point was that LLVM compiler infrastructure has a first-class C++ font-end. They know the ins-and-outs of language features because they are implementing standards-compliant compilers for said language.
  - barrkel 10y ago
    Most self-hosted compilers are written in languages ill-suited to compiler writing. The choice of features used is often a compromise, rather than best practice for either good compiler design or good target language use. C++ users in particular have strong concerns about things like RTTI and the overhead of exceptions not thrown. The cost of making unthrown exceptions low (near zero) is that throwing exceptions is much more expensive. This turns into a feedback loop, where C++ programs end up performing better if they never throw any exceptions because of the tradeoff. This feeds into self-hosted compilers. Thing is, certain compiler design techniques can work well with cheap unwinding: constraint solving (more common in languages with better type systems than C++), forward-looking grammar assertions with speculative parsing, IDE-integrated code completion (implement the lexer to add the cursor position as a special token, and jump out of the parser when it's found, where all the context is available to pass along). But C++'s peculiar tradeoffs may make using things like exceptions less than ideal to use for this purpose, not because exceptions are the wrong tool, but because most C++ programs are not compilers and aren't tuned for it. And OTOH, compilers written in low-level languages like C++ often twist themselves into knots to simulate things like tree pattern matching, multiple dispatch, destructuring binds, etc. Sometimes they even give up and write code generating tools.
- strcat 10y ago
  LLVM doesn't take shortcuts like that. It's designed as a set of reusable libraries for use in all kinds of tooling. In many cases it even has to continue going after detecting errors and recording a representation of them, so that it can still produce useful information. That's an important feature for lots of tooling.

gakada 10y ago

Exceptions in C++ are rotten. void read_file_by_lines(const char* path, void (*callback)(const char* line)) { FILE* file = fopen(path, "r"); size_t length = 0; char* line = NULL; while (-1 != getline(&line, &length, file)) { callback(line); } free(line); fclose(file); } This C function should be compatible with C++. If exceptions are off, it is. If exceptions are on then it's dangerous because if an exception is thrown through callback, then the file handle and line buffer will leak. C++ exceptions are predicated on the assumption that all resources are managed using RAII. In the real world, this isn't true, especially considering that C doesn't even have RAII. Python programmers (including me) love their exceptions, because Python is a dynamic language, and exposes system resources as reference counted objects.

pjmlp 10y ago
This is the real issue, so many C++ features are hampered due to the drop-in compatibility with C code.
pif 10y ago
Your example is wrong. This function is compatible with C++ as soon as you document it as not accepting exception-throwing callbacks.
- gakada 10y ago
  I'm sorry, I can't capture such a complicated issue with a pithy example. You will have to settle for my illustrative one. The most general definition of the restriction is that C++ code cannot throw exceptions through exception unsafe code. How do you know if your C++ function was called from exception unsafe code? You can't! So it's only ever safe to throw an exception when you are expecting it to be caught immediately i.e. you can use exceptions as glorified error codes, but not much else. In Django I can throw a Http404 exception from deep inside a view and the server will come up with a 404 response. I can assert and the client will get a 500 error but the server won't go down. This is the real power of exceptions, and God help anybody who tries to do it in C++.
- 10y ago

pjmlp 10y ago

I agree with you, however Bjarne wanted to sneak C++ into C code, given his experience being forced to use C (there are a few interviews where he mentions this). So by having exceptions, with code that only knows about C semantics but was compiled with C++ mode, you open the door to all sorts of nasty surprises. So exceptions can cause resource leaks and other issues like being thrown in the middle of a UNIX signal. Which leads to the situation that sadly many library writers avoid them. I still enjoy using C++, but the best place for it is as infrastructure language for the bottom layer when performance requires it, then using something else on the other layers.