I agree up to a point and I'd agree fully if we were comparing Java with
C. But C++ has mechanisms to enable objects to manage the access to and
lifetime of any dynamic memory they use. This levels the playing field
between C++ and Java applications. I's go further and say the ability
to manage any resource type with RAII tips the balance on favour of C++.
Why just under Linux?
Sorry. I didn't want to say just "process" in that context as I
thought it was overly vague, so I picked a random operating system
which has good fault isolation between processes.
Disagree. In my option C++ is no worse than Java in this regard. I
will concede that the developer has to take greater care in C++, but
where fault isolation isn't an issue, not having to care can have its
advantages!
To be clear, I am not making any claims about Java at this point. I am
merely making the claim, to have a robust C++ product on a modern
desktop-like OS, you need to have the fault isolation at the process
level. No comparisons to Java. It's just a simple fact of making
robust C++ applications.
I'd dispute "much". I'd also note that this greater protection from the
language has a cost: the reduction of the utility of the language.
One of the beauties of C++, its multi-paradigm nature means you can
choose to write code in the style of a number of other languages. I
have C++ code that's almost C (device drivers), code that could be
mistaken for Java (my XML libraries implement the Java DOM bindings) and
code that could be mistaken for PHP (my web application libraries). If
an application demands the fault isolation of Java, it can be just as
easily be written in a Java like subset of C++ as it can in Java.
I think it's not quote over empirical fact now. I don't think I'll be
able to convince you, but I don't think you fully get where I'm coming
from, so bear with me.
The question central in this discussion is what to do in the face of a
programming error when detected by a sanity check in the program. In a
"safer" language like Java, it is difficult and unlikely for a
programming error to break the memory subsystem, scramble random bits
of random objects, etc. In fact, Java has many guarantees on this
subject. However, yes, my argument rests on the assumption that the
JVM is correct, which isn't necessarily true, but it seems like a
reasonable enough assertion when compared to most desktop C++ programs
which have their correctness conditional on their operating system,
their "virtual" machine.
You just argued that with care, you can achieve the same benefits of
Java in C++. In some sense, I agree fully. However, my very premise, a
programmer error, contradicts "with great care by the programmer".
We're examining what should we do in the very real and common
occasions where the programmer "was not careful enough". In this case,
Java offers a lot more guarantees about process stability than C++
(conditioned on the correctness of the JVM).
When designing for robustness, one must anticipate that programmers
will not always be careful enough. Designing for robustness is
designing with the expectations of programmer bugs (and more). One
must have fault tolerance. One does this with redundancies, backups,
rollovers, transactions, etc., and most importantly fault isolation.
In this regard, C++ is very different than Java. (Not "better", as I
don't want to go there, just different.)
The very nature of Java, lack of pointer arithmetic, defined and
"sensible" outcomes from race conditions, defined and "sensible"
behavior on null pointer accesses, etc., aka all of its security
features, gives Java a higher degree of fault isolation intra-process
than C++.
Fault isolation by definition is how isolated are separate parts of
your application from faults in other parts of your application. In
Java, it's basically impossible to corrupt the bits of a local stack
object of someone's else's thread which did not have any escaped
references, but it's trivial for that to happen in C++ from a
programmer mistake.
) course, then