Re: Program_Error because of Finalization.

[Marin David Condic <mcondic.nospam@acm.org>]

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.
======================================================================