memory management and productivity

memory management and productivity

[Russ]

The following is an excerpt from an article featured on Slashdot today
(6/16/04). The excerpted paragraph is not even the main topic of the
article, but it made wonder what chance Ada has in the future without
automatic memory management. It seems to me that garbage collection
should be optional within the language.

excerpt from http://www.joelonsoftware.com/articles/APIWar.html

How Microsoft Lost the API War
By Joel Spolsky

...

A lot of us thought in the 1990s that the big battle would be between
procedural and object oriented programming, and we thought that object
oriented programming would provide a big boost in programmer
productivity. I thought that, too. Some people still think that. It
turns out we were wrong. Object oriented programming is handy dandy,
but it's not really the productivity booster that was promised. The
real significant productivity advance we've had in programming has
been from languages which manage memory for you automatically. It can
be with reference counting or garbage collection; it can be Java,
Lisp, Visual Basic (even 1.0), Smalltalk, or any of a number of
scripting languages. If your programming language allows you to grab a
chunk of memory without thinking about how it's going to be released
when you're done with it, you're using a managed-memory language, and
you are going to be much more efficient than someone using a language
in which you have to explicitly manage memory. Whenever you hear
someone bragging about how productive their language is, they're
probably getting most of that productivity from the automated memory
management, even if they misattribute it.

Re: memory management and productivity

[tmoran]

>If your programming language allows you to grab a
>chunk of memory without thinking about how it's going to be released
>when you're done with it, you're using a managed-memory language, and
>you are going to be much more efficient than someone using a language
>in which you have to explicitly manage memory.
   I guess Ada is a managed-memory language then, since I normally
grab a chunk of memory without thinking about how it's going to be
released.  In fact I don't even think about whether the compiler might
actually be doing a heap allocation with hidden pointer, or doing the
stack allocation that appears to be happening.  And when I use a
Controlled type from some library, I let its Finalize do any memory
worrying that's needed.  Only on rare occasions do I explicitly
do a "new" and have to remember to do a "Free".
   But I sincerely doubt anyway that memory management is the proverbial
silver bullet.  Yes, it's faster, as well as less buggy, to program in
Ada, but it's still not a snap.

Re: memory management and productivity

[Martin Dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0406162056.334745ed@posting.google.com...
> The following is an excerpt from an article featured on Slashdot today
> (6/16/04). The excerpted paragraph is not even the main topic of the
> article, but it made wonder what chance Ada has in the future without
> automatic memory management. It seems to me that garbage collection
> should be optional within the language.

You will be delighted to here that Ada already supports GC thought the
use of Controlled types then. And if that weren't enough you can grap
"Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/.

Cheers

-- Martin

Re: memory management and productivity

[Russ]

"Martin Dowie" <martin.dowie@baesystems.com> wrote in message news:<40d15023$1_1@baen1673807.greenlnk.net>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0406162056.334745ed@posting.google.com...
> > The following is an excerpt from an article featured on Slashdot today
> > (6/16/04). The excerpted paragraph is not even the main topic of the
> > article, but it made wonder what chance Ada has in the future without
> > automatic memory management. It seems to me that garbage collection
> > should be optional within the language.
> 
> You will be delighted to here that Ada already supports GC thought the
> use of Controlled types then. And if that weren't enough you can grap
> "Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/.

I am indeed delighted to hear that. And if Ada really has automatic
memory management capabilities, more people need to know it.

However, I am curious about why initialize and finalize are different
and better than constructors and destructors in C++.

Re: memory management and productivity

[Martin Dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0406181510.37b8f5e2@posting.google.com...
> > You will be delighted to here that Ada already supports GC thought the
> > use of Controlled types then. And if that weren't enough you can grap
> > "Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/.
>
> I am indeed delighted to hear that. And if Ada really has automatic
> memory management capabilities, more people need to know it.

Hopefully this thread will breath the life of publicity to this package then
:-)


> However, I am curious about why initialize and finalize are different
> and better than constructors and destructors in C++.

I never made such a claim.

Cheers

-- Martin

Re: memory management and productivity

[Russ]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<cb0vjl$8hp$1@sparta.btinternet.com>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0406181510.37b8f5e2@posting.google.com...
> > > You will be delighted to here that Ada already supports GC thought the
> > > use of Controlled types then. And if that weren't enough you can grap
> > > "Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/.
> >
> > I am indeed delighted to hear that. And if Ada really has automatic
> > memory management capabilities, more people need to know it.
> 
> Hopefully this thread will breath the life of publicity to this package then
> :-)
> 
> 
> > However, I am curious about why initialize and finalize are different
> > and better than constructors and destructors in C++.
> 
> I never made such a claim.

Well, if initialize and finalize are fundamentally no different than
constructors and destructors, then I conclude that Ada does not have
automated memory management any more than C++ has it. (I may be a bit
slow, but I catch on eventually.)

As for using a library that has memory management built in, that
sounds great. I'd just feel a bit better about it if it were in a
standard library that everyone agrees on and comes with the language,
like STL in C++. Then you could honestly say that Ada has automated
memory management built in. (And it would be better than Java's
because it would be optional.)

Re: memory management and productivity

[Jano]

Russ wrote:
> "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<cb0vjl$8hp$1@sparta.btinternet.com>...
> 
>>"Russ" <18k11tm001@sneakemail.com> wrote in message
>>news:bebbba07.0406181510.37b8f5e2@posting.google.com...
>>
>>>>You will be delighted to here that Ada already supports GC thought the
>>>>use of Controlled types then. And if that weren't enough you can grap
>>>>"Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/.
>>>
>>>I am indeed delighted to hear that. And if Ada really has automatic
>>>memory management capabilities, more people need to know it.
>>
>>Hopefully this thread will breath the life of publicity to this package then
>>:-)
>>
>>
>>
>>>However, I am curious about why initialize and finalize are different
>>>and better than constructors and destructors in C++.
>>
>>I never made such a claim.
> 
> 
> Well, if initialize and finalize are fundamentally no different than
> constructors and destructors, then I conclude that Ada does not have
> automated memory management any more than C++ has it. (I may be a bit
> slow, but I catch on eventually.)

It's been so many time since I did C++ that I may be wrong, correct me 
in that case.

IIRC, in C++ you must destroy (delete?) the object to get the destructor 
called. So, even if you have a carefully built chain of destructors, if 
at some point you forget to destroy the root, you're leaking.

In Ada, when an object goes out of scope (assuming it has been created 
in the stack and not with the "new" operator), it's automatically 
finished so you have one less thing to care about.

Re: memory management and productivity

[Martin Dowie]

"Jano" <notelacreas@porfavor.no> wrote in message
news:2jnh22F12nvieU2@uni-berlin.de...
> It's been so many time since I did C++ that I may be wrong, correct me
> in that case.
>
> IIRC, in C++ you must destroy (delete?) the object to get the destructor
> called. So, even if you have a carefully built chain of destructors, if
> at some point you forget to destroy the root, you're leaking.
>
> In Ada, when an object goes out of scope (assuming it has been created
> in the stack and not with the "new" operator), it's automatically
> finished so you have one less thing to care about.

Not quite true! Try this...

BTW Jano - are you ever going to make that announcement in cla? ;-)

with Ada.Finalization;
package Foo is

   type Bar is private;

   type Handle    is access all      Bar;
   type Reference is access constant Bar;

   function Default return Bar;

private

   type Bar is new Ada.Finalization.Controlled with null record;

   procedure Initialize (B : in out Bar);
   procedure Finalize   (B : in out Bar);

end Foo;

with Ada.Text_IO; use Ada.Text_IO;
package body Foo is

   function Default return Bar is
   begin
      return (Ada.Finalization.Controlled with null record);
   end Default;

   procedure Finalize (B : in out Bar) is
   begin
      Put_Line ("Finalize");
   end Finalize;

   procedure Initialize (B : in out Bar) is
   begin
      Put_Line ("Initialize");
   end Initialize;

end Foo;

with Ada.Text_IO; use Ada.Text_IO;
with Foo;
procedure Wibble is
   B :          Foo.Handle    := new Foo.Bar;
   C : constant Foo.Reference := new Foo.Bar'(Foo.Default);
begin
   Put_Line ("Wibble");
end Wibble;

Re: memory management and productivity

[Jano]

Martin Dowie wrote:

> "Jano" <notelacreas@porfavor.no> wrote in message
> news:2jnh22F12nvieU2@uni-berlin.de...
> 
>>It's been so many time since I did C++ that I may be wrong, correct me
>>in that case.
>>
>>IIRC, in C++ you must destroy (delete?) the object to get the destructor
>>called. So, even if you have a carefully built chain of destructors, if
>>at some point you forget to destroy the root, you're leaking.
>>
>>In Ada, when an object goes out of scope (assuming it has been created
>>in the stack and not with the "new" operator), it's automatically
>>finished so you have one less thing to care about.
> 

I want to add that you also don't need to explicitly destroy object 
members, of course, since Finalize is called on them automagically...

> Not quite true! Try this...

I get this:

Initialize
Finalize
Finalize
Wibble
Finalize
Finalize

and I'm impressed because I didn't knew these differences. I must 
however admit that I don't understand exactly what's happening and gvd 
sigfaults on me (w2000). Could you provide a short explanation please?

> BTW Jano - are you ever going to make that announcement in cla? ;-)

For the next release... if I get time to do it ;)

Re: memory management and productivity

[Martin Dowie]

"Jano" <notelacreas@porfavor.no> wrote in message
news:2jnk5nF12uei1U1@uni-berlin.de...
> > Not quite true! Try this...
>
> I get this:
>
> Initialize -- Initialize B
> Finalize  -- Finalize temporary (in ObjectAda you only get one of these...
> Finalize  -- Finalize temporary  ...two temporaries on assignment)
> Wibble
> Finalize  -- Finalize C
> Finalize  -- Finalize B

Not you don't get a call to Initialize on an assignment to
an "access constant" as you have to assign a value anyway.

Cheers

-- Martin

Re: memory management and productivity

[Brian May]

>>>>> "Martin" == Martin Dowie <martin.dowie@baesystems.com> writes:

    Martin> Not quite true! Try this...

I think the finalize routine doesn't get called because the variable
drops out of scope, it only gets finalized when the program exits.

So you can't rely on this behavior unless your program was going to
exit anyway.

eg. change the Wibble function to:

--- cut ---
with Ada.Text_IO; use Ada.Text_IO;
with Foo;
procedure Wibble is
   procedure Wobble is
      B :          Foo.Handle    := new Foo.Bar;
      C : constant Foo.Reference := new Foo.Bar'(Foo.Default);
   begin
      Put_Line ("Wibble");
   end Wobble;
begin
   Wobble;
   Put_Line ("Wobble");
end Wibble;
--- cut ---

I get:

--- cut ---
Initialize
Finalize
Finalize
Wibble
Wobble
Finalize
Finalize
--- cut ---

Ada can't finalize B or C until the program exits, because these
pointers might be duplicated to variables not in the same scope. When
you use Free(...) you are telling the compiler that you guarantee this
is not the case.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: memory management and productivity

[Martin Dowie]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4vfhkfshy.fsf@snoopy.apana.org.au...
> I think the finalize routine doesn't get called because the variable
> drops out of scope, it only gets finalized when the program exits.
>
> So you can't rely on this behavior unless your program was going to
> exit anyway.

You're absolutely right - but this is still different from C++ just not
as different as I'd thought.

Cheers

-- Martin

Re: memory management and productivity

[Ole-Hjalmar Kristensen]

Jano <notelacreas@porfavor.no> writes:

> Russ wrote:
> > "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<cb0vjl$8hp$1@sparta.btinternet.com>...
> >
> >>"Russ" <18k11tm001@sneakemail.com> wrote in message
> >>news:bebbba07.0406181510.37b8f5e2@posting.google.com...
> >>
> >>>>You will be delighted to here that Ada already supports GC thought the
> >>>>use of Controlled types then. And if that weren't enough you can grap
> >>>>"Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/.
> >>>
> >>>I am indeed delighted to hear that. And if Ada really has automatic
> >>>memory management capabilities, more people need to know it.
> >>
> >>Hopefully this thread will breath the life of publicity to this package then
> >>:-)
> >>
> >>
> >>
> >>>However, I am curious about why initialize and finalize are different
> >>>and better than constructors and destructors in C++.
> >>
> >>I never made such a claim.
> > Well, if initialize and finalize are fundamentally no different than
> > constructors and destructors, then I conclude that Ada does not have
> > automated memory management any more than C++ has it. (I may be a bit
> > slow, but I catch on eventually.)
> 
> It's been so many time since I did C++ that I may be wrong, correct me
> in that case.
> 
> IIRC, in C++ you must destroy (delete?) the object to get the
> destructor called. So, even if you have a carefully built chain of
> destructors, if at some point you forget to destroy the root, you're
> leaking.

Yes, *IF* it has been allocated with new.

> 
> In Ada, when an object goes out of scope (assuming it has been created
> in the stack and not with the "new" operator), it's automatically
> finished so you have one less thing to care about.

This is exactly the same as C++.  I would say that Ada and C++ are
more or less on equal footing when it comes to garbage collection in
practice.

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: memory management and productivity

[Jano]

Ole-Hjalmar Kristensen wrote:

>>IIRC, in C++ you must destroy (delete?) the object to get the
>>destructor called. So, even if you have a carefully built chain of
>>destructors, if at some point you forget to destroy the root, you're
>>leaking.
> 
> 
> Yes, *IF* it has been allocated with new.

That's what I wasn't sure about. In java you're forced (right this 
time?) but in C++ I wasn't sure.

But as others have noted, indefinite types and containers for them are a 
blessing.

Re: memory management and productivity

[Martin Dowie]

"Ole-Hjalmar Kristensen"
<ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message
news:wvbrsmcp2uqd.fsf@europa1.Norway.Sun.COM...
> > In Ada, when an object goes out of scope (assuming it has been created
> > in the stack and not with the "new" operator), it's automatically
> > finished so you have one less thing to care about.
>
> This is exactly the same as C++.  I would say that Ada and C++ are
> more or less on equal footing when it comes to garbage collection in
> practice.

No! Please try the example I posted - in Ada an access to a controlled
object is automatically finalized - this is different (and better!) than
C++.

Cheers

-- Martin

Re: memory management and productivity

[Ole-Hjalmar Kristensen]

>>>>> "MD" == Martin Dowie <martin.dowie@baesystems.com> writes:

    MD> "Ole-Hjalmar Kristensen"
    MD> <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message
    MD> news:wvbrsmcp2uqd.fsf@europa1.Norway.Sun.COM...
    >> > In Ada, when an object goes out of scope (assuming it has been created
    >> > in the stack and not with the "new" operator), it's automatically
    >> > finished so you have one less thing to care about.
    >> 
    >> This is exactly the same as C++.  I would say that Ada and C++ are
    >> more or less on equal footing when it comes to garbage collection in
    >> practice.

    MD> No! Please try the example I posted - in Ada an access to a controlled
    MD> object is automatically finalized - this is different (and better!) than
    MD> C++.

    MD> Cheers

    MD> -- Martin

Well, perhaps, but what Jano described is exactly like C++.
Doesn't the automatic finalization of an access to a controlled
object happen only when the *type* goes out of scope?

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: memory management and productivity

[Robert I. Eachus]

Ole-Hjalmar Kristensen wrote:

> Well, perhaps, but what Jano described is exactly like C++.
> Doesn't the automatic finalization of an access to a controlled
> object happen only when the *type* goes out of scope?

No, as Martin's program shows, finalization occurs when the object or 
the type can no longer be referenced, no matter how that happens.  This 
means you have to be a bit careful in designing your Finalize procedure. 
  It may be called several times on the same object in complex cases. 
(The rule is that controlled objects in Ada are always finalized at 
least once. If you think about a subprogram that is doing clean-up when 
an exception occurs, you can see why the choice is between at least once 
and almost always.)

But writing Finalize so that it is okay to call it multiple times is 
usually easy enough to do.   Deallocating an object sets the pointer to 
it to null, and doesn't complain if given a null pointer as an argument. 


-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: memory management and productivity

[Frank J. Lhota]

"Ole-Hjalmar Kristensen"
<ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message
news:wvbrsmcp2uqd.fsf@europa1.Norway.Sun.COM...
> > Russ wrote:
> Yes, *IF* it has been allocated with new.

In C++, all memory allocation / deallocation should be done using the new /
delete operators. This is true even for pointers to classes that do not have
constructors or destructors. This is because classes often have default
constructor / destructor actions that need to be performed for the object to
be usable. For example, if the class has any virtual methods, then "jump
table" must be set up. Also, if any field / sub-field / sub-sub-field has a
constructor / destructor, then this constructor / destructor cannot be
ignored.

The safe way to change the memory management algorithms for a given C++
class is to define new / delete operators for that class. This will permit
the user-defined algorithms for allocation / deallocation to be used for the
class without interfering with constructor / destructor actions. This is the
C++ equivalent of the Ada "for Name'Storage_Pool use ...;" clause.

> This is exactly the same as C++.  I would say that Ada and C++ are
> more or less on equal footing when it comes to garbage collection in
> practice.

I agree. It would be more accurate to say that in both Ada and C++, the
tools are there to implement your types with GC.

Re: memory management and productivity

[Ole-Hjalmar Kristensen]

>>>>> "FJL" == Frank J Lhota <NOSPAM.lhota.adarose@verizon.net> writes:

    FJL> "Ole-Hjalmar Kristensen"
    FJL> <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message
    FJL> news:wvbrsmcp2uqd.fsf@europa1.Norway.Sun.COM...
    >> > Russ wrote:
    >> Yes, *IF* it has been allocated with new.

    FJL> In C++, all memory allocation / deallocation should be done using the new /
    FJL> delete operators. This is true even for pointers to classes that do not have
    FJL> constructors or destructors. This is because classes often have default
    FJL> constructor / destructor actions that need to be performed for the object to
    FJL> be usable. For example, if the class has any virtual methods, then "jump
    FJL> table" must be set up. Also, if any field / sub-field / sub-sub-field has a
    FJL> constructor / destructor, then this constructor / destructor cannot be
    FJL> ignored.

Yes, I agree. I was thinking about stack-allocated objects, where
the destructor is called automatically for you upon exit of the
varaible's scope.

    FJL> The safe way to change the memory management algorithms for a given C++
    FJL> class is to define new / delete operators for that class. This will permit
    FJL> the user-defined algorithms for allocation / deallocation to be used for the
    FJL> class without interfering with constructor / destructor actions. This is the
    FJL> C++ equivalent of the Ada "for Name'Storage_Pool use ...;" clause.

    >> This is exactly the same as C++.  I would say that Ada and C++ are
    >> more or less on equal footing when it comes to garbage collection in
    >> practice.

    FJL> I agree. It would be more accurate to say that in both Ada and C++, the
    FJL> tools are there to implement your types with GC.

Yes, that would be more accurate, although conservative collectors
like Boehm's would probably work with both languages.

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: memory management and productivity

[Martin Krischik]

Jano wrote:

> It's been so many time since I did C++ that I may be wrong, correct me
> in that case.
> 
> IIRC, in C++ you must destroy (delete?) the object to get the destructor
> called. So, even if you have a carefully built chain of destructors, if
> at some point you forget to destroy the root, you're leaking.
> 
> In Ada, when an object goes out of scope (assuming it has been created
> in the stack and not with the "new" operator), it's automatically
> finished so you have one less thing to care about.

It is the same in Ada as in C++. Both can create object on the heap on
stack. The real difference is that Ada has indefinite objects and as a
result far less object need to be created on the heap.

For example C++ std::vector<> can't store polymorvic objects - Ada soon to
come Ada.Containers.Indefinite_Vectors can.

With Regards

Martin

Container Libraries with support for indefinite Object:

Booch Components: http://adacl.sf.net
Ada.Containers: http://charles.tigris.org.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: memory management and productivity

[Hyman Rosen]

Martin Krischik wrote:
> For example C++ std::vector<> can't store polymorvic objects - Ada soon to
> come Ada.Containers.Indefinite_Vectors can.

That seems like a neat trick, given that a vector is
intended to work like an array, that is, to have a
contiguous block of equal-sized objects. How is the
container going to work?

Re: memory management and productivity

[Martin Krischik]

Hyman Rosen wrote:

> Martin Krischik wrote:
>> For example C++ std::vector<> can't store polymorvic objects - Ada soon
>> to come Ada.Containers.Indefinite_Vectors can.
> 
> That seems like a neat trick, given that a vector is
> intended to work like an array,
> that is, to have a 
> contiguous block of equal-sized objects.

It only has to work like it - internally it might be implemented differently
i.E. using dynamic memory.

> How is the 
> container going to work?

The trick is that Ada can "clone ()" objects without:

class Base
{
   virtual Base* clone();
}

That's because Ada knows (by hidden size attribute) how large any object is.
Including polymorvic objects. Write any indefinite object to a Stream via
'Output and look at it with hex editor.

In that respect Ada is even cooler then Java: You can serialise any object
without a Serialiseable interface.

So, the truth is that the object is copied into dynamic memory. However, you
will never know about it.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: memory management and productivity

[Hyman Rosen]

Jano wrote:
> correct me in that case.

OK.

> IIRC, in C++ you must destroy (delete?) the object to get the destructor 
> called. So, even if you have a carefully built chain of destructors, if 
> at some point you forget to destroy the root, you're leaking.
> 
> In Ada, when an object goes out of scope (assuming it has been created 
> in the stack and not with the "new" operator), it's automatically 
> finished so you have one less thing to care about.

Both in C++ and in Ada, a stack object is finalized/destructed
automatically when its scope is exited.

I believe, but I'm not sure, that in Ada if a pointer *type* (not
a pointer object) goes out of scope, then all objects of that type
are deallocated.

Re: memory management and productivity

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> I believe, but I'm not sure, that in Ada if a pointer *type* (not
> a pointer object) goes out of scope, then all objects of that type
> are deallocated.

Not sure but I think the above is right if the type has its own storage pool.
To be checked though...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: memory management and productivity

[Robert I. Eachus]

Hyman Rosen wrote:

> I believe, but I'm not sure, that in Ada if a pointer *type* (not
> a pointer object) goes out of scope, then all objects of that type
> are deallocated.

Hmmm, a better description is that if a type goes out of scope, all 
objects of that type are deallocated.  If a storage pool goes out of 
scope, all objects in the pool are deallocated. If an access type goes 
out of scope though, nothing special happens.

It is easiest to see this by thinking about:

declare
   type Foo is private;
   Foob: Foo;

   procedure Fubar(F: in Foo) is
     type Bar is access all Foo
     B: Bar := F'access;
   begin null end;
begin
   Fubar(Foob);
end;

Obviously you don't want Foob to be deallocated when Bar goes out of 
scope.  B will be deallocated when Fubar returns, but that is because B 
goes out of scope, not Bar.


-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: memory management and productivity

[Martin Dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0406202016.1f15c133@posting.google.com...
> Well, if initialize and finalize are fundamentally no different than
> constructors and destructors, then I conclude that Ada does not have
> automated memory management any more than C++ has it. (I may be a bit
> slow, but I catch on eventually.)
>
> As for using a library that has memory management built in, that
> sounds great. I'd just feel a bit better about it if it were in a
> standard library that everyone agrees on and comes with the language,
> like STL in C++. Then you could honestly say that Ada has automated
> memory management built in. (And it would be better than Java's
> because it would be optional.)

Ada does not forbid an implementation for performing GC but there
has been zero customer call for it. That's no too surprising - "Sorry, you
can't apply brakes/launch missile/shutdown reactor as I'm busy garbage
collecting." would not go done well.

But for desktop apps or even business apps, it might well be appropriate.

Cheers

-- Martin

Re: memory management and productivity

[Russ]

"Martin Dowie" <martin.dowie@baesystems.com> wrote in message news:<40d69121$1_1@baen1673807.greenlnk.net>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0406202016.1f15c133@posting.google.com...
> > Well, if initialize and finalize are fundamentally no different than
> > constructors and destructors, then I conclude that Ada does not have
> > automated memory management any more than C++ has it. (I may be a bit
> > slow, but I catch on eventually.)
> >
> > As for using a library that has memory management built in, that
> > sounds great. I'd just feel a bit better about it if it were in a
> > standard library that everyone agrees on and comes with the language,
> > like STL in C++. Then you could honestly say that Ada has automated
> > memory management built in. (And it would be better than Java's
> > because it would be optional.)
> 
> Ada does not forbid an implementation for performing GC but there
> has been zero customer call for it. That's no too surprising - "Sorry, you
> can't apply brakes/launch missile/shutdown reactor as I'm busy garbage
> collecting." would not go done well.

Are you saying that an Ada compiler can implement GC or not? That
seems a bit inconsistent to me. How can the same language have it both
ways? What if someone tries to port an Ada application that has its
own memory management to an Ada compiler that already has it by
default? I would think you would at least want it controlled by a
compilation flag or some something.

> But for desktop apps or even business apps, it might well be appropriate.

Which is why it should be under control of the application developer,
it seems to me.

Re: memory management and productivity

[David Starner]

On Mon, 21 Jun 2004 12:03:55 -0700, Russ wrote:

> Are you saying that an Ada compiler can implement GC or not? That
> seems a bit inconsistent to me. How can the same language have it both
> ways?

Every language has it both ways. You could link the Boehm-Weiser garbage
collector into a C program without any change to the source outside a
couple defines on the command line. A Lisp interpreter could choose not to
garbage collect memory. Like interpretation, GC is more a feature of
choices and tradition than an enforced standard.

The advantage of Ada is that the strong typing makes it possible for an
advanced GC to find pointers and adjust them when moving things in memory.
Ada also makes many of the small, temporary memory uses found in C
unnecessary by allowing you to pass things by reference and to pass arrays.

> What if someone tries to port an Ada application that has its
> own memory management to an Ada compiler that already has it by
> default? 

It depends on the code and on the GC system. If you depend on the details
of memory management, then you depend on the details of memory management.
If it's pure Ada, it should work; if it's not, it might not work. In any
case, well-designed memory management systems are usually easy to pull out
or at least write a dummy replacement for.

> Which is why it should be under control of the application developer,
> it seems to me.

But it is. The application developer chooses which compiler to use and
which flags to compile it with. 

If you're compiling for a LISP machine or a JVM, you probably don't have a
choice whether or not to use GC. As the only Ada compilers with built-in
GC right now are those which compile to the JVM, they don't offer a choice.

Re: memory management and productivity

[Ole-Hjalmar Kristensen]

>>>>> "DS" == David Starner <dvdeug@email.ro> writes:

    DS> On Mon, 21 Jun 2004 12:03:55 -0700, Russ wrote:
    >> Are you saying that an Ada compiler can implement GC or not? That
    >> seems a bit inconsistent to me. How can the same language have it both
    >> ways?

    DS> Every language has it both ways. You could link the Boehm-Weiser garbage
    DS> collector into a C program without any change to the source outside a
    DS> couple defines on the command line. A Lisp interpreter could choose not to
    DS> garbage collect memory. Like interpretation, GC is more a feature of
    DS> choices and tradition than an enforced standard.

But the only language which I have used so far which got it quite
right IMHO is Modula-3. The programmer is free to choose, and the
language guarantees that GC is available.

<snip>

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: memory management and productivity

[Russ]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:<wvbrr7s8qatj.fsf@sun.com>...
> >>>>> "DS" == David Starner <dvdeug@email.ro> writes:
> 
>     DS> On Mon, 21 Jun 2004 12:03:55 -0700, Russ wrote:
>     >> Are you saying that an Ada compiler can implement GC or not? That
>     >> seems a bit inconsistent to me. How can the same language have it both
>     >> ways?
> 
>     DS> Every language has it both ways. You could link the Boehm-Weiser garbage
>     DS> collector into a C program without any change to the source outside a
>     DS> couple defines on the command line. A Lisp interpreter could choose not to
>     DS> garbage collect memory. Like interpretation, GC is more a feature of
>     DS> choices and tradition than an enforced standard.
> 
> But the only language which I have used so far which got it quite
> right IMHO is Modula-3. The programmer is free to choose, and the
> language guarantees that GC is available.

Bingo. That's exactly what Ada should have. And it shouldn't take a
rocket scientist to figure that out.

Re: memory management and productivity

[Martin Dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0406222041.593ab7c3@posting.google.com...
> > But the only language which I have used so far which got it quite
> > right IMHO is Modula-3. The programmer is free to choose, and the
> > language guarantees that GC is available.
>
> Bingo. That's exactly what Ada should have. And it shouldn't take a
> rocket scientist to figure that out.

We could start the ball rolling on getting the AdaCL garbage collector into
Ada1X! :-)

Re: memory management and productivity

[Björn Persson]

Martin Dowie wrote:

> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0406222041.593ab7c3@posting.google.com...
> 
>>>But the only language which I have used so far which got it quite
>>>right IMHO is Modula-3. The programmer is free to choose, and the
>>>language guarantees that GC is available.
>>
>>Bingo. That's exactly what Ada should have. And it shouldn't take a
>>rocket scientist to figure that out.
> 
> We could start the ball rolling on getting the AdaCL garbage collector into
> Ada1X! :-)

Could someone enlighten me a little on the mysteries of garbage?

Since a garbage collector can apparently be compiled in as a library, 
why isn't that good enough? Is it a great advantage to have it provided 
by the compiler instead?

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: memory management and productivity

[David Starner]

On Wed, 23 Jun 2004 17:36:23 +0000, Bj�rn Persson wrote:

> Could someone enlighten me a little on the mysteries of garbage?
> 
> Since a garbage collector can apparently be compiled in as a library, 
> why isn't that good enough? Is it a great advantage to have it provided 
> by the compiler instead?

The only library garbage collectors I know about are conservative; they
assume that every pointer-size chunk of accessible memory is a pointer,
(unless it's in a block of data that was allocated with a special function
that tells the GC there are no pointers in that data.) They don't move
memory because you can't adjust pointers if you can't tell pointers from
integers. A garbage collector that was part of the compiler could tell
integers from pointers (that is, be a precise collector instead of a
conservative collector) and could move items in memory (which many
high-performance GCs do.) This makes easier, for example, for a compiler
to scan only the new stuff, which has a shorter live time than the stuff
the program has kept around for a while. The first may be more important;
a misplaced integer could potentially hold several megabytes of garbage in
memory.

Re: memory management and productivity

[Björn Persson]

David Starner wrote:

> The only library garbage collectors I know about are conservative; they
> assume that every pointer-size chunk of accessible memory is a pointer,
> (unless it's in a block of data that was allocated with a special function
> that tells the GC there are no pointers in that data.) They don't move
> memory because you can't adjust pointers if you can't tell pointers from
> integers. A garbage collector that was part of the compiler could tell
> integers from pointers (that is, be a precise collector instead of a
> conservative collector) and could move items in memory (which many
> high-performance GCs do.) This makes easier, for example, for a compiler
> to scan only the new stuff, which has a shorter live time than the stuff
> the program has kept around for a while. The first may be more important;
> a misplaced integer could potentially hold several megabytes of garbage in
> memory.

I see. For a language like Ada, something that can't tell a pointer from 
an integer clearly isn't as good as it could be. I knew there had to be 
some drawback with a garbage collector that works for C. :-)

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: memory management and productivity

[Martin Krischik]

Bjï¿œrn Persson wrote:

> David Starner wrote:
> 
>> The only library garbage collectors I know about are conservative; they
>> assume that every pointer-size chunk of accessible memory is a pointer,
>> (unless it's in a block of data that was allocated with a special
>> function that tells the GC there are no pointers in that data.) They
>> don't move memory because you can't adjust pointers if you can't tell
>> pointers from integers. A garbage collector that was part of the compiler
>> could tell integers from pointers (that is, be a precise collector
>> instead of a conservative collector) and could move items in memory
>> (which many high-performance GCs do.) This makes easier, for example, for
>> a compiler to scan only the new stuff, which has a shorter live time than
>> the stuff the program has kept around for a while. The first may be more
>> important; a misplaced integer could potentially hold several megabytes
>> of garbage in memory.
> 
> I see. For a language like Ada, something that can't tell a pointer from
> an integer clearly isn't as good as it could be. I knew there had to be
> some drawback with a garbage collector that works for C. :-)

BTW: In an Ada dialect with a precise collector Unchecked_Convertion between
Access and Address/Integer are likely not to work any more.

And if you use Unchecked_Deallocation you need to use pragma Controlled as
well.

Both of which will break existing code :-(.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: memory management and productivity

[Wes Groleau]

Martin Krischik wrote:
> BTW: In an Ada dialect with a precise collector Unchecked_Convertion between
> Access and Address/Integer are likely not to work any more.

Never did work very well--at least not portably.
There is no requirement for an access type to
actually be the address of the object.

Interesting bugs when some C person makes that
assumption, and luckily it works.  Then two years
later, he/she is gone and you change compilers.....

-- 
Wes Groleau

A pessimist says the glass is half empty.

An optimist says the glass is half full.

An engineer says somebody made the glass
        twice as big as it needed to be.

Re: memory management and productivity

[Russ]

Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<rcjCc.96718$dP1.318279@newsc.telia.net>...
> Martin Dowie wrote:
> 
> > "Russ" <18k11tm001@sneakemail.com> wrote in message
> > news:bebbba07.0406222041.593ab7c3@posting.google.com...
> > 
> >>>But the only language which I have used so far which got it quite
> >>>right IMHO is Modula-3. The programmer is free to choose, and the
> >>>language guarantees that GC is available.
> >>
> >>Bingo. That's exactly what Ada should have. And it shouldn't take a
> >>rocket scientist to figure that out.
> > 
> > We could start the ball rolling on getting the AdaCL garbage collector 
>  into
> > Ada1X! :-)
> 
> Could someone enlighten me a little on the mysteries of garbage?
> 
> Since a garbage collector can apparently be compiled in as a library, 
> why isn't that good enough? Is it a great advantage to have it provided 
> by the compiler instead?

Having it as a library is fine with me -- as long as the library is
*standard* and available with every Ada compiler (or at least the main
free one).

Re: memory management and productivity

[Robert I. Eachus]

Russ wrote:

> Having it as a library is fine with me -- as long as the library is
> *standard* and available with every Ada compiler (or at least the main
> free one).

If you want, I write you a generic library for Ada 95 that does garbage 
collection.  All you need to do is wrap Ada.Strings.Unbounded_String in 
a generic along with Unchecked_Conversion.

I've never bothered to do it because the cases where I used the 
technique, it was better to have a non-generic binding.  (Slices of 
arrays created as intermediate values.  Slicing two dimensional arrays 
was most of the work, not the garbage management.)

Incidently, the 'fragile' part of that code is not the garbage 
collection, it is deciding what the lifetime of a particular slice needs 
to be.  If you make the lifetime too short, you either have code that 
won't compile or get an exception during testing. If you make the scope 
too long, you run out of storage.  (And yes, the liftime of the object 
is determined by where it is declared, it is getting those declarations 
in the right place that is difficult.)

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: memory management and productivity

[Larry Kilgallen]

In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:

> Bingo. That's exactly what Ada should have. And it shouldn't take a
> rocket scientist to figure that out.

ACT says they have not really seen market demand from their customers,
and some of them are presumably rocket scientists.

Absent customer demand, there seems no justification for a _requirement_
since Ada already has a _permission_.

Re: memory management and productivity

[Björn Persson]

Larry Kilgallen wrote:

> In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> 
>>Bingo. That's exactly what Ada should have. And it shouldn't take a
>>rocket scientist to figure that out.
> 
> ACT says they have not really seen market demand from their customers,
> and some of them are presumably rocket scientists.

Well, I'd think rocket scientists don't want garbage collection. Their 
programs are real-time systems.

Developers of desktop applications are more likely to want garbage 
collection, but very few of them use Ada, and of those who do, probably 
very few can afford support contracts from ACT.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: memory management and productivity

[Ole-Hjalmar Kristensen]

>>>>> "BP" == Bj�rn Persson <spam-away@nowhere.nil> writes:

    BP> Larry Kilgallen wrote:
    >> In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
    >> 

    >>> Bingo. That's exactly what Ada should have. And it shouldn't take a
    >>> rocket scientist to figure that out.
    >> ACT  says  they  have  not  really seen  market  demand  from  their
    >> customers,

    >> and some of them are presumably rocket scientists.

    BP> Well, I'd think rocket scientists don't want garbage collection. Their
    BP> programs are real-time systems.

In that case, you do not want any dynamic allocation whatsoever, so
the availability of garbage collection is not important.  On the other
hand, *IF* you can live with dynamic allocation, there are garbage
collection algorithms which will give hard real-time performance,
provided you have an upper bound on the size of your objects. Baker's
treadmill, the incremental copying collector, and reference-counting
schemes can all do this with a very slight loss of generality.


    BP> Developers  of desktop applications  are more  likely to  want garbage
    BP> collection,  but very  few  of them  use  Ada, and  of  those who  do,
    BP> probably very few can afford support contracts from ACT.


    BP> -- 
    BP> Bj�rn Persson                              PGP key A88682FD
    BP>                     omb jor ers @sv ge.
    BP>                     r o.b n.p son eri nu


-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: memory management and productivity

[Simon Wright]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> writes:

> >>>>> "BP" == Bj�rn Persson <spam-away@nowhere.nil> writes:

>     BP> Well, I'd think rocket scientists don't want garbage
>     BP> collection. Their programs are real-time systems.
> 
> In that case, you do not want any dynamic allocation whatsoever, so
> the availability of garbage collection is not important.

Depends what you mean by "dynamic allocation". I see nothing wrong
with using dynamic allocation so long as the storage pool used behaves
appropriately for the requirement.

-- 
Simon Wright                               100% Ada, no bugs.

Re: memory management and productivity

[Russ]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<qc2e5zFQJM1y@eisner.encompasserve.org>...
> In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Bingo. That's exactly what Ada should have. And it shouldn't take a
> > rocket scientist to figure that out.
> 
> ACT says they have not really seen market demand from their customers,
> and some of them are presumably rocket scientists.
> 
> Absent customer demand, there seems no justification for a _requirement_
> since Ada already has a _permission_.

The rocket scientists probably don't need or want automated memory
management for their real-time applications, but desktop application
developers probably do. Why not make them both happy?

Oh, the desktop developers are not "demanding" it? Of course they
aren't, because they aren't using Ada in the first place. And why
aren't they using Ada? Perhaps in part because it doesn't have GC.

Why wait for your current customers to "demand" something before
adding a basic feature that could turn *potential* customers into
*actual* customers? I'm afraid that such short-sighted views will only
perpetuate the demise of Ada.

Re: memory management and productivity

[David Starner]

On Wed, 23 Jun 2004 11:18:09 -0700, Russ wrote:

> Oh, the desktop developers are not "demanding" it? Of course they
> aren't, because they aren't using Ada in the first place. And why
> aren't they using Ada? Perhaps in part because it doesn't have GC.

So instead they use ... C++. Ada is not going to make a dent in Perl,
Python, or Lisp(s), because they aren't designed for the same types of
jobs. As for Java, ACT produced a version of GNAT (JGNAT) that compiled to
the JVM (and thus was GCed). They found no (few?) takers, and stopped
supporting it. GC just ain't going to get a bunch of programmers using Ada.

Re: memory management and productivity

[Larry Kilgallen]

In article <bebbba07.0406231018.21d042db@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:

> The rocket scientists probably don't need or want automated memory
> management for their real-time applications, but desktop application
> developers probably do. Why not make them both happy?
> 
> Oh, the desktop developers are not "demanding" it? Of course they
> aren't, because they aren't using Ada in the first place. And why
> aren't they using Ada? Perhaps in part because it doesn't have GC.

They are off using Smalltalk ?

Why would they be using that rather than using the "build it yourself"
form of garbage collection discussed here, all the time complaining
that it was not built in.

> Why wait for your current customers to "demand" something before
> adding a basic feature that could turn *potential* customers into
> *actual* customers? I'm afraid that such short-sighted views will only
> perpetuate the demise of Ada.

I have the feeling you don't have experience in marketing or overall
company finance.

Re: memory management and productivity

[Russ]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<IKJODEu6UfVI@eisner.encompasserve.org>...
> In article <bebbba07.0406231018.21d042db@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> 
> > The rocket scientists probably don't need or want automated memory
> > management for their real-time applications, but desktop application
> > developers probably do. Why not make them both happy?
> > 
> > Oh, the desktop developers are not "demanding" it? Of course they
> > aren't, because they aren't using Ada in the first place. And why
> > aren't they using Ada? Perhaps in part because it doesn't have GC.
> 
> They are off using Smalltalk ?
> 
> Why would they be using that rather than using the "build it yourself"
> form of garbage collection discussed here, all the time complaining
> that it was not built in.
> 
> > Why wait for your current customers to "demand" something before
> > adding a basic feature that could turn *potential* customers into
> > *actual* customers? I'm afraid that such short-sighted views will only
> > perpetuate the demise of Ada.
> 
> I have the feeling you don't have experience in marketing or overall
> company finance.

No, I don't. But it seems to me that Ada has a golden opportunity here
to provide a clear advantage over both C++ and Java -- and it is
declining.

C++ has no garbage collection, and development time is two to three
times greater as a result (not to mention memory leaks all over the
place). Java has GC, but everyone is working overtime to make it work
for real time. The obvious solution is to have GC available on demand
-- but *optional* at the discretion of the developer.

You Ada enthusiasts tell me that the Ada standard "allows" GC but does
not require it to be available. Well, as an engineer who would like to
promote Ada, I honestly don't know what that means. Does Ada have
standard automated memory management or doesn't it? Can I count on it,
or can't I? If not, what good is it to me?

Maybe you think I am just too simple minded. Well, maybe I am. But so
are a lot of other people, including many of the decision-making
managers you guys are so fond of. When they compare languages (if they
do), one thing they do is to set up a list of check boxes, and one is
for GC. As a rule of thumb, a check beats a question mark every time.

Re: memory management and productivity

[Robert I. Eachus]

Russ wrote:

> Maybe you think I am just too simple minded. Well, maybe I am. But so
> are a lot of other people, including many of the decision-making
> managers you guys are so fond of. When they compare languages (if they
> do), one thing they do is to set up a list of check boxes, and one is
> for GC. As a rule of thumb, a check beats a question mark every time.

Ada does not have a REQUIREMENT for garbage collection.  What it has 
though is a requirement for no memory leaks:

AdaRM A.4.5(88): Implementation Requirements

     No storage associated with an Unbounded_String object shall be lost 
upon assignment or scope exit.

Those words were chosen specifically to require what garbage collection 
promises, but not to require any particular garbage collection scheme. 
If the implementor implements this using something other than garbage 
collection, do you as a user care?  I certainly don't think about 
whether the object will be managed with reference counts, controlled 
types, or global garbage collection when I use Unbounded_String. All I 
need to know is that it works, and works means no storage leaks.

If I don't want heap allocation, I can use Bounded_String where the RM says:

AdaRM A.4.4(106): Implementation Advice

      Bounded string objects should not be implemented by implicit 
pointers and dynamic allocation.

And as I said in another post, if I want to use similar memory 
management for arrays of Long_Float, I use Unchecked_Conversion. 
(Actually I use a record with the array bounds AND an Unbounded_String 
object.)

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: memory management and productivity

[Randy Brukardt]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:JvCdnWaLWMnaOEDdRVn-jg@comcast.com...
...
> Ada does not have a REQUIREMENT for garbage collection.  What it has
> though is a requirement for no memory leaks:
>
> AdaRM A.4.5(88): Implementation Requirements
>
>      No storage associated with an Unbounded_String object shall be lost
> upon assignment or scope exit.
>
> Those words were chosen specifically to require what garbage collection
> promises, but not to require any particular garbage collection scheme.
> If the implementor implements this using something other than garbage
> collection, do you as a user care?  I certainly don't think about
> whether the object will be managed with reference counts, controlled
> types, or global garbage collection when I use Unbounded_String. All I
> need to know is that it works, and works means no storage leaks.

Note that the various containers proposed for Ada 2005 have the same wording
and thus the same properties. Using them, Robert can store his array of
Long_Floats without any Unchecked_Conversion.

                Randy.

Re: memory management and productivity

[Stephen Leake]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Bingo. That's exactly what Ada should have. And it shouldn't take a
> > rocket scientist to figure that out.
> 
> ACT says they have not really seen market demand from their customers,
> and some of them are presumably rocket scientists.

Me, for one :).

I prefer to manage memory according to the needs of my algorithms and
applications, rather than letting some unknown algorithm attempt to do
it for me. Ada lets me do this quite nicely.

One thing I would like is better testing tools for the GNAT allocator.
That's a vendor issue, not a language issue.
-- 
-- Stephe

Re: memory management and productivity

[Hyman Rosen]

Stephen Leake wrote:
> I prefer to manage memory according to the needs of my algorithms and
> applications, rather than letting some unknown algorithm attempt to do
> it for me.

I prefer to manage registers according to the needs of my algorithms and
applications, rather than letting some unknown algorithm attempt to do it
for me. That's why I'll never use FORTRAN!

Re: memory management and productivity

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1088086179.73158@master.nyc.kbcfp.com...
> I prefer to manage registers according to the needs of my algorithms and
> applications, rather than letting some unknown algorithm attempt to do it
> for me. That's why I'll never use FORTRAN!

LOL! BTW are you writing FORTRAN in all caps for emphasis or to stick with
the 1960's programming language naming conventions?

A side note: FORTRAN I (three revisions before the widely adapted FORTRAN
IV) did have a REGISTER declaration, used in much the same way as the
"register" keyword in C/C++. It was used to indicate a variable that was so
commonly used that it should be implemented as a register. The FORTRAN
'REGISTER' declaration was dropped after version 1, only to surface again in
other languages.

Re: memory management and productivity

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Stephen Leake wrote:
> > I prefer to manage memory according to the needs of my algorithms and
> > applications, rather than letting some unknown algorithm attempt to do
> > it for me.
> 
> I prefer to manage registers according to the needs of my algorithms and
> applications, rather than letting some unknown algorithm attempt to do it
> for me. That's why I'll never use FORTRAN!

Well, I see the analogy, but I don't think it's a good one. 

The advantages of letting an optimizing compiler schedule register
usage are well proven.

The disadvantages of typical garbage collectors are also well proven.

The use of specific memory management schemes for specific application
requirements are also well proven.

For register scheduling, there are general techniques that produce
nearly universally good results. I don't think the same can be said of
memory management/garbage collection.

On the other hand, I mostly do hard realtime, with little need for
dynamic memory management, so I'm not in the best position to judge.

-- 
-- Stephe

Re: memory management and productivity

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1088086179.73158@master.nyc.kbcfp.com>...
> Stephen Leake wrote:
> > I prefer to manage memory according to the needs of my algorithms and
> > applications, rather than letting some unknown algorithm attempt to do
> > it for me.
> 
> I prefer to manage registers according to the needs of my algorithms and
> applications, rather than letting some unknown algorithm attempt to do it
> for me. That's why I'll never use FORTRAN!

I can imagine someone actually saying that. I knew an engineer who at
one time refused to use a VT-100 terminal because he didn't trust it
as much as he did punch cards. And he was a very good engineer,
believe it or not.

Re: memory management and productivity

[Russ]

Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<mailman.151.1088083768.391.comp.lang.ada@ada-france.org>...
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
> > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> > 
> > > Bingo. That's exactly what Ada should have. And it shouldn't take a
> > > rocket scientist to figure that out.
> > 
> > ACT says they have not really seen market demand from their customers,
> > and some of them are presumably rocket scientists.
> 
> Me, for one :).
> 
> I prefer to manage memory according to the needs of my algorithms and
> applications, rather than letting some unknown algorithm attempt to do
> it for me. Ada lets me do this quite nicely.

What's your point? Because you don't want automated memory management,
nobody else should want it either? What I'm suggesting would give you
what you want and it would also give the desktop and web developers
what they want. In other words, it would make Ada a more versatile
language. Maybe you don't think that's wise, but if you don't, please
don't complain about the fact that Java dwarfs Ada in popularity (and
is now being adapted big-time for real-time use by the military).

Re: memory management and productivity

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<mailman.151.1088083768.391.comp.lang.ada@ada-france.org>...
> > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> > 
> > > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> > > 
> > > > Bingo. That's exactly what Ada should have. And it shouldn't take a
> > > > rocket scientist to figure that out.
> > > 
> > > ACT says they have not really seen market demand from their customers,
> > > and some of them are presumably rocket scientists.
> > 
> > Me, for one :).
> > 
> > I prefer to manage memory according to the needs of my algorithms and
> > applications, rather than letting some unknown algorithm attempt to do
> > it for me. Ada lets me do this quite nicely.
> 
> What's your point? 

My point is that _this_ "rocket scientist" reaches a different
conclusion than you do about the desirability of garbage collection.

> Because you don't want automated memory management, nobody else
> should want it either? 

That's not exactly my argument, but it is my conclusion, if by
"automated memory management" you mean "garbage collection, as
provided by the JVM for example".

The term "automated memory management" can mean many things, including
typical Ada use of the stack for local variables. So we need clearer
definitions before we go any farther.

> What I'm suggesting would give you what you want and it would also
> give the desktop and web developers what they want. 

I'm suggesting that "garbage collection" is not what they _need_
(different from what they _want_).

> In other words, it would make Ada a more versatile language. 

Nope.

As many have pointed out, Ada the _langauge_ allows for garbage
collection, and some implementations have provided it (JGNAT in
particular). That has not lead to commercial success. So what has
changed, that you think it will lead to commercial success now?

Ada provides better ways to manage memory, and programmers that take
the time to figure that out don't need traditional "garbage
collection".

> Maybe you don't think that's wise, but if you don't, please don't
> complain about the fact that Java dwarfs Ada in popularity (and is
> now being adapted big-time for real-time use by the military).

I've never "complained" about that. I'm disappointed in the waste of
my tax dollars, but that's nothing new :).

-- 
-- Stephe

Re: memory management and productivity

[Ole-Hjalmar Kristensen]

>>>>> "SL" == Stephen Leake <stephen_leake@acm.org> writes:
<snip>

    SL> I'm suggesting that "garbage collection" is not what they _need_
    SL> (different from what they _want_).

    >> In other words, it would make Ada a more versatile language. 

    SL> Nope.

    SL> As many have pointed out, Ada the _langauge_ allows for garbage
    SL> collection, and some implementations have provided it (JGNAT in
    SL> particular). That has not lead to commercial success. So what has
    SL> changed, that you think it will lead to commercial success now?

"Allows for" is not the same as is available. You cannot write a
portable Ada application and take advantage of automatic garbage
collection. You *can* do that with Java. You can argue that
programmers do not need garbage collection, but you cannot stop them
from wanting it.

But I agree, I do not think that adding garbage collection would make
much difference wrt. commercial success of Ada. I think Ada is doomed
to forever being a niche language.

    SL> Ada provides better ways to manage memory, and programmers that take
    SL> the time to figure that out don't need traditional "garbage
    SL> collection".

Of course yo do not need it, but it can be convenient.

    >> Maybe you don't think that's wise, but if you don't, please don't
    >> complain about the fact that Java dwarfs Ada in popularity (and is
    >> now being adapted big-time for real-time use by the military).

    SL> I've never "complained" about that. I'm disappointed in the waste of
    SL> my tax dollars, but that's nothing new :).

    SL> -- 
    SL> -- Stephe


-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: memory management and productivity

[David Starner]

On Fri, 25 Jun 2004 12:13:34 +0200, Ole-Hjalmar Kristensen wrote:

> You *can* do that with Java. You can argue that
> programmers do not need garbage collection, but you cannot stop them
> from wanting it.

Who is wanting it? I'm not seeing the people on this newsgroup demanding
it, except those thinking of it as a magic bullet. I'm not seeing the
people who use Ada running out and writing garbage collectors. I'm not
seeing all the people that are writing code in C and C++, which makes up
a large percentage of any Linux distribution, using garbage collectors.
Gnome and KDE have no reason not to have a garbage collector, given the
number of libraries they already depend on. But they choose not to. All
this indicates that GC is not important to many programmers.

Re: memory management and productivity

[Russ]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.153.1088127452.391.comp.lang.ada@ada-france.org>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<mailman.151.1088083768.391.comp.lang.ada@ada-france.org>...
> > > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> > > 
> > > > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> > > > 
> > > > > Bingo. That's exactly what Ada should have. And it shouldn't take a
> > > > > rocket scientist to figure that out.
> > > > 
> > > > ACT says they have not really seen market demand from their customers,
> > > > and some of them are presumably rocket scientists.
> > > 
> > > Me, for one :).
> > > 
> > > I prefer to manage memory according to the needs of my algorithms and
> > > applications, rather than letting some unknown algorithm attempt to do
> > > it for me. Ada lets me do this quite nicely.
> > 
> > What's your point? 
> 
> My point is that _this_ "rocket scientist" reaches a different
> conclusion than you do about the desirability of garbage collection.
> 
> > Because you don't want automated memory management, nobody else
> > should want it either? 
> 
> That's not exactly my argument, but it is my conclusion, if by
> "automated memory management" you mean "garbage collection, as
> provided by the JVM for example".
> 
> The term "automated memory management" can mean many things, including
> typical Ada use of the stack for local variables. So we need clearer
> definitions before we go any farther.

I don't know much about memory management or garbage collection, but I
do know that it is considered a great benefit of Java and many other
languages. Whatever Ada provides in this regard should be optional at
the discretion of the *developer* (not the compiler vendor), and it
should be at least as good as the GC in Java for those who choose to
use it that way.

> > What I'm suggesting would give you what you want and it would also
> > give the desktop and web developers what they want. 
> 
> I'm suggesting that "garbage collection" is not what they _need_
> (different from what they _want_).

Yes, of course, and a C programmer could just as well claim that you
don't really need array bound checking. All you need is to be careful
not to address your arrays out of bounds.

I think you are missing a huge point here. The advantages of automatic
memory management are that it is (1) convenient for the developer and
(2) much more reliable, just as the automatic array bounds checking is
more reliable than a developer's hand-rolled bounds checking.

You may neither want or need it for your application, and you
shouldn't be forced to use it, but the desktop and web developers
should always have it available if they want it. They shouldn't be
denied a valuable feature just because you don't want it.

> > In other words, it would make Ada a more versatile language. 
> 
> Nope.

Yup. Look at the amazing popularity of Java. I would venture to say
that it is due, in large part, to Java's garbage collection. Java
started out as a web language, and it has become a desktop application
language too. Now it is so popular that it is starting to push Ada out
of its niche in real-time systems. Once a language reaches a certain
level of popularity, everyone wants to use it. Your attitude of not
caring what desktop/web developers want is a sure-fire way to let Ada
die a slow, agonizing death.

> As many have pointed out, Ada the _langauge_ allows for garbage
> collection, and some implementations have provided it (JGNAT in
> particular). That has not lead to commercial success. So what has
> changed, that you think it will lead to commercial success now?

That's a bit like saying, "Hey, we threw a 60-yard touchdown pass and
we still lost the game, so why should we waste our time trying to
score touchdowns anymore?" I can't guarantee that GC (or equivalent)
will make Ada more popular, but I *can* guarantee that Ada will *not*
become more popular if it continues to ignore the needs of the vast
majority of developers out there.

> Ada provides better ways to manage memory, and programmers that take
> the time to figure that out don't need traditional "garbage
> collection".

So I guess all those Canneige-Mellon and MIT professors who use Java
are just simpletons. Hey, I agree that they should use Ada, but I'm
not quite as arrogant as you in telling them what they need.

> > Maybe you don't think that's wise, but if you don't, please don't
> > complain about the fact that Java dwarfs Ada in popularity (and is
> > now being adapted big-time for real-time use by the military).
> 
> I've never "complained" about that. I'm disappointed in the waste of
> my tax dollars, but that's nothing new :).

If self-centered attitudes like yours prevail in the Ada community, I
suggest you start getting used to a lot more of the same.

Re: memory management and productivity

[Martin Dowie]

Russ wrote:
> Yup. Look at the amazing popularity of Java. I would venture to say
> that it is due, in large part, to Java's garbage collection.

I don't believe for a minute that Java is popular "in large part" because
of GC - much more to do with Sun's $$$$ and a huge built in _standard_
library.

Having said that, I don't see any harm in making GC in Ada much more
mainstream.

Re: memory management and productivity

[Ed Falis]

On 25 Jun 2004 16:35:53 -0700, Russ <18k11tm001@sneakemail.com> wrote:

> Yup. Look at the amazing popularity of Java. I would venture to say
> that it is due, in large part, to Java's garbage collection.


Unfortunately, there are counter-arguments to this conjecture, anyway.

Consider Eiffel, a very nice language, quite Ada-like in many ways, with  
garbage collection and several innovative features (eg design by  
contract).  It is not as popular or as widely used as Ada.

Consider that both Aonix (from Intermetrics/Averstar) and AdaCore provided  
Ada compilers for the JVM, including garbage collection and robust  
bindings to the  Java class libraries.  Neither was commercially  
successful.

Consider that when I was at Aonix, I built a setup allowing the use of the  
Great Circle garbage collector with ObjectAda, and that we advertized the  
availability of this capability.   One copy of GC was sold with ObjectAda  
if I remember rightly.

So, IMO, garbage collection is a nice option to have, but I doubt that  
it's of the essence of Java's popularity.

By the way, I happen to enjoy programming in languages that provide GC,  
and was pretty heavily involved in almost all of the above.

- Ed

Re: memory management and productivity

[Russ]

"Ed Falis" <falis@verizon.net> wrote in message news:<opr97e5lkh5afhvo@localhost>...
> On 25 Jun 2004 16:35:53 -0700, Russ <18k11tm001@sneakemail.com> wrote:
> 
> > Yup. Look at the amazing popularity of Java. I would venture to say
> > that it is due, in large part, to Java's garbage collection.
> 
> 
> Unfortunately, there are counter-arguments to this conjecture, anyway.
> 
> Consider Eiffel, a very nice language, quite Ada-like in many ways, with  
> garbage collection and several innovative features (eg design by  
> contract).  It is not as popular or as widely used as Ada.
> 
> Consider that both Aonix (from Intermetrics/Averstar) and AdaCore provided  
> Ada compilers for the JVM, including garbage collection and robust  
> bindings to the  Java class libraries.  Neither was commercially  
> successful.

Part of the problem, as I see it, is that open-source developers now
expect their compiler to be free -- as in beer. So do students. That
is a real dilemma for compiler vendors, of course, and I don't envy
them.

But now that the Ada->JVM compilers have been determined to be
commercially unviable, is it conceivable that they could be
open-sourced and made available for free -- as in beer *and* speech?

Why waste all the effort that went into them? Perhaps a free Ada->JVM
compiler with robust bindings to the Java class libraries might be a
key to a revival of Ada. Then again, maybe not. But if not, the
prospects for a revival of Ada seem rather bleak.

Re: memory management and productivity

[Ludovic Brenta]

Russ writes:
> Part of the problem, as I see it, is that open-source developers now
> expect their compiler to be free -- as in beer. So do students. That
> is a real dilemma for compiler vendors, of course, and I don't envy
> them.
>
> But now that the Ada->JVM compilers have been determined to be
> commercially unviable, is it conceivable that they could be
> open-sourced and made available for free -- as in beer *and* speech?
>
> Why waste all the effort that went into them? Perhaps a free
> Ada->JVM compiler with robust bindings to the Java class libraries
> might be a key to a revival of Ada. Then again, maybe not. But if
> not, the prospects for a revival of Ada seem rather bleak.

JGNAT is free.  Anyone interested can get it at no cost, use it for
any purpose they wish, change it, and redistribute it along with their
changes.  So, nothing is lost :)

-- 
Ludovic Brenta.

Re: memory management and productivity

[Dmitry A. Kazakov]

On Sat, 26 Jun 2004 23:36:06 +0200, Ludovic Brenta wrote:

> Russ writes:
>> Part of the problem, as I see it, is that open-source developers now
>> expect their compiler to be free -- as in beer. So do students. That
>> is a real dilemma for compiler vendors, of course, and I don't envy
>> them.
>>
>> But now that the Ada->JVM compilers have been determined to be
>> commercially unviable, is it conceivable that they could be
>> open-sourced and made available for free -- as in beer *and* speech?
>>
>> Why waste all the effort that went into them? Perhaps a free
>> Ada->JVM compiler with robust bindings to the Java class libraries
>> might be a key to a revival of Ada. Then again, maybe not. But if
>> not, the prospects for a revival of Ada seem rather bleak.
> 
> JGNAT is free.  Anyone interested can get it at no cost, use it for
> any purpose they wish, change it, and redistribute it along with their
> changes.  So, nothing is lost :)

And nothing happens, alas!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: memory management and productivity

[Robert I. Eachus]

Russ wrote:

> I don't know much about memory management or garbage collection, but I
> do know that it is considered a great benefit of Java and many other
> languages. Whatever Ada provides in this regard should be optional at
> the discretion of the *developer* (not the compiler vendor), and it
> should be at least as good as the GC in Java for those who choose to
> use it that way...

> I think you are missing a huge point here. The advantages of automatic
> memory management are that it is (1) convenient for the developer and
> (2) much more reliable, just as the automatic array bounds checking is
> more reliable than a developer's hand-rolled bounds checking.
> 
> You may neither want or need it for your application, and you
> shouldn't be forced to use it, but the desktop and web developers
> should always have it available if they want it. They shouldn't be
> denied a valuable feature just because you don't want it.

I think you are just not hearing what is being said.  Let me try saying 
it this way.

1) Garbage collection is of great benefit in many languages.
2) Automatic memory management is a big advantage for some programmmers 
and some programs.

So far, so good. But...

3) Ada programmers like the automatic memory management that is a part 
of Ada, and don't particularly care for garbage collection.

Is the memory management that is part of Ada perfect for all 
applications?  No, in fact there are many AI algorithms that work better 
in a garbage collection environment.  Personally I would accept the 
slight extra work of implementing such an algorithm in Ada using 
controlled objects rather than use Java or Lisp.  But that is because 
the cost of doing the memory management that way is to me much, much 
smaller than the debugging advantages of using Ada. Of course, I also 
get predictable timing by using Ada. YMMV.

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: memory management and productivity

[David Starner]

On Thu, 24 Jun 2004 12:26:34 -0700, Russ wrote:

> please
> don't complain about the fact that Java dwarfs Ada in popularity 

Ada with Java's garbage collection was offered for sale. There were
no takers. That indicates to me that the problem is far beyond technical
issues; Ada's reputation and past history, compared with Sun's marketing
savvy, linking Java with the Internet and now a large base of available
Java tools is much more important.
 
> (and
> is now being adapted big-time for real-time use by the military).

Which is a crying shame. The military still uses Vietnam-era planes but
won't commit to the programming language they commissioned for any period
of time. 

Re: memory management and productivity

[Larry Kilgallen]

In article <1088086179.73158@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Stephen Leake wrote:
>> I prefer to manage memory according to the needs of my algorithms and
>> applications, rather than letting some unknown algorithm attempt to do
>> it for me.
> 
> I prefer to manage registers according to the needs of my algorithms and
> applications, rather than letting some unknown algorithm attempt to do it
> for me. That's why I'll never use FORTRAN!

You should switch to Bliss, which gives a lot of higher level looping
constructs, excellent macro facilities, and the opportunity to micro-
manage register usage.

Re: memory management and productivity

[Martin Krischik]

Russ wrote:

> "Martin Dowie" <martin.dowie@baesystems.com> wrote in message
> news:<40d69121$1_1@baen1673807.greenlnk.net>...
>> "Russ" <18k11tm001@sneakemail.com> wrote in message
>> news:bebbba07.0406202016.1f15c133@posting.google.com...
>> > Well, if initialize and finalize are fundamentally no different than
>> > constructors and destructors, then I conclude that Ada does not have
>> > automated memory management any more than C++ has it. (I may be a bit
>> > slow, but I catch on eventually.)
>> >
>> > As for using a library that has memory management built in, that
>> > sounds great. I'd just feel a bit better about it if it were in a
>> > standard library that everyone agrees on and comes with the language,
>> > like STL in C++. Then you could honestly say that Ada has automated
>> > memory management built in. (And it would be better than Java's
>> > because it would be optional.)
>> 
>> Ada does not forbid an implementation for performing GC but there
>> has been zero customer call for it. That's no too surprising - "Sorry,
>> you can't apply brakes/launch missile/shutdown reactor as I'm busy
>> garbage collecting." would not go done well.
> 
> Are you saying that an Ada compiler can implement GC or not? That
> seems a bit inconsistent to me. How can the same language have it both
> ways? What if someone tries to port an Ada application that has its
> own memory management to an Ada compiler that already has it by
> default? I would think you would at least want it controlled by a
> compilation flag or some something.

That's what "pragma Controlled ()" is for. Which is even better then a
compiler flag.
 
>> But for desktop apps or even business apps, it might well be appropriate.
> 
> Which is why it should be under control of the application developer,
> it seems to me.

Well it is.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: memory management and productivity

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
: Are you saying that an Ada compiler can implement GC or not?

Have you had a look at storage pools?

Re: memory management and productivity

[Robert I. Eachus]

Russ wrote:

> Are you saying that an Ada compiler can implement GC or not? That
> seems a bit inconsistent to me. How can the same language have it both
> ways? What if someone tries to port an Ada application that has its
> own memory management to an Ada compiler that already has it by
> default? I would think you would at least want it controlled by a
> compilation flag or some something.

Symbolics had an Ada compiler for their systems, which had global 
garbage collection.  I'm not sure about the R1000 Rational hardware.

But in any case, this has been the history of global garbage collection 
in Ada.  If the OS supports it, the compiler will do what is necessary 
to run in that environment.  But it is seen more as an extra development 
cost than a desired feature.  (I'm not saying that is why Symbolics went 
bankrupt.  But if there was a big market for Ada with garbage 
collection, Symbolics might still be in business.)

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: memory management and productivity

[Dmitry A. Kazakov]

On 20 Jun 2004 21:16:16 -0700, 18k11tm001@sneakemail.com (Russ) wrote:

>Well, if initialize and finalize are fundamentally no different than
>constructors and destructors, then I conclude that Ada does not have
>automated memory management any more than C++ has it. (I may be a bit
>slow, but I catch on eventually.)

The difference is that in Ada there is much lesser need in objects
allocated in the heap. That makes things a lot easier and safer.
Moreover it is also much more efficient, especially in a parallel
environment.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: memory management and productivity

[Christoph Karl Walter Grein]

> I get this:
> 
> Initialize
> Finalize
> Finalize
> Wibble
> Finalize
> Finalize
> 
> and I'm impressed because I didn't knew these differences. I must 
> however admit that I don't understand exactly what's happening and gvd 
> sigfaults on me (w2000). Could you provide a short explanation please?

The relevant chapter in the RM is not easy to understand. So find here a commented example of initialisation/adjustment/finalization:

http://home.t-online.de/home/christ-usch.grein/AdaMagica/Secretive.html
____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist 
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200

Re: memory management and productivity

[Jano]

Christoph Karl Walter Grein wrote:

>>I get this:
>>
>>Initialize
>>Finalize
>>Finalize
>>Wibble
>>Finalize
>>Finalize
>>
>>and I'm impressed because I didn't knew these differences. I must 
>>however admit that I don't understand exactly what's happening and gvd 
>>sigfaults on me (w2000). Could you provide a short explanation please?
> 
> 
> The relevant chapter in the RM is not easy to understand. So find here a commented example of initialisation/adjustment/finalization:
> 
> http://home.t-online.de/home/christ-usch.grein/AdaMagica/Secretive.html

Thanks!