* Re: Program_Error because of Finalization. [not found] <39C3B125.209C0440@acm.org> @ 2000-09-17 0:00 ` Laurent Guerby 2000-09-17 0:00 ` Marin David Condic 0 siblings, 1 reply; 4+ messages in thread From: Laurent Guerby @ 2000-09-17 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Program_Error because of Finalization. 2000-09-17 0:00 ` Program_Error because of Finalization Laurent Guerby @ 2000-09-17 0:00 ` Marin David Condic 2000-09-19 0:00 ` Tucker Taft 0 siblings, 1 reply; 4+ messages in thread From: Marin David Condic @ 2000-09-17 0:00 UTC (permalink / raw) 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. ====================================================================== ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Program_Error because of Finalization. 2000-09-17 0:00 ` Marin David Condic @ 2000-09-19 0:00 ` Tucker Taft 2000-09-19 0:00 ` Laurent Guerby 0 siblings, 1 reply; 4+ messages in thread From: Tucker Taft @ 2000-09-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Program_Error because of Finalization. 2000-09-19 0:00 ` Tucker Taft @ 2000-09-19 0:00 ` Laurent Guerby 0 siblings, 0 replies; 4+ messages in thread From: Laurent Guerby @ 2000-09-19 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-09-19 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <39C3B125.209C0440@acm.org> 2000-09-17 0:00 ` Program_Error because of Finalization Laurent Guerby 2000-09-17 0:00 ` Marin David Condic 2000-09-19 0:00 ` Tucker Taft 2000-09-19 0:00 ` Laurent Guerby
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox