"That's why C++ is overly cumbersome unless you ignore most of its capabilities, like exceptions."
Complete non sequitur. Exceptions are not "most of C++ capabilities". In fact, you can refuse to catch or throw exceptions for 99% of your (millions of lines) of code and still end up with a very large, stable code base running a large portion of the internet. Ask Google.
Today, there's pretty much no viable alternative to C++ for writing large scale, high performance systems with reliable performance guarantees. You could do it in C if you have a religious anti-C++ agenda but that would be like cutting off your nose to spite your face, and you'll end up in a horrible mish-mash of macros and generated code all over the place for a project with any level of complexity. Rust or D might get there some day if they manage to attract a solid community and big corporate backing. But they are certainly not there yet.
To add to this point: There are C++ frameworks such as Qt who don't use exceptions at all! And what impressed most: When writing a Qt application, you don't even miss exceptions. You don't have to resort to C-style return value checking all over your code. How is that? It took me some time to figure this out, but I believe it is because Qt applies the "Null Object" pattern consequently - down to the deepest depth of their framework,
The point is that these features are infectious. If you don't want to throw exceptions, how do you handle a failure in a constructor? And then if you abandon constructors, other C++ features are unusable without them. And so on.
Have a look at Tarsnap's source code.
I wouldn't call Herb Sutter's _Exceptional C++_ a huge tome and it seems to be the standard treatment of exception safety.
I'm not saying it's impossible to write exception safe code. I'm saying that you can write code without exceptions without being worse off for it.
So I'm curious about why you think RAII makes writing exception-safe code difficult?
The book is excellent. For anyone who wants to use C++ exceptions, it should be required reading. But as someone who has gone through that gauntlet, I feel that I probably would've been better served by spending my time on something other than mastering the finer points of exceptions.
The reason I started talking about C++ exceptions in the first place is because, in my experience, when someone is very pro-RAII (like the original commenter I responded to), they also tend to be pro-exceptions. This isn't always true, but on average, it seems like either people prefer both or prefer neither.
Writing exception-safe code is certainly one of the hardest challenges available in C++, so if you enjoy a good challenge, then it's hard to do better. But if you're just looking to design large-scale systems, it seems like exceptions are unnecessary, as Google has demonstrated by banning the use of exceptions in their codebases.
In my experience, by refraining from using exceptions, it's possible to design large codebases more quickly, with fewer bugs, and without losing any safety or extensibility. However, this is simply my personal experience, and it may be mistaken to generalize this into a claim that all codebases among all C++ teams should refrain from using exceptions.
So, that's all I meant. I was also in excruciating pain yesterday due to a certain tooth that decided to segfault in my mouth, which may have contributed to the adversarial nature of my writing style. I feel bad about how I came across, and I sincerely apologize for it. No excuses, though: I should've done better.
exceptions (specifically, exceptions from constructors) are part of what RAII is, so it's only natural that people "prefer both".
As another personal anecdote, in my experience working with a large (175MLoC at last count) mostly-C++ codebase, I can't imagine how painful it would have been if the code didn't use exceptions.
I can't understand how a correct init method could be easier to write than a ctor, given that the compiler is required to generate code that knows which of your base classes and fields are already initialized at any point they could fail, which you would have to do yourself after moving to an init method, as well as losing the guarantee you can't silently ignore an error by forgetting to check for it.