New school C

I really like a lot of Lua's features, especially closures and the way metatables work. Although Lua doesn't support true classes, it's possible to implement them nicely through metatables.

I haven't used Lua yet, but reading about it led me to believe it was a "broad-spectrum scripting language".

I'd like to understand the distinction you're making more deeply.

Object lifecycle and reference counting are two completely different things that only appear to be related. Even if you figure out your C++ auto_smart_magic pointers, you still have to decide when the object you're referring to is no longer necessary, just like you would in Python or Java.

Also, circular references are not a problem in managed languages the same way they are in C++. Managed languages automatically clean up cycles. C++ requires careful use of weak pointers to deal with cycles.

    X<->Y

...and the default behavior is program termination.

"destructors are called during stack unwinding when another exception is propagating, and throwing an exception during another exception causes program termination"

That was true in C++98. In C++11, the default behavior of a destructor is to call std::terminate if an exception propagates out of the destructor. This must be explicitly overridden by the programmer in order to get C++98-style behavior, which is undefined (not sure if that is better or worse than being defined as "unconditional program termination").

This does not need to be a problem. If the stack were unwound after the catch block exits (or if it explicitly unwinds the stack), there would be no double exception faults. This is not something that needs to be inefficient, nor does it need to impact performance any worse than exceptions do right now, and it has already been implemented in other languages (e.g. Common Lisp).

"what's your solution to the problem?"

See above.

"If the destructor is doing nothing but deallocating memory (and calling other destructors that only deallocate memory) then it never needs to throw and there is no problem"

Except that destructors can free other resources, and some of those other resources might throw exceptions when they are freed. A destructor might, for example, close a file; if the file cannot be synchronized when it is closed, an exception should be thrown (but the C++ standard actually requires that such an exception be ignored; after all, the programmer's job is to manually close files, right?).

"If it's doing something else then it's either doing something that another language wouldn't allow because it has no destructors (in which case you can refrain from doing it in C++ as easily as you can switch to one of those languages), or the other language has an equivalent to destructors and then will have the same issue with throwing during exception propagation. Do you see some solution to having it both ways?"

See above! There should not be any program code that cannot safely throw an exception to indicate an error, and the solution is to change the order of stack unwinding and catch block execution. C++ is not the only language with a double-exception problem; Java and Python have this problem also (e.g. in Java, if you have try...finally without any catch and the finally block throws an exception). The other benefit of this approach, aside from solving the double exception problem, is that it makes exceptions more useful by making "restarts" possible: the catch block can resume execution from some point defined by the thrower of the exception, which helps a lot with encapsulation (if e.g. the error can be corrected, but only the client code can correct it; for example, writing to an external disk that was disconnected before the operation could complete).

The only complication is that the catch block needs a stack of its own, and that the catch block needs to have a pointer to the stack frame it should return to if the rest of the stack should be unwound. These are not major challenges, certainly not by comparison with the other challenges C++ compiler writers need to deal with.

"Rubbish. Constructors don't even have return values. Throwing exceptions is the canonical way of indicating construction failure."

Oh, not having return values justifies using exceptions? Destructors don't have return values. How do destructors indicate failures?

Constructor exceptions are bad because they can cause program termination when objects are constructed in the global scope. Global objects are generally bad, of course, since their construction order is undefined, but they are allowed and they are sometimes used by the standard (e.g. cin, cout). This is not a hard one to solve: give programmers a way to catch exceptions that are thrown before main is called or after main exits.

"How about catching the exception, addressing it, and retrying the operation in the try block?"

Except that forces the client code to understand how to retry an operation, which breaks encapsulation, makes error recovery more complicated (if the exception is thrown in the middle of writing some record, you now need a way to either roll back the write, figure out where the incomplete record begins, or figure out where the last write operation failed).

"What do other languages do that you feel is superior?"

Common Lisp's "conditions" system, for one, or any language that supports continuations.

"The range of a 64-bit type is more than sufficient for the overwhelming majority of applications"

Except that integer overflow vulnerabilities are common and problematic, and occur with 64-bit integer types. Saying that 64 bits is enough for any application is kind of like saying that 640k is enough RAM for any application. If you want to use integer arithmetic, use the integers -- which means arbitrary width, or else an exception being thrown if you try to represent an integer that is too big.

"for the few remaining with specialized needs (you know who you are, cryptographers and mathematicians), arbitrary precision libraries are readily available."

Having code that does not do unexpected things is not exactly a "specialized need." It is pretty easy for a programmer to forget that the sum of two positive numbers could actually be negative, or that the product of two positive numbers could be positive but less than the two factors. Most people think of integer arithmetic in terms of integers, not two's complement, even when they are programming in a language with fixed-width arithmetic -- and it takes extra mental effort to remember that you are not really dealing with integers (mental effort that could be used for other things).

Sure, you can use a library -- but then you need to be explicit about wanting arbitrary precision, and you don't get any automatic optimization from your compiler (e.g. if your compiler can prove that some value will always be in a particular range, it might remove an arbitrary precision operation and replace it with a fixed-width operation without creating a risk of an overflow).

"The default string type is std::string"

Unless you declare a string constant, in which case you get a pointer to an array of characters. C++11 conveniently adds yet another way to get a pointer to an array of characters, "raw" string literals (at least it is appropriately named), on top of the typical double-quoted string and the C++03 wide-character string literal notation.

Even with std::string, bounds checking is not guaranteed. operator[] won't check bounds. String iterators can be incremented past the bounds of the string without any exceptions being thrown. You can even try to dereference the placeholder iterator returned by string::end(), with conveniently undefined behavior (would any definition actually make sense for some application or platform?). You have at(), of course, which will do bounds checking but which breaks the [] syntax you get with C-style strings, arrays, maps, and other types (at least you have the same interface as std::vector, which might be useful).

This is the sort of brittleness that characterizes C++ and that makes reliable code hard to write. Everything looks great, until you step over the poorly-indicated boundary that separates "good for C++" and "you'll regret this later."

Smart pointers, Boost, rvalue references and move constructors is exactly the things that obscure the hell out of the code, frequently making it incomprehensible to anyone but the author. Crashing on a dereferenced NULL pointer is peanuts compared to clusterf#ck of logic that stems from a mess in the dev's head. C++ is less safe because its adepts, on average, are sloppier and messier than those who favor other languages (C included).

Really? I am pretty sure there are a large number of STL implementations that give you a pointer when you ask for a vector iterator. I suppose you could avoid iterating on vectors, but you would also have to avoid operator[] (which by default performs no bounds checking, so the pointer arithmetic is just as unsafe as it would have been with a primitive array type); you'd be stuck with at(), which few compilers will optimize even if it could be shown that the index will never be out of bounds.

"That cuts out a large number of potential problems"

Yet the language encourages programmers to do things the unsafe way. It is a lot less effort to use a low-level pointer type, a fixed-width integer type, etc. than to use smart pointers, STL containers, iterators, Boost (which is not even standard), and so forth. Just as an example, a C++ programmer must first choose between multiple smart pointer types (where should you break your pointer cycle with a weak_ptr?), whereas a primitive pointer is easily accessible and requires no decision-making (this was the pattern with casting: C-style casts are much more convenient than static_cast, dynamic_cast, or const_cast, and so you saw C-style casts being used all over the place). While a Java or Python programmer on a tight deadline might produce slow code, a C++ programmer will produce unsafe code that is far more likely to have bugs (even if the high-level design is bug-free).

Definitely.

> And the runtimes qualify as important software in their own right, simply because they inherit from the importance of all the software that runs on them written in other languages.

Also agreed.

The only thing I'm trying to disprove is the thesis that "basically" no important software is written in languages other than C/Cpp.

The two biggest issues are (1) lots of undefined behavior and lots of complicated semantics and (2) the difficulties involved with handling errors.

The undefined behavior is something that Stroustrup justified by pointing to all the undefined behavior in C. This is a poor response in my view, since there are undefined behaviors in C++ that could have been defined without breaking any compatibility with C; for example, the order in which function arguments are evaluated. There are also things that were left unspecified for no apparent reason, such as a non-void function where some control paths have no return statement (which can be disastrous in C++ and can make debugging a giant pain). When the standard cannot even rule out programs that could never be compiled into something sensible, the standard is deficient (especially when most compilers can issue a warning over this sort of things -- so why not just define it as a compile-time error?).

C++ also forces programmers to deal with complicated semantics as the default. It may not seem like a big deal, but it is easy for a programmer to forget that "1/3" is not "one third." It is also easy for a programmer to forget that "x+1" might actually have a value that is less than "x." The problem here is that C++ makes these things the default, citing "performance;" it would be far better if the default were arbitrary-width types, smart pointer/smart array types, and other high-level types, with low-level types like "32-bit integer" or "pointer to a character array" requiring an explicit cast by the programmer. Critical systems have failed because of obscure "corner case" semantics like integer overflows in the past; these also create vulnerabilities in software.

Error handling is a complete mess in C++. Exceptions are OK, but they cannot be thrown from destructors, they should not be thrown from constructors, and there is no way to say, "retry the operation that threw the exception" -- exceptions destroy the entire stack, and so the client code is responsible for knowing how to retry things. If you are in the middle of writing a record to a thumb drive and that thumb drive is removed, what do you do? You cannot simply prompt the user to reinsert the drive, and then have the "OK" button cause the rest of the record to be written (unless the exception is thrown again because the thumb drive is not there), unless you want your IO library to open dialog windows (and so much for encapsulation). That basically makes exceptions no better than checking return values, other than that exceptions are a little faster and cannot be ignored.

The situation with exceptions is so bad that even the C++ standard library requires some errors to just be ignored. The standard IO classes, for example, are required to silently fail if there is an error closing an underlying file when the object is being destroyed. This forces programs to explicitly invoke a member function to close the stream before destroying the object -- so what is the point of having a destructor at all? Destructors have no good way to signal errors: they cannot throw exceptions, they cannot return an error code, and the order in which destructors are called is undefined so they cannot set a global error flag -- so you can only put things in destructors that either never create errors or which can only create errors that are safe to ignore (can you think of any such errors?).

C++11 could have fixed this error handling problem: they could have required that the stack only be unwound after the catch block ends, which would have both solved the destructor exception problem and opened the possibility of Lisp-style "restarts." Unfortunately, the standards committee did nothing of the sort, and instead defined the default behavior of destructor exceptions to be "abort the program." Here I was, thinking that "abort" was something that should only be called under the gravest of circumstances, yet a C++ program might abort because it was unable to write to a log file. Typically, one will hear the argument that exceptions should only be called in "exceptional" situations, which we are meant to think only means situations that are grave enough that "abort" can be called -- yet the standard defines exceptions for errors that can be corrected and for which a program exit is not strictly necessary, like an attempt to write to a full disk (and lest you think that this is no big deal, I have seen people lose over a 24 hours' worth of work because a program exited when the disk was full -- and you definitely would not want a 911 dispatch system to shut down just because it could not write to a log file).

You point to the use of the Linux kernel in critical telecom and financial systems as if it were evidence that the Linux kernel can be relied upon. I see the Linux kernel panic periodically. I doubt you would be happy if your 911 call were dropped because some telecom equipment was suffering a kernel panic. You see Linux in these places because technically better systems are too expensive and there are too few people who know how to configure and use those systems.

If you want to play with straw men, go elsewhere. All you're doing here is wasting everyone's time, including your own.

Libraries are used by app guys -rarely by OS or embedded - unless they are specific to the hardware etc.

I hear the excuse "you can hurt yourself in C++ if not trained". That's true, but not helpful. You can build a house with hand tools too but nobody does any more - they use power tools and professional carpenters, electricians etc.

I've reduced 10,000 lines of C code to a 12-line template. Surely that is a good thing? This is not typical but a good example of high-leverage tools.