🚀 go-pugleaf

Viet-Trung Luu (vluu@lagrange.uwaterloo.ca) wrote:

>Well, the cost for checking in C/C++ programs shouldn't be much more than
>for programs written in other languages. Is that an indication of how 
>slow other languages are or are you saying that C/C++ programs are 
>unchecked because those who use C/C++ want small fast programs?

Umm ... do you have any timing tests that support these assertions?
I suspect not.  There seems to be a widespread belief that, just
because C is close to assembly language, it will give you small 
fast programs.  It doesn't seem to work out that way in practice.
With the compilers I use, Modula-2 programs with all run-time
checking enabled tend to be smaller and faster than the equivalent
C programs with no run-time checking.  And, in most implementations,
C++ programs are even bulkier and slower than C programs.

>(Obviously, it is more difficult and thus "costly" to check C/C++ 
>programs, but not so much more than for other languages. I guess most of 
>the cost is due to the freedom that C/C++ allow.)

"Not so much more" - I very much doubt this.  To take a simple
example: one very common programming error in C is letting a
pointer run off the end of an array.  Think of how tricky it would
be to test for that error at run-time.  In just about any
high-level language, you can check for a subscript range error
in one or two machine instructions.

Somebody once said that the price of freedom is eternal vigilance.
C is one language that really _needs_ strong run-time checking,
because of the number of common errors that high-level language
compilers catch at compile time but which in C can't be detected
until run time.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           file://ee.newcastle.edu.au/pub/www/Moylan.html