However, what's great for avoiding straightforward failures becomes a nightmare when your goal is to guarantee that no undefined behaviour happens. The decoupling between raising of the exception and handling it, that makes avoiding failures so easy in C++, makes it virtually impossible to guarantee that the program never runs info undefined behaviour.

I do not see from where that conclusion originates. Functions that are being called (and potentially fail with an error) should be decoupled from the caller. It doesn't matter if the error is propagated as an exception or a simple code. Error codes can be silently ignored, while exceptions can't, which means you are more likely to introduce bugs while using error codes. If you ignore an error condition and go on, your process might go into undefined behaviour territory. An exception will propagate to the nearest handler, cleaning every object along the way.

int rc = fx ();
if (rc != 0)
handle_error ();

int rc = fx ();
if (rc != 0)
throw std::exception ();

These are not equivalent - far from it.

The problem with that is that you have no idea of who and where is going to handle the exception.

As it should be. Why should you care who handles the error? In your example, the function fx() obviously doesn't care - just informs that an error happened. You are advocating coupling callees with callers.

(code examples)
It's far more readable and — as a bonus — compiler is likely to produce more efficient code.

First - it's not equivalent, since you also need to jump out after the error in C. The most common way I see with C programmers is using goto for that task (because you usually need to release resources and there is no RAII in C), which isn't readable at all and can introduce bugs. Can you recall scoping rules with goto out of your head? I don't think so.
Second - if you forget about jumping out, your code will just go on thinking no error was generated.
Third - you have no evidence of the compiler producing that much better code for the programmer to care. When it comes to trading safety for efficiency, you should go with the safety the exceptions provide you with.
Fourth - I find exceptions far more readable - "if X happened, generate error Y". What's not readable about that?

However, it doesn't end there. Consider the case when the exception is not handled in the function that raises it. In such case the handling of the error can happen anywhere, depending on where the function is called from.

That is exactly the point. Callee should not care who handles its errors. When a C function returns an error code, it doesn't care who handles it. The same logic applies to exceptions. Once again you are trying to tie callees with callers.

As you fix individual bugs you'll find out that you are replicating almost the same error handling code in many places. Adding a new function call to the code introduces that possibility that different types of exceptions will bubble up to the calling function where there are not yet properly handled. Which means new bugs.

If you don't handle an exception, the default handler will (terminating the process with an error message). If you don't handle an error code in C - nothing will inform you of that. Your process will go on in an erroneous state thinking everything is ok. Good luck debugging such errors.

If you don't give up on the "no undefined behaviour" principle, you'll have to introduce new exception types all the time to distinguish between different failure modes. However, adding a new exception type means that it can bubble up to different places. Pieces of code have to be added to all those places, otherwise you end up with undefined behaviour.

First - you won't end up with undefined behaviour, since the exception propagation is well defined by the Standard. You'll end up with the default handler which will show you the error message.
Second - similar logic applies to error code. If you create a new error code, you need to handle it. If you don't, your process will silently go into some undefined state.

Well, the problem is that exception specifications are just a tool to handle the problem of exponential growth of the exception handling code in a more systematic manner, but it doesn't solve the problem itself. It can even be said it makes it worse as now you have to write code for the new exception types, new exception handling code *and* new exception specifications.

That really doesn't make sense. What is that problem that exceptions don't solve and error codes do? Please define it. Also - what exception specifications? If you're talking about throw(…) in declarations, those were always a bad idea and were discouraged. Now, they're deprecated and should never be used.

Consider what happens when initialisation of an object can fail. Constructors have no return values, so failure can be reported only by throwing an exception. However, I've decided not to use exceptions.

And that is your problem there. You decided to go against the language features and you ended up with some absurd semi-constructed states, which you need to handle manually. If you followed the language, that is:

• An object is considered constructed (initialized) when its constructor returns with no exception.
• With RAII, all your resources should be released in the destructor, making resource handling automatic.

you'd find that your code is both safer and simpler. Object could be either constructed or not. Error would be signalled on failed constructions. Resources would be automatically freed.
Instead you made a little hell for yourself, where you need to take that semi-constructed state into account, potentially introducing bugs.

Now you say: But that's just a consequence of your artificial restriction of not using exceptions! If exception is thrown in a constructor, C++ runtime cleans the object as appropriate and there is no 'semi-initalised' state whatsoever!

Fair enough. However, it's beside the point.

No, it's not beside the point. The whole point is about you fighting the language, instead of using its features to make safe code.

And that is not a reasonable option for an infrastructure component with the need to be very robust in the face of failures.

As a person who is making such "infrastructure components", as you called them, I claim you are totally wrong on that front. Proper usage of exceptions and proper usage of language features make your code resistant to failures and very safe. Fighting against it is what lead you to this mess, and you try to blame the language for it.

Moreover, even if initialisation wasn't a problem, termination definitely is. You can't really throw exceptions in the destructor. Not because of some self-imposed artificial restrictions but because if the destructor is invoked in the process or unwinding the stack and it happens to throw an exception, it crashes the entire process.

Right - you should not throw form the destructor (they are noexcept now, in fact). Try to think about more closely - you are releasing resources and you encounter an error. If this is not critical and the process can continue, you can safely not throw. If it it's critical, you should terminate because, well, it's critical.

Thus, if termination can fail, you need two separate functions to handle it

No, just follow RAII. You'll get a safe and reliable way of automatically releasing resources in a single function - the destructor.

However, once you introduce separate init functions, the number of states starts to grow.

So you see why your idea of semi-states is bad. Why do you advocate it then?

With objects like these it's almost impossible to guarantee predictable behaviour.

You created a problem which doesn’t really exist, if you follow the simple rules. You then created a really bad workaround to that problem. And, in the end, you list the reasons why your solution is bad. That's absurd.

To summarise the above, I believe that requirement for fully-defined behaviour breaks the object-oriented programming model. The reasoning is not specific to C++. It applies to any object-oriented language with constructors and destructors.

Pretty much every piece of code, which is made with proper fashion, proves you wrong. Don't fight the language, but learn to use it to your advantage. You'll find all your problems are really artificial.

The first point of yours was that certain exception patterns are awkward. I agree - so simply don't do it this way. Don't use exceptions for control flow. If, when throwing, you need to know who catches the error then it is a misuse of exception handling and too tight of a coupling. Exceptions are to be treated as special return values that automatically bubble up as a default behavior.

If an operation is expected to fail sometimes, and meaningful actions can be taken as a result, then error codes as return values are totally reasonable. They mix with exceptions well.

For destructors being invoked at the end of the block, you can do that too with C: http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html

For virtual methods, I agree it's quite painful, but for a schema that's working in years you can look at gobject and how they do it. For a single class there are two data structures, the instance struct and the class struct. The class struct is where you put the vtable.
That means you have a single vtable for one class instead of having one vtable per-instance.

While exception do allow the de-coupling of handling from cause, they don't heve to be used that way. You can stop exceptions propagating out of any block and handle, assert or convert to c-style at whatever level you want.

In an earlier example you talked about calling a third-party function that could generate any (to you) unknown exception, so just wrap it in a try…catch(…) and convert to a return FAIL or asssert, whechever you prefer. How is not using exceptions going to help in this situation?

Almost all of C can be mis-used just as easily as C++. At least with exceptions, if you do miss one it will propagate out and you will know, with a missed return check, you may never find out.

Abstraction is a technique for managing complexity but these "modern" high-level features often results in more work for machine and developers without any additional values.

code like this:

XX* p = new(std::nothrow) XX(..);

if (nullptr == p) { handle_error(); }
else {
auto ret = p->init();
if (OK != ret) { handle_error(); }
}

if ( p->init_succ() ) {
auto ret = p->deinit();
if (OK != ret) {
handle_error();
}
}

…

From there, it's a matter of allocating from that particular pool (one of the reasons I think interfaces like malloc() are broken, is because there is no way to supply a generic pool of memory, or to seize a pool from malloc() and have it manage allocations within it).

More sophisticated memory handling would benefit C.

If it was talking about C vs. C++ it would make no sense. C is (more or less) a subclass of C++.

As for C++11, C++14 etc., by growing the featureset it's making the problem even more grave. Idiomatic C++ today is definetely a bigger mess than it used to be in 1995. Soon enough it will be as messy as Java :(

"This is great when you are OK with 80% or 90% solutions. Errors are sparse and handling them correctly in 90% or cases can mean the problem will be never hit, especially if the program is not used very widely."

However, even a hello world application doesn't have a <10% (we're sayingthat only 10% or less of the logic in the application doesn't handle every single error that can happen absolutely perfectly…) fault ratio; not even the UNIX kernel has a <10% fault ratio….there's always a way to break stuff, why fix it until it needs to be fixed? At which point you know the issue, and how to handle it…. I can hack Windows and activate it any day of the week -> switching to another language isn't going to stop that.

Move to C++14, not to plain C. C++ i s an extension of C -> You can use any part of C in C++ -> including C syntax. In fact, most beginner C++ courses don't even teach you any C++ at all - it's all C syntax run under a C++ compiler. So in essence it doesn't even make sense to say C would have been better than C++….

The true trick to any lower level programming language is architecture. How you design your application will make it or break it -> regardless of the actual language used.

I'm disappointed seeing all the comments about replacement languages for C; why aren't people working on replacing POSIX APIs with C++ methods over C methods? Why isn't anyone working on replacing C altogether with C++ rather than just letting it be an extension? You know…making a true C++ runtime in Assembly instead of requiring a C runtime over Assembly? Bet ya that'd be much faster than Go and we wouldn't have to learn any new languages or APIs (well, for the most part - syntax would certainly change a bit for some system methods).

Donate me 100k and I'll do it myself - just give me a few years…

The father of C++ isn't dead yet, its only getting better and better and better and better and better.

You just need to take the time to work it out. It takes YEARS to LEARN programming, not days -> if you are looking for a single day answer switch to .NET or some other auto-generated non-sense and let the quality speak for itself (but I'm sure you know this already ^^).

Another alternative to is rust, being developed by Mozilla. It's focus is on being very fast and very safe. The first stable version is due to be released within the next few months and from the little bit I've played around with it, it looks promising as an alternative to C that can be used to build system programs that need to be robust.