bj@hatch.socal.com (Brendan Jones) writes:

>Hmmmm... I usually don't take the flame bait Timur, but you're doused
>yourself with gasoline and dared me... :-)   This isn't personal.
>Rather, you've said some silly things and must be trounced soundly! :-)
>
>(att. Wear asbestos suit before entering.  Wear welding goggles).
>----------------------------------------------------------------------------

Right, I am all suited up and ready to go :-)

> >>C and C++'s power is its flexibility, but that shouldn't stop it
> >>from offering a few safety nets should we ask to work with them.
> >Efficiency is more C/C++'s strong point than flexibility.  Any
> >time a certain behavior (like array bound checking) would result
> >in a possibile waste of CPU cycles, it is not included.
>What would you rather have Timur?  A program that runs right, or a
>buggy program that runs 10% faster?  How many millions of instructions
>a second will computers have to execute before you decide we can spend
>some of those on preventing bugs?

Array bounds checking and NULL pointer checking do _not_ need to be
something that it built into the language (although this would be nice).
C++ does not do this, but you can easily build a C++ template class for
working with arrays for you (resizeable or fixed size arrays). One of the
things that this array class can do, is check for out of bounds array
indexing, which can be done inline. Naturally you can also write the
code so that you can turn on or off this array bounds checking at compile
time, so you can test and debug your code (please ensure you leave this
kind of stuff _ON_ when sending out beta test releases) with the
knowledge that these bugs will be found (believe me, this works. I
frequently find that my programs bomb out with an array bounds error - not
because the code is bad, but because I am still writing it; 5 mintues
later the bug does no exist anymore).

You can also build a template class for working with pointers, to check
for NULL pointer references and using a debugging malloc/free library that
will do extensive testing of the heap when doing memory allocation etc.
NULL pointer checking can also be done at the hardware level on the 386,
and it done so with GCC under 386BSD (I think FreeBSD or NetBSD does it).

All is not lost when going to C/C++, but you must take extra precautions.
Taking that attitude that these bugs do not exists however is ludicrous.
Just look at the number of badly written pieces of code in the world...

+------------------------------------------+-------------------------------+
| Kendall Bennett                          | Internet:                     |
| RMIT Advanced Computer Graphics Centre   | kjb@citri.edu.au              |
| CITRI Building, 723 Swanston Street      | rcskb@minyos.xx.rmit.oz.au    |
| Carlton Victoria 3053 AUSTRALIA.         |                               |
+------------------------------------------+-------------------------------+

Hmmmm... I usually don't take the flame bait Timur, but you're doused
yourself with gasoline and dared me... :-)   This isn't personal.
Rather, you've said some silly things and must be trounced soundly! :-)

(att. Wear asbestos suit before entering.  Wear welding goggles).
----------------------------------------------------------------------------

 >Brendan Jones <bj@hatch.socal.com> wrote:
 >>  1. array indexes straying out of bounds
 >>  2. stray or null pointers
 >>There must be tens of thousands of people who have wasted hundreds
 >>of hours each hunting these type of bugs down.  Think of all the
 >>wasted time that adds up to!  It's about time the C++ language
 >>specification was amended so these, the most common bugs, can
 >>be trapped.

 To which Timur responded:
 >From: timur@seas.gwu.edu (Timur Tabi)
 >The C language was designed for people who know what they're doing
 >when they program.  It doesn't check array bounds because that
 >takes time.  It is the responsibility of the programmer to make
 >sure that his code is correct.  Advanced debuggers, linters,
 >and similar tools can be used to track down these kinds of bugs.

 What a tub of hogwash!  Timur, have you ever worked in the real world?

 Software that is running in the real world has to run *right.*  A bug can
 cost a company thousands upon thousands of dollars.  This can take the
 form of money going astray as your program moves it around, money that
 isn't there being "created", not to mention million dollar satellites
 spinning off into space and missing planets (ever heard of Mariner?).
 It also means application downtime while you track your bug...  A
 little dramatic reading to make the point:

 Joe: What the hell is going on down there!!! I have a six million dollar
      tender due in in forty minutes!!!  I can't get anything out of your
      system.  Do you know how much this is going to cost our company?
 Sam: Sorry Joe, but we're trying to track down an application bug.
      Probably nothing big; a stray pointer, array index out of down.
      Shouldn't take long to fix when we find it...
 Joe: HOW LONG IS THAT GOING TO TAKE!?
 Sam: Oohh... I don't know; these things take time; It could take five
      minutes.  It could take a week.  Bugs can be tricky to isolate,
      but we have "advanced debuggers" that can help us... Just think,
      it might only take days instead of weeks!
 Joe: WHAT KIND OF HALF-ASSED CODE DO YOU GUYS WRITE DOWN THERE!?
 Sam: Fast Joe, Fast...  You see, we believe that efficiency should
      take a higher priority than quality.  Take array checking for example.
      Timur found out we can save 10 CPU cycles per array access by
      not using a BOUND instruction.  Why, that must save nearly
      five milliseconds over your average transaction...

 Exercise for the reader.  Does Joe reply:
      1. Well, I don't mind losing the odd tender if my transactions can
         execute in 1.9 seconds instead of 2.0!
 or   2. YOU'RE FIRED!  YOU'LL NEVER WORK IN THIS TOWN AGAIN!


 When I write code, I want that code to run right, first time.  I don't
 have time to chase stupid bugs the compiler could pick out for me.
 Bugs cost time, money... and even lives.  Timur, you say it is the
 program responsbility to "make sure his code is correct".  I guess
 all your programs must carry the label "certified 100% bug free"?

 >Don't flame C for being exactly what it is designed to be.  If you
 >don't like it, then go ahead and use Pascal and watch your software
 >run at half speed.
(1) Since when does Pascal run half the speed of C?  Ever heard of an
optimizer?  Do you really think C is inherrently faster?  Have you
ever looked at unoptimized C output?  More to the point, have you ever
used a computer? ;-).  (2)  C++ goes a long way towards fixing up the
bug affinity of C.  Sure, when I was in Uni I loved hunting bugs in
C code, but aren't there better ways to spend your time?  (Wasting
time taking the bait on Internet posts for example? :-)  Other reasons:
C++ has become an industry standard, and for the most part I find it
a good programming environment, but it can be better... Much better.
When C++ is good it is very very good, and when it is bad it is awful.

 >In the meantime, real programmers (like me :-)
 >will be happy using a computer language that doesn't restrict us
 >unnecessarily.
... Doesn't restrict you from making bugs?

Actually, this argument bothers me.  When software developers complain
about bug-prone programming languages, people like Timur jump up and
say "poor poor baby; obviously you aren't a real programmer... I
can handle it... Why can't you?  Is it too hard for you?"   No Timur,
it's actually because we take pride in our work.  >:-(

 >>C and C++'s power is its flexibility, but that shouldn't stop it
 >>from offering a few safety nets should we ask to work with them.
 >Efficiency is more C/C++'s strong point than flexibility.  Any
 >time a certain behavior (like array bound checking) would result
 >in a possibile waste of CPU cycles, it is not included.
What would you rather have Timur?  A program that runs right, or a
buggy program that runs 10% faster?  How many millions of instructions
a second will computers have to execute before you decide we can spend
some of those on preventing bugs?

 >C is not for the timid.
I hope they never let you program a life support system.

 >------------------------------------------------------------------ Timur Tabi
 >Contributing Editor for "OS/2 Monthly"        Internet:    timur@seas.gwu.edu
 >Maintainer of the DOS-OS/2 Games List         Fidonet: Timur Tabi @ 1:109/347
 >                                              Bitnet:            if402c@gwuvm
I use OS/2.  How reassuring! ;-)

cheers,
Brendan Jones.