From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ade59281d0eea302 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!l77g2000hsb.googlegroups.com!not-for-mail From: "andrew.carroll@okstate.edu" Newsgroups: comp.lang.ada Subject: Re: STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW Date: 12 Apr 2007 06:48:01 -0700 Organization: http://groups.google.com Message-ID: <1176385681.104884.119930@l77g2000hsb.googlegroups.com> References: <1175494388.509572.267790@l77g2000hsb.googlegroups.com> NNTP-Posting-Host: 139.78.128.110 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1176385681 15505 127.0.0.1 (12 Apr 2007 13:48:01 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 12 Apr 2007 13:48:01 +0000 (UTC) In-Reply-To: <1175494388.509572.267790@l77g2000hsb.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: l77g2000hsb.googlegroups.com; posting-host=139.78.128.110; posting-account=Kq9unQ0AAADh_grEViI3JGqegXKDDjxt Xref: g2news1.google.com comp.lang.ada:14934 Date: 2007-04-12T06:48:01-07:00 List-Id: 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