Re: Program_Error because of Finalization.

Re: Program_Error because of Finalization.

[Laurent Guerby]

Marin David Condic <mcondic.nospam@acm.org> writes:
> O.K., This one is a bit long. I'm having trouble using the Stream_IO
> facilities to input and output a class-wide type that is referenced with
> an access object. Basically, it works just fine so long as a) the object
> is just a static declaration with no pointer or b) I do not derive the
> class from Ada.Finalization. The smallest example I could come up with
> is here: [...]

Ada.Finalization.Controlled is likely to have some pointers in it, and
so using the predefined read/input attribute to build such an object from a
binary image is likely to cause havoc. The solution is to redefine
the stream attributes for your object to bypass the predefined ones.

I remember myself mentionning this issue (stream attribute on Controlled)
to the standard list while I was working on the distributed annex, but
I don't remember if some AI was issued or not.

Also, you might want to change

procedure Load (File: in out ASIO.File_Type ; Obj : in out Some_Type'Class) ;

to a function returning a class-wide type, since with the procedure
version, the tag will be determined by the caller actual and you
won't be able to change it inside Load.

declare
   X : Some_Type'Class := Load (F);
begin
  --...
end;

-- 
Laurent Guerby <guerby@acm.org>

Re: Program_Error because of Finalization.

[Marin David Condic]

Laurent Guerby wrote:

> Ada.Finalization.Controlled is likely to have some pointers in it, and
> so using the predefined read/input attribute to build such an object from a
> binary image is likely to cause havoc. The solution is to redefine
> the stream attributes for your object to bypass the predefined ones.
>

That is exactly what I was trying to avoid. I'd like to use the normal
dispatching mechanism and the default Input/Output mechanism so that most classes
derived from the root wouldn't have to do anything to redefine stream input and
output.  Anything that doesn't use complex data structures just gets saved and
restored with no programming effort. My understanding (maybe flawed?) is that if
I were to override it in the base class, I'd be forever overriding it in derived
classes. If the Controlled class retains some kind of pointers in it, I can see
why you wouldn't be able to accept the default Input/Output, and hence not want
to derive from it. However, you kind of want to use Finalization as the root so
that just in case a derived class has some structured data you can fix it up
where necessary.

>
> I remember myself mentionning this issue (stream attribute on Controlled)
> to the standard list while I was working on the distributed annex, but
> I don't remember if some AI was issued or not.
>

So there is some kind of language issue here, eh? Well at least I know that it
wasn't just a case of my doing it wrong. I thought perhaps I was just missing
something on the function return value or some such.

What disturbs me is that it works *Just Fine* so long as the parameter is a
static object. Its only when I use something dereferencing a pointer that it gets
messed up. In principle, I should be pointing to a chunk of memory that is of the
right size to contain the next object in the stream. (Assuming I did not mess up
the order of reading and writing) I recall seeing some stuff in the ARM talking
about multiple access paths and depth and many other things beyond my knowledge
and desire to know. Does this maybe have something to do with it? (I've got a
pointer. Ada has a pointer. Too many pointers violates some rule?)

If the access value points to an object of the right type, size and shape - and
still even includes the right tag, why would the function have a problem
assigning the contents of the stream to it? How does Finalization impact this?
Controlled is an abstract type, so it shouldn't contain anything, correct? Or
does it have something to do with deallocating/reallocating the memory I'm
pointing to? I guess I just can't see a reason why it shouldn't work, so I'm a
bit mystified when it blows up.

>
> Also, you might want to change
>
> procedure Load (File: in out ASIO.File_Type ; Obj : in out Some_Type'Class) ;
>
> to a function returning a class-wide type, since with the procedure
> version, the tag will be determined by the caller actual and you
> won't be able to change it inside Load.
>
> declare
>    X : Some_Type'Class := Load (F);
> begin
>   --...
> end;
>

Not sure about exactly what this buys me. If I'm reading the stream and I got
something other than what I expected (as indicated by the caller actual) then I
must have made a programming error or accessed a corrupt file. I'm not clear
about why I would want to read the stream and pull in objects of indeterminate
type. Maybe I'm not thinking outside the box. :-)

My intent here was to duplicate something similar to the "Serialize" functions
found in the Microsoft Foundation Classes. I'd like to have a root object that
handled loading and storing itself to some file and anything derived from it
would automatically have the same capability - possibly overriding the
subprograms as needed. Maybe I need to rethink the approach?

Thanks for the help.

MDC
--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going"

        --  William McChesney Martin, Former Fed chairman, explaining
            what a sound central bank must always do.
======================================================================

Re: Program_Error because of Finalization.

[Tucker Taft]

Marin David Condic wrote:
> ...
> >
> > I remember myself mentionning this issue (stream attribute on Controlled)
> > to the standard list while I was working on the distributed annex, but
> > I don't remember if some AI was issued or not.
> >
> 
> So there is some kind of language issue here, eh? Well at least I know that it
> wasn't just a case of my doing it wrong. I thought perhaps I was just missing
> something on the function return value or some such.
> 
> What disturbs me is that it works *Just Fine* so long as the parameter is a
> static object. Its only when I use something dereferencing a pointer that it gets
> messed up. In principle, I should be pointing to a chunk of memory that is of the
> right size to contain the next object in the stream.
> ...

This looks like a bug.  There is no reason 'Input should fail just
because the type is derived from Controlled.  I suggest you create
a minimal test case that illustrates the problem and send it into
your friendly compiler vendor ;-).  The whole point of 'Input was
to avoid any issues with internal representation.  

There is also a new AI, I believe, which specifically requires that all
non-limited types in language-defined packages behave reasonably
for 'Input/'Output.

> MDC
> --
> ======================================================================
> Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
> Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
> Visit my web site at:  http://www.mcondic.com/
> 
>     "Take away the punchbowl just when the party gets going"
> 
>         --  William McChesney Martin, Former Fed chairman, explaining
>             what a sound central bank must always do.
> ======================================================================

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Program_Error because of Finalization.

[Laurent Guerby]

Tucker Taft <stt@averstar.com> writes:
> [...] There is also a new AI, I believe, which specifically requires that all
> non-limited types in language-defined packages behave reasonably
> for 'Input/'Output.

Does someone have a reference for the AI?

-- 
Laurent Guerby <guerby@acm.org>