Re: Some errors in MIT's intro C++ course
"Joshua Maurice" <joshuamaurice@gmail.com>
Ok. I guess we disagree on facts. I believe that a misbehaving Java
library cannot mess up the process as easily as a misbehaving C++
library. The C++ library could trash the entire memory subsystem with
a single bad line of code, which under certain coding styles is quite
easy to make. A race condition with the status quo or with the
upcoming standard. However, short of maliciousness, Java doesn't have
these problems. It's still possible that a bug in a library borks your
whole program, but the odds seem to be a lot less. It can't
inadvertently trash the memory subsystem, or cause a seg fault from a
race condition, etc.
<<
Facts ot opinion?
Race condition was undeined behavior at least in java 1.2 as I last read --
doubt that changed. And a *practical* java program will crash easily just
by doing resource allocation.
Not corruping memory so easily is true -- but java has no notion of passing
objects by value/const ref -- so the objects sit there unprotected to state
altering effects. How you calculate a "chance" of what harm the effect of
a bug can be? Please admit you really can not.
The exception handler at upper level si hardly any wiser than the designer
and design translator who already was proven wrong by the Assert violation
triggered.
And we didn't even talk about java programs extending boundaries -- how many
use JNI, CORBA or orther RPC calls, etc. Or systems that will interpret
data written to certain named files as device request.
Of course, it's all a matter of degree. Process boundaries are only
good to a degree. Separate physical hardware gives better fault
isolation than separate processes under Linux. In the end, as you say,
good design is required.
In the beginning. So what we're talking about? Why twist the mud? State
can be correct/incorrect/unknown. discoveruing violation puts you where?
After that, it all depends. Perhaps your
particulars require dumping core when your Java process hits a
programmer bug. I'm not in a position to comment on your design goals,
how good your fault isolation in the Java process is, etc. For
example, a misbehaving Java library could still make calls into other
libraries, which might trash the program. It's a judgment call as to
the proper response.
Judgement indeed. Was just reading about launch of game 'Elemental war of
magic'. That was craching all over and impossible to play -- yet the CEO
judged it is okay the way it is, and glad the paying customers sent in all
those bug reports promptly. The approach makes me want to puke.
I just wanted to make the observations:
1- Fault tolerance requires fault isolation.
2- Generally one cannot reliably isolate faults inside of a C++
process. Fault isolation must be at the process level for C++.
provided the system sandboxes the process -- and the process concept apply
in the first place...
After some replies, I made one final claim:
3- It's much easier to get more reliable fault isolation inside of a
single process in other languages, like Java, as opposed to C++.
You meant to say, it is way easier elude yourself to think that true, just
because other languages have less UB and no trivial means to corrupt memory
like buffer overrun or access free-d object.
But it is just delusion -- as despite java manages object memory chunk's
lifetime, designing the life of object has all the same obligations on the
designer and the coder -- and messing it up is exactly that easy.
Resulting in corruption too, only it manifests differently.
And I definitely don't mean to get into a language dick waving
contest. I am just noting that fault isolation does not necessarily
need to be at the process level. it depends on the particulars.
Well, guess if a program have no state at all, and you restrict to ceratin
operations -- i.e your ptogram just calcualtes digits for pi, you can draw
the line elsewhere. Normal programs that are subject to 'development' and
worth discussion are hardly that limited ever.