Re: next "big" language?? (disagree)

[dweller@dfw.net (David Weller)]

In article <4pj7e0$fat@goanna.cs.rmit.EDU.AU>,
++           robin <rav@goanna.cs.rmit.EDU.AU> wrote:
>---One of the problems of using rigid facilities -- amply
>illustrates my point.  Arrays don't often have fixed sizes.
>The size depends on the problem.  One day, it might be 10,
>next day, 300, day after, 90.
>
>   Are you seriusly suggesting that EACH time the program
>is run that it be edited and recompiled?  And what
>happens -- as is often the case -- the size of the array
>changes DURING the run?

If this is your belief, then you are SERIOUSLY missing the point.

If you have software where the array size MIGHT change, then you write
your software to support that.  You MIGHT decide to make the array
size a constant and recompile when needed (it's a valid choice,
although not one I'd make), you also MIGHT allow your array to grow as
more things are added to it.  These things are easy to handle.

The point of the discussion, however, was situations where you indexed
outside an array, which is so damn easy in C that EVERY book I've seen
in C says, "be careful not to do this!"

There is a VERY considerable difference between adding something to an
array in a manner such that the array size grows with the addition,
and indexing outside an array, such that you're now lost in the middle
of memory-land and can't figure out why your program gives (most
likely) unrepeatable errors.

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada