Weird controlled behavior - Gnat 3.15p NT

Weird controlled behavior - Gnat 3.15p NT

[Jano]

Hello,

see the following type declarations and lines of code:

   type Object is abstract new 
      Finalization.Controlled with null record;
   type Object_access is access all Object'Class;

   procedure Initialize (This : in out Object) is
   begin
      Trace.Log ("====>");      
   end Initialize;

   procedure Finalize   (This : in out Object) is
   begin
      Trace.Log ("<====");
   end Finalize;

   declare
      -- THIS LINE IS THE RELEVANT ONE.
      Thing : Object_access := 
         new Object'Class'(Object'Class'Input (Stream));
   begin
      null;
   end;

Ok, running normally or stepping with GVD when the line with the
stream reading is executed I get the following log:

====>
<====
<====
<====

Compiled with -O2 and without it if that means something. Consistently
with each object in the stream.

Now, I would assume that no Finalization could happen without a
corresponding Initialization, so is this normal? Is something wrong in
that read way?

Regards,

A. Mosteo.

Re: Weird controlled behavior - Gnat 3.15p NT

[Martin Krischik]

Jano wrote:

> Hello,
> 
> see the following type declarations and lines of code:
> 
>    type Object is abstract new
>       Finalization.Controlled with null record;
>    type Object_access is access all Object'Class;
> 
>    procedure Initialize (This : in out Object) is
>    begin
>       Trace.Log ("====>");
>    end Initialize;

Try to add:

procedure Adjust (This : in out Object) is
   begin
     Trace.Log ("<===>");
   end Adjust;

and Test again.

>    procedure Finalize   (This : in out Object) is
>    begin
>       Trace.Log ("<====");
>    end Finalize;
> 
>    declare
>       -- THIS LINE IS THE RELEVANT ONE.
>       Thing : Object_access :=
>          new Object'Class'(Object'Class'Input (Stream));
>    begin
>       null;
>    end;
> 
> Ok, running normally or stepping with GVD when the line with the
> stream reading is executed I get the following log:
> 
> ====>
> <====
> <====
> <====
> 
> Compiled with -O2 and without it if that means something. Consistently
> with each object in the stream.
> 
> Now, I would assume that no Finalization could happen without a
> corresponding Initialization, so is this normal? Is something wrong in
> that read way?

Yes, types may be Adjusted without Initialization. Has been (and still is) 
a major headache in the design of AdaCL.Trace
(http://adacl.sourceforge.net/html/______Include__AdaCL-Trace__adb.htm).

With Regards

Martin

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

Re: Weird controlled behavior - Gnat 3.15p NT

[Patrice Freydiere]

On Thu, 04 Sep 2003 08:25:41 +0000, Jano wrote:

> Hello,
> 
> see the following type declarations and lines of code:
> 
>    type Object is abstract new 
>       Finalization.Controlled with null record;
>    type Object_access is access all Object'Class;
> 
>    procedure Initialize (This : in out Object) is
>    begin
>       Trace.Log ("====>");      
>    end Initialize;
> 
>    procedure Finalize   (This : in out Object) is
>    begin
>       Trace.Log ("<====");
>    end Finalize;
> 
>    declare
>       -- THIS LINE IS THE RELEVANT ONE.
>       Thing : Object_access := 
>          new Object'Class'(Object'Class'Input (Stream));
>    begin
>       null;
>    end;
> 
> Ok, running normally or stepping with GVD when the line with the
> stream reading is executed I get the following log:
> 
> ====>
> <====
> <====
> <====
> 
> Compiled with -O2 and without it if that means something. Consistently
> with each object in the stream.
> 
> Now, I would assume that no Finalization could happen without a
> corresponding Initialization, so is this normal? Is something wrong in
> that read way?
> 
> Regards,
> 
> A. Mosteo.


is it related to assign ?? 
can you log assign call , for the controlled type ?? 

Patrice

Re: Weird controlled behavior - Gnat 3.15p NT

[Jano]

Patrice Freydiere dice...
> On Thu, 04 Sep 2003 08:25:41 +0000, Jano wrote:
> 
> > Hello,
> > 
> > see the following type declarations and lines of code:
> > 
> >    type Object is abstract new 
> >       Finalization.Controlled with null record;
> >    type Object_access is access all Object'Class;
> > 
> >    procedure Initialize (This : in out Object) is
> >    begin
> >       Trace.Log ("====>");      
> >    end Initialize;
> > 
> >    procedure Finalize   (This : in out Object) is
> >    begin
> >       Trace.Log ("<====");
> >    end Finalize;
> > 
> >    declare
> >       -- THIS LINE IS THE RELEVANT ONE.
> >       Thing : Object_access := 
> >          new Object'Class'(Object'Class'Input (Stream));
> >    begin
> >       null;
> >    end;
> > 
> > Ok, running normally or stepping with GVD when the line with the
> > stream reading is executed I get the following log:
> > 
> > ====>
> > <====
> > <====
> > <====
> > 
> > Compiled with -O2 and without it if that means something. Consistently
> > with each object in the stream.
> > 
> > Now, I would assume that no Finalization could happen without a
> > corresponding Initialization, so is this normal? Is something wrong in
> > that read way?
> > 
> > Regards,
> > 
> > A. Mosteo.
> 
> 
> is it related to assign ?? 
> can you log assign call , for the controlled type ?? 

Assign isn't overloaded, but I'll try it to see what happens.

Re: Weird controlled behavior - Gnat 3.15p NT

[Jano]

Jano dice...
> Patrice Freydiere dice...
> > On Thu, 04 Sep 2003 08:25:41 +0000, Jano wrote:
> > 
> > > Hello,
> > > 
> > > see the following type declarations and lines of code:
> > > 
> > >    type Object is abstract new 
> > >       Finalization.Controlled with null record;
> > >    type Object_access is access all Object'Class;
> > > 
> > >    procedure Initialize (This : in out Object) is
> > >    begin
> > >       Trace.Log ("====>");      
> > >    end Initialize;
> > > 
> > >    procedure Finalize   (This : in out Object) is
> > >    begin
> > >       Trace.Log ("<====");
> > >    end Finalize;
> > > 
> > >    declare
> > >       -- THIS LINE IS THE RELEVANT ONE.
> > >       Thing : Object_access := 
> > >          new Object'Class'(Object'Class'Input (Stream));
> > >    begin
> > >       null;
> > >    end;
> > > 
> > > Ok, running normally or stepping with GVD when the line with the
> > > stream reading is executed I get the following log:
> > > 
> > > ====>
> > > <====
> > > <====
> > > <====
> > > 
> > > Compiled with -O2 and without it if that means something. Consistently
> > > with each object in the stream.
> > > 
> > > Now, I would assume that no Finalization could happen without a
> > > corresponding Initialization, so is this normal? Is something wrong in
> > > that read way?
> > > 
> > > Regards,
> > > 
> > > A. Mosteo.
> > 
> > 
> > is it related to assign ?? 
> > can you log assign call , for the controlled type ?? 
> 
> Assign isn't overloaded, but I'll try it to see what happens.

Well, the sequence with Assign traced is:

====> (Initialize)
=***= (Adjust)
<==== (Finalize)
=***=
=***=
<====
<====

and that for each read item.

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: Weird controlled behavior - Gnat 3.15p NT

[Preben Randhol]

Jano wrote:
> Patrice Freydiere dice...

Please, both of you, cut down on the text you are quoting. There are a
hundred lines of quoted text and one line of answer.

Preben
-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: Weird controlled behavior - Gnat 3.15p NT

[Jano]

Preben Randhol dice...
> Jano wrote:
> > Patrice Freydiere dice...
> 
> Please, both of you, cut down on the text you are quoting. There are a
> hundred lines of quoted text and one line of answer.

I use to do that, in this case was just for preserving the example... 
and whereas sometimes the messages get lost.

Sorry for the trouble.

Re: Weird controlled behavior - Gnat 3.15p NT

[Robert I. Eachus]

Jano wrote:

> Now, I would assume that no Finalization could happen without a
> corresponding Initialization, so is this normal? Is something wrong in
> that read way?

No object can be finalized that has not been initialized (or created as 
part of an assignment with adjust), but there are a number of situations 
where even a limited object may be finalized several times.  I won't go 
into the gory details, I think they are all in the Ada 95 Rationale. 
But you should always either design things so that multiple finalization 
is harmless, or you check in the finalization operation whether the 
object has already been finalized.  For example if your Finalize 
procedure contains a call to Unchecked_Deallocation for an access value 
in the object, be sure to pass the value directly, not a copy, so it 
gets set to null.

--
                                           Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Weird controlled behavior - Gnat 3.15p NT

[Randy Brukardt]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F57B071.5030206@attbi.com...
> Jano wrote:
>
> > Now, I would assume that no Finalization could happen without a
> > corresponding Initialization, so is this normal? Is something wrong in
> > that read way?
>
> No object can be finalized that has not been initialized (or created as
> part of an assignment with adjust)...

No, that's not right either.
Finalizable objects can be "initialized" three ways:
    -- Default initialization followed by a call to Initialize.
    -- Explicit initialization followed by a call to Adjust.
    -- Aggregate initialization.

Note that the latter doesn't call anything. Also note that an abstraction
can make the last illegal by declaring the type as a private type.

In this case, it looks like GNAT is assigning temporaries, so there is a bit
copy, followed by an Adjust call, and then a Finalize call for the
temporary. That accounts for the "extra" calls. For a non-limited controlled
type, you have to account for all three routines; they can get used
implicitly even if you never wrote any assignments.

Finally, Robert's basic point is correct: Finalize should always be designed
to be called "extra" times on an object. I usually use something like:

    procedure Finalize (Obj : in out Object_Type) is
    begin
        if Obj.Inited then
            -- Finalize code.
            Obj.Inited := False;
        -- else not Initialized or already Finalized.
        end if;
    end Finalize;

with Initialize setting the Initted flag. (Often, I use some data in the
record for this purpose, rather than a dedicated flag; such as an allocated
block of memory [if the pointer is null, the object is already Finalized].)

                  Randy.

Re: Weird controlled behavior - Gnat 3.15p NT

[Jano]

Randy Brukardt dice...
> "Robert I. Eachus" <rieachus@attbi.com> wrote in message
> news:3F57B071.5030206@attbi.com...
> (...)
> Finally, Robert's basic point is correct: Finalize should always be designed
> to be called "extra" times on an object. I usually use something like:

Thanks for the answers, that's what happens when I assume something. 
Fortunately it wasn't a great deal, I was only counting existing objects 
for statistical purposes.

Re: Weird controlled behavior - Gnat 3.15p NT

[Dmitry A. Kazakov]

On Fri, 5 Sep 2003 15:48:07 +0200, Jano <nono@celes.unizar.es> wrote:

>Randy Brukardt dice...
>> "Robert I. Eachus" <rieachus@attbi.com> wrote in message
>> news:3F57B071.5030206@attbi.com...
>> (...)
>> Finally, Robert's basic point is correct: Finalize should always be designed
>> to be called "extra" times on an object. I usually use something like:
>
>Thanks for the answers, that's what happens when I assume something. 
>Fortunately it wasn't a great deal, I was only counting existing objects 
>for statistical purposes.

I suppose your code would work if the objects were limited controlled.
Otherwise, it is probably not very reasonable to count them. It is
much like counting numeric literals. (:-))

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

Re: Weird controlled behavior - Gnat 3.15p NT

[Hyman Rosen]

Robert I. Eachus wrote:
 > there are a number of situations where even a limited object
 > may be finalized several times

It's important to point this out to new Ada programmers who are
coming from C++, since this is a major difference in the languages.
In C++, an object's constructor and destructor are called exactly
once, so an object never needs to keep track internally if it has
been initialized or finalized.

Re: Weird controlled behavior - Gnat 3.15p NT

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]


"Hyman Rosen" <hyrosen@mail.com> a �crit dans le message de news:pwa7b.8484$w41.5873@nwrdny02.gnilink.net...
> Robert I. Eachus wrote:
>  > there are a number of situations where even a limited object
>  > may be finalized several times
>
> It's important to point this out to new Ada programmers who are
> coming from C++, since this is a major difference in the languages.
> In C++, an object's constructor and destructor are called exactly
> once, so an object never needs to keep track internally if it has
> been initialized or finalized.
>
And what happens in C++ when an exception is raised by a destructor,
for this object and for objects not yet finalized?

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Weird controlled behavior - Gnat 3.15p NT

[Hyman Rosen]

Jean-Pierre Rosen wrote:
> And what happens in C++ when an exception is raised by a destructor,
> for this object and for objects not yet finalized?

It is considerd very bad design in C++ to allow exceptions to escape
from destructors, because of the poor semantic meaning of such a thing.
(While you may fail to construct something and so have no object, when
the compiler says it's time to destroy something, it's gone.)

In any case, should an exception be thrown from a destructor, the code
goes on to call destructors for the remaining completely constructed
subobjects of the throwing object, if any, then for other objects whose
lifetimes are ending due to the scope being exited because of the thrown
exception. Should one of those destructors again throw, the special global
function terminate() is called, and the program ends.

I believe that in similar circumstances, Ada does all the finalizations
and then raises Program_Error, so in both languages, Don't Do That (tm).

Re: Weird controlled behavior - Gnat 3.15p NT

[Dmitry A. Kazakov]

On Tue, 09 Sep 2003 02:01:57 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Robert I. Eachus wrote:
> > there are a number of situations where even a limited object
> > may be finalized several times
>
>It's important to point this out to new Ada programmers who are
>coming from C++, since this is a major difference in the languages.
>In C++, an object's constructor and destructor are called exactly
>once, so an object never needs to keep track internally if it has
>been initialized or finalized.

Really? What about this:

class Foo
{
public :
   void Surprise () { this->Foo::~Foo (); }
   virtual ~Foo ();
};

You might say that the above is rubbish. Not at all. It is a design
pattern for self-destructing objects. For instance when you
encapsulate a window to an object which destroys itself upon closing
the window. Now imagine what should happen if somebody would allocate
Foo on the stack? Access violation.

Another example is when an object is put into DLL in a shared section.
Then it will be constructed over an over again, each time a new
process maps the DLL. And not surprisingly it will be also destructed
many many times. A nice feature to fight with.

---
Both Ada and C++ have this nasty problem, namely, an ability to
explicitly call parts of constructors / destructors. It is a nightmare
for a software designer. But there are many reasons why it was made
so. Some of them are not very convincing (to me). Future generations
of OO languages will hopefully solve this better.

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

Re: Weird controlled behavior - Gnat 3.15p NT

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> You might say that the above is rubbish. Not at all. It is a design
> pattern for self-destructing objects.

Not at all. It's a well-known and good pattern, as you say.

> Now imagine what should happen if somebody would allocate
> Foo on the stack?

Undefined behavior. You are not allowed to do that, and if you do,
the behavior of the program is unspecifed by the language. (The
workaround is to make the destructor protected, by the way. Then the
compiler will prevent such objects from being allocated on the stack,
because the destructor will be inaccessible.)

If you call a destructor yourself, you must make sure that the
compiler will not call the destructor again on that object (which in
fact no longer exists, except as a region of storage with undefined
contents).

Re: Weird controlled behavior - Gnat 3.15p NT

[Dmitry A. Kazakov]

On Thu, 11 Sep 2003 03:46:56 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> You might say that the above is rubbish. Not at all. It is a design
>> pattern for self-destructing objects.
>
>Not at all. It's a well-known and good pattern, as you say.
>
>> Now imagine what should happen if somebody would allocate
>> Foo on the stack?
>
>Undefined behavior. You are not allowed to do that, and if you do,
>the behavior of the program is unspecifed by the language. (The
>workaround is to make the destructor protected, by the way. Then the
>compiler will prevent such objects from being allocated on the stack,
>because the destructor will be inaccessible.)
>
>If you call a destructor yourself, you must make sure that the
>compiler will not call the destructor again on that object (which in
>fact no longer exists, except as a region of storage with undefined
>contents).

As you see the problem exists. The source is an ability to call a
destructor explicitly and also an ability to call them from the
methods. For many reasons, it is widely used, but it is a very
dangerous and bad thing.

From design point of view, constructor and destructor should be
invisible from the methods. They are not methods and are not a part of
the interface.

That we have to do such things both in Ada and C++ is a deficiency.
However, I cannot say how to avoid it in all cases.

In case of self-destructing objects, there is a safe alternative
solution: smart pointers + object reference counts. Unfortunately both
Ada and C++ do not allow an effective, "coder-friendly", transparent
implementation of smart pointers. For example, Ada has
half-transparent access types, but no user-defined ones, etc.

And do not tell me stories about templates! (:-)) Only a full-blown
ADT may help to solve the problem!

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

Re: Weird controlled behavior - Gnat 3.15p NT

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 523 bytes --]


"Jano" <402450@cepsz.unizar.es> a �crit dans le message de news:5d6fdb61.0309040725.3403aa29@posting.google.com...

> Now, I would assume that no Finalization could happen without a
> corresponding Initialization, so is this normal? Is something wrong in
> that read way?
>
No, the magic formula is:
Nb (Finalize) = Nb (Initialize) + Nb (Adjust) + Nb (Aggregates)


-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr