M
Martin Gregorie
This had nothing to do with Ada per se and everything to do withAnd don't forget Ariane 5
shortcuts:
- re-use of an Ariane 4 component without changing its parameters
to match the Ariane 5 flight profile
- not removing Ariane 4-only code intended to handle launch holds
and not used at all in Ariane 5
- a programming fault that allowed an exception code to be sent
to another component as if it was valid data.
Inadequate testing allowed all these to be flown without finding the
errors.
Bottom line: All this would still have happened regardless of the
programming language used. However, don't just listen to me: read the
final report on Ariane 501 here:
http://www.di.unito.it/~damiani/ariane5rep.html
S
sturlamolden
I am quite sure C and Fortran makes it unlikely for an unhandled
exception to trigger the autodestruct sequence. But it's nice to know
when flying that modern avionics is programmed in a language where
this is possible.
M
Mark Lawrence
Haven't been able to read this properly as the stomach has been shaking
too much to control the mouse and/or arrow keys/page up/down etc. Hum,
marks out of 10, 1.649072354865927**trillions. For the cryptographers,
is this a decent random number?
Kindest regards.
Mark Lawrence
M
Mark Lawrence
A bug is a bug is a bug?
Except in my code. Never written a bug in my life. Cross my heart and
hope to die. Of course I'm lying.
Kindest regards.
Mark Lawrence.
S
sturlamolden
According to Grace Hopper, a bug might be a moth, in which case the
best debugger is a pair of forceps.
C
Carey Tilden
Perl is written in C++. That is not enough to make me want to use
it
I realize this was meant to be funny, but it's not true, and detracts
from the point you were trying to make. Maybe skip the pointless jabs
at Perl and stick to things you know more about.
P
Peter
I used to work for defence contractors - Ada (IMO
) is the verybest OO language for real-time and embedded systems. It scales
fantastically well to large, multi-platform jobs as well. If I had my
way we would use it where I work now (biomedical field) but that isn't
an option - too many folk are brought up on a steady diet of C/C++ and
therefore don't know any better, plus there is a dearth of Ada
compilers for the CPU's that we use here (all embedded work). I have
used fortran, C, C++, some Java, Ada (and Python
), if I had mychoice for the type of programming I do here at work, it would
definitely go to Ada by a country mile.
Having said that though, I won't replace Python with it on my desktop
for the type of stuff I do around the fringes of my job (test scripts
etc) and my personal programming
But for anyone who wants to expand their horizons, learning Ada would
be an excellent choice (although like any learning activity, unless
you have a concrete goal in mind you will probably just waste your
time
). It is not an easy language to just pick up and run withbecause the strong type-checking FORCES you to think about and design
your program very carefully from the very beginning - something that
many programmers find an abhorrence for
But I always used to tellpeople - by the time I got a program to compile then I figured 99% of
the bugs were already discovered! Try that with C/C++ or almost any
other language you care to name
Peter
P
Paul Rubin
sturlamolden said:
The earliest Ada compilers were terrible, but they are about like C
compilers now, so the output code is ok (see Alioth shootout for
example). I agree about the verbosity but I don't think that's too big
a problem in the sorts of systems that need to be written in such
languages.
And don't forget Ariane 5
I have looked into that a few times and I do wonder whether the language
or release process could have been of any help. One possibility is
using something like SPARK to ensure the absence of overflow exceptions.
Another is automatic test generation something like
http://www.stanford.edu/~engler/klee-osdi-2008.pdf
but that approach was probably unknown at the time.
R
Roy Smith
sturlamolden said:
To be fair, there were usable C++ compilers before there were usable STL
implementations. Thus, it should not be surprising to find older C++
code bases eschewing the use of STL. That's not to say that this trend
should be propagated in current educational material.
This one I don't understand. Yes, I get RAII, but surely there are
valid reasons to allocate memory outside of constructors. Containers
which resize themselves (such as std::vector) are one obvious example.
R
Roy Smith
[email protected] (Aahz) said:
The same story has been floating around for eons, just with the names
changed. I saw one where Wirth was ostensibly making fun of the people
who didn't understand that Pascal was all just a joke.
I'm sure if you go back far enough, you can find a McCarthy / Lisp
version. It probably goes something like, "So, anyway, we tried to
figure out what was the most absurd way to abuse punctuation we could
imagine. Somebody suggested that every program would have to end with
37 close parentheses. When we finally stopped laughing, we started
sketching out a grammar on the chalkboard that would let us do that".
S
sturlamolden
That is because an exception might skip an arbitrarily placed delete[]
or std::fclose when it rewinds the stack, so to avoid resource leaks
they must be places inside a destructor of an object on the stack
(which will be called).
This is unsafe, anyone who writes this in C++ should be flogged:
void foobar()
{
std::FILE *fid = fopen("whatever");
// some code here
std::fclose(fid);
}
This idiom is safer :
struct File {
std::FILE *fid;
File(const char *name) {
// acquire resource in constructor
fid = std::fopen(name);
if (!fid) throw some_exception;
}
~File() {
// free resource in destructor
if(fid) std::flose(fid);
}
};
void foobar()
{
File file("whatever");
// some code here
}
It is for the very same reason we should use std::vector instead of
new[] for arrays. It is why new and delete should only be used inside
constructors/destructors. It also why C++ has references in addition
to pointers.
Which means this is bad in C++, as new and delete is arbitrarily
placed:
void foobar()
{
File *myfile = new File("whatever);
// some code here
delete myfile;
}
An object should go on the stack, because if an exception is thrown,
we need the destructor call. Which is why this (as shown above) is
ok:
void foobar()
{
File file("whatever");
// some code here
}
This is the kind of gotchas that allows C++ to shoot your leg off.
In comparison C is much more forgiving, because there is no exceptions
(unless you use setjmp/longjmp). This is ok in C, but not in C++:
void foobar()
{
FILE *fid = fopen("whatever");
// some code here
fclose(fid);
}
For the same reason we can place malloc and free wherever we like in C
code. But in C++ we must restrict std::malloc and std::free (as well
as new and delete) to constructor and destructor pairs.
This kind of design is mandatory to make safe C++ programs. But it is
not enforced by the compiler. And since the majority of C++
programmers don't obey by these rules, Java and C# tends to produce
far less runtime errors and memory/resource leaks. And C++ textbooks
tends to avoid teaching these important details. I'm inclined to
believe it is because the authors don't understand it themselves.
Objects on the stack are also required for operator overloading in C+
+. A common novice mistake is this:
std::vector<double> *myvec = new std::vector<double>(10);
myvec[5] = 10.0; // why does the compiler complain?????
And then the novice will spend hours contemplating why the stupid
compiler claims the type of myvec[5] is std::vector<double>. There was
recently a post to the Cython mailing list claiming there is a bug in
Cython's auto-generated C++ because of this. But this is how it should
be:
std::vector<double> myvec(10);
myvec[5] = 10.0; // ok
And now we see why C++ has references, as that is how we can
efficiently reference and object on the stack without getting the
operator overloading problem above.
C++ is good, but most programmers are better off with C. It has fewer
gotchas. And if we need OOP, we have Python...
Sturla
S
sturlamolden
And since this is comp.lang.python, I'll add in that this sometimes
applies to Python as well. Python, like C++, can have the call stack
rewinded by an exception. If we call some raw OS resource allocation,
e.g. malloc or fopen using ctypes, we have to place a deallocation in
__del__ (and make sure the object is newer put in a reference cycle).
The safer option, however, is to use a C extension object, which is
guaranteed to have the destructor called (that is, __dealloc__ when
using Cython or Pyrex).
If we place raw resource allocation arbitrarily in Python code, it is
just as bad as in C++. But in Python, programmers avoid this trap by
mostly never allocating raw OS resources from within Python code. E.g.
Python's file object is programmed to close itself on garbage
collection, unlike a pointer retured from fopen using ctypes.
Sturla
R
Roy Smith
sturlamolden said:
Well, OK, but there's still nothing wrong with allocating memory outside
of constructors, as long as you make sure the destructor cleans it up.
Or you have made some other arrangements to make sure it's cleaned up
(try/catch, auto_pointer, etc).
A
Aahz
Actually, with Python 2.6 or later, the Pythonic solution is to use
``with``.
N
Nobody
But I always used to tell
people - by the time I got a program to compile then I figured 99% of
the bugs were already discovered! Try that with C/C++ or almost any
other language you care to name
ML and Haskell are also quite good for this (although I wish they
supported integer subranges). Also, the statelessness of FP eliminates
entire classes of bugs.
N
Nobody
One feature which can't readily be implemented in C is the automatic
clean-up side of the RAII idiom.
C
Chris Rebert
That's not directly related to object-orientation though.
Cheers,
Chris
J
James Mills
C is a Turing-Complete Language is it not ?
If so, therefore is it not true "anything" can be implemented ?
Even the "automated clean-up side of the RAIL idiom" ?
cheers
James