Re: Some errors in MIT's intro C++ course
"Joshua Maurice" <joshuamaurice@gmail.com>
One as you noted (and as I noted earlier), the correctness of such a
system is conditional on the correctness of the C++ library /
framework or the (J)VM. I suspect that the sun JVM is much more tested
and reliable than your C++ library / framework. As such, when
evaluating the robustness of such designs, I would be more concerned
about the correctness of your C++ library / framework as opposed to
the JVM, enough so that I would consider it more "required" to use
separate processes for the C++ application.
This sound like a religious comment instead of a technical one.
JVM is one helluva complex program. And is written using possibly the very
same C++ library/framework we use. (And executes on top of another pretty
complex system too...)
Also I see countless releases of the JVM rolling out. Ways more than C++
compilers and especially C++ libs/frameworks. With fat list of problems
fixed every week. And people using java around tend to swear a lot, on
broken stuff or that have different results on different builds.
My estimates show more effort put in C++ compilers and libs timely; more
time passed to evolve; and the complexity is just a fragment. So how come
your figure of the latter shall be less bug-ridden?
For those that do, the coding
standards for the application can enforce them.
Code review, application coding standards, etc., collectively
programmer care, can only go so far. Enforcement by the compiler and
runtime as an automated process is far more reliable and robust. I
disagree with your implicit assertion that coding standards are a
perfectly equivalent substitute for compiler enforcement on things
such as type safety.
Sure, auto tools, like a compiler does a good job -- in its scope. Too bad
it is way too limited in the engineering realm.
I snipped the portion where yo stated that java makes "sensible" things for
some common problems, like race conditions. This is just a great delusion.
Indeed, from 1.5 the memory model changed, and race is no longer said
explicitly UB in the langspec. But what you get instead? For *practice*
all the same problems.
Java can go no further than stating the a 'correctly synchronized' program
will show a correctly sequenced execution. While if you have data race,
you will mess up the program state all the same. Calling it 'unexpectd' or
'unintuitive' instead of 'undefined' will not help that much. And the
compiler will not provide a great help -- it is the designer's job to have
corrext synchron and eliminate data races.
Yes, having UB in a program is bad. But if you substitute UB cases to some
stock defined behavior that does not match that what *expected* by the
programmer, you still have no correct thing, and the results can be almost
as disastrous. Somewhat less on one end due to more contained impact,
but somewhat more due to this kind of common false sense of security.
The compiler is good to pick up typos, but really the correct design, design
reviews and code reiews are the tools that make it possible to come up with
actually working stuff.
Simplest example, an uninitialized int is UB in C++, and well defined 0 in
java. If you wanted to set it to a particular value but missed some case in
the if/switch, how the compiler/runtime helps you? ( Actually for C++ you
have a fair chance to gain a compiler warning with optimized build, or a
flag from valgrind; certainly if you did set the value just a wrong one,
you're left to tests and code review. )