Re: STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW



S.I.T.R.E.P

I changed the GPS compiler to Ada95 and fixed any compiler errors.
Once I did that (and without using dispatching or abstract types) I
was able to get the program _working_, again. I made some other
changes to the overall design. The schema type now has it's own file
for 'input and 'output so I don't have to read past it in the file
that contains the tuples. I implemented accessor methods (set and
get) for the attributes of the attribute types and extentions. So I
have getValue, setValue...

After all that was working I changed the attribute type to be abstract
and all it's methods to be abstract and implemented the to_disc
procedure again (dispatching for writing to disk). That part worked.

After that I tried to implement the from_disc function (dispatching
from the disk). Problem with this one is that when I used it, the
context of the call is for an attribute type and of course attribute
is abstract and therefore cannot be instantiated. Here is a small
example:

attrib : attribute_ptr;
....
attrib.all := from_disc(fin, obj_of_desired_attribute_class.all)

but in order to do this, attrib has to be "not null" like the
following

attrib: attribute_ptr;
....
attrib := new attribute;
attrib.all := from_disc(fin, obj_of_desired_attribute_class.all)

and of course the type attribute is abstract so it cannot be
instantiated.


So I removed the abstract and implemented the methods for the
attribute type. Now I can do:

attrib: attribute_ptr;
....
attrib := new attribute;
attrib.all := from_disc(fin, obj_of_desired_attribute_class.all);

but, it only ever dispatches to the from_disc of attribute even though
I've supplied an object of booleanattribute or stringattribute or
dateattribute or integerattribute as the actual parameter. So now I
have some questions:

1. If I have the following function defined for attribute type, and
also defined for types extending from attribute type, do they all need
to have attribute'class as the return value so that it dispatches
based on the actual parameter ONLY?

function from_disc(fin :ada.streams.stream_io.file_type; item:
attribute) return attribute;
function from_disc(fin :ada.streams.stream_io.file_type; item:
booleanattribute) return booleanattribute;
function from_disc(fin :ada.streams.stream_io.file_type; item:
integerattribute) return integerattribute;
function from_disc(fin :ada.streams.stream_io.file_type; item:
stringattribute) return stringattribute;
function from_disc(fin :ada.streams.stream_io.file_type; item:
dateattribute) return dateattribute;



The reason the program crashes NOW is because when from_disc is called
it only ever 'inputs an attribute type. An attribute type is smaller
in size than the other attribute extentions. So if the file actually
contains a booleanattribute then 'input will not read the full
booleanattribute; just the attribute. This means that the fin file
pointer is not on end_of_file. So a loop with the following sentinel;
not end_of_file(fin), will not break (exit) when it should because fin
is not at end_of_file and it will try to read another attribute. Of
course for my test cases there is only one attribute in the file but
because we are not at end_of_file the program loops and tries to read
another attribute.

If from_disc were dispatching, then the correct extention of attribute
type would be 'input-ed and the fin file pointer would be at end of
file, the loop would exit properly and things would be okay.

Am I making any sense?

Andrew



.