Re: The great Java showcase (re: 2nd historic mistake)

[Laurent Guerby <Laurent.Guerby@enst-bretagne.fr>]

doylep@ecf.toronto.edu (Patrick Doyle) writes:
> > [...]
>   That's a pretty cheap shot, Robert.  Plus, it's not necessarily
> true.  There are applications that just beg for automatic memory
> management, and if they happend upon one of these, they certainly
> could have seen such an improvement.
> 
>   For my part, I'd guess that at least 40 to 50% of my time is
> spent looking for memory allocation bugs in C++.
> [...]

   Ada has the ability to manipulate unconstrained objects (something
like returning dynamic sized objects/arrays) without requiring user
heap management. The greatly obviates the need for user
allocation/deallocation, you can write very large Ada programs without
doing fine grained heap management (and I agree with you, very error
prone unless you're some kind of programming deity ;-).

   When doing graph/tree stuff, you'll often see a big dynamically
allocated array behind the scene in Ada programs, reallocated when
there's not enough room, a good example of this is GNAT (see the
generic unit table in the sources).

   It is an area where language matters, by allowing stack (the Ada
compiler may use dymaic allocation behind your back, but I guess most
modern Ada technologies use a secondary stack) allocated complex
dynamic types (Ada case) or by providing garbage collection (Java).

   I've seen high level translation to Ada of C++ API, which
originately required the user to worry a lot about heap management
(conventions C1, C2, ... C6, that kind of stuff), giving an Ada
version without any heap management (discrimated types and
unconstrained arrays doing the job). Needless to say, bye bye the "40%
to 50% of the time" chasing heap problems ;-).


-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."