* 'Read for pointers @ 2000-07-26 0:00 Ted Dennison 2000-07-26 0:00 ` Pat Rogers ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Ted Dennison @ 2000-07-26 0:00 UTC (permalink / raw) I've seen it suggested in several places to handle Stream writing of pointers by writing what the pointer points to instead. That's simple enough. But say I want to make this automatic. Lets say I have a pointer type declared thusly: package Example is type Handle is private; ... private type Instance; type Handle is access all Instance; end Example; The user doesn't even really know or care that Handle is really a pointer. But they may need to do stream I/O with it. The obvious solution is to create my own 'Write and 'Read routines for Handle. But there's a problem. Following is the profile for 'Read: procedure Read (Stream : access Ada.Streams.Root_Stream_Type'Class; Item : out Handle ); for Handle'Read use Read; The problem is that Item is an *out* parameter. That means I won't have acces to the pointer's old value inside Read. There's no way I can put the newly read data from the stream into the Instance that Handle currently points to! I see two possible solutions to this: 1) Redefine "Handle" to be a record with a single pointer field for Instance in it. 2) Provide my own Read routine with an "in" or "in out" parameter for Handle, then warn the user with copious comments not to use 'Read. This may involve them writing their own 'Read for their compound objects to prevent their users from transitivly calling Handle'Read. I'm not too fond of either solution. It would have been nice if Read used "in out" instead. Does anyone have any other solutions? -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-26 0:00 'Read for pointers Ted Dennison @ 2000-07-26 0:00 ` Pat Rogers 2000-07-26 0:00 ` tmoran 2000-07-27 0:00 ` Ted Dennison 2000-07-26 0:00 ` Pat Rogers 2000-07-28 0:00 ` Stephen Leake 2 siblings, 2 replies; 19+ messages in thread From: Pat Rogers @ 2000-07-26 0:00 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:8lndgv$1om$1@nnrp1.deja.com... > I've seen it suggested in several places to handle Stream writing of > pointers by writing what the pointer points to instead. That's simple > enough. > > But say I want to make this automatic. Lets say I have a pointer type > declared thusly: > > package Example is > type Handle is private; > > ... > private > > type Instance; > > type Handle is access all Instance; > > end Example; > > The user doesn't even really know or care that Handle is really a > pointer. But they may need to do stream I/O with it. > > The obvious solution is to create my own 'Write and 'Read routines for > Handle. But there's a problem. Following is the profile for 'Read: > > procedure Read > (Stream : access Ada.Streams.Root_Stream_Type'Class; > Item : out Handle > ); > for Handle'Read use Read; > > The problem is that Item is an *out* parameter. That means I won't have > acces to the pointer's old value inside Read. There's no way I can put > the newly read data from the stream into the Instance that Handle > currently points to! Further to my previous post, to the effect that one can indeed read mode out parameters: the access value of the actual is copied into the formal, so you get a meaningful value coming in even though the mode is out. See RM 6.4.1{12,13} -- Pat Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-26 0:00 ` Pat Rogers @ 2000-07-26 0:00 ` tmoran 2000-07-26 0:00 ` Pat Rogers 2000-07-27 0:00 ` Ted Dennison 1 sibling, 1 reply; 19+ messages in thread From: tmoran @ 2000-07-26 0:00 UTC (permalink / raw) >Further to my previous post, to the effect that one can indeed read >mode out parameters: the access value of the actual is copied into the >formal, so you get a meaningful value coming in even though the mode >is out. See RM 6.4.1{12,13} So to catch bugs at an early time, given type Handle_Type is access ... procedure p(x : some_stuff; Handle : out Handle_Type); one should Handle := null; p(y, Handle); otherwise a supposedly new object at Handle.all may actually be an old object. That must be fun to debug. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-26 0:00 ` tmoran @ 2000-07-26 0:00 ` Pat Rogers 2000-07-27 0:00 ` tmoran 0 siblings, 1 reply; 19+ messages in thread From: Pat Rogers @ 2000-07-26 0:00 UTC (permalink / raw) <tmoran@bix.com> wrote in message news:YEJf5.49$LV1.69164@news.pacbell.net... > >Further to my previous post, to the effect that one can indeed read > >mode out parameters: the access value of the actual is copied into the > >formal, so you get a meaningful value coming in even though the mode > >is out. See RM 6.4.1{12,13} > So to catch bugs at an early time, given > type Handle_Type is access ... > procedure p(x : some_stuff; Handle : out Handle_Type); > one should > Handle := null; > p(y, Handle); > otherwise a supposedly new object at Handle.all may actually be > an old object. That must be fun to debug. I'm not sure I see your point, given the context. The variable Handle, used as the actual to the call to P, would initially have the null value (absent any explicit initialization) automatically. So the value copied in is still meaningful, even if never assigned prior to the call. -- Pat Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-26 0:00 ` Pat Rogers @ 2000-07-27 0:00 ` tmoran 2000-07-26 0:00 ` Pat Rogers 0 siblings, 1 reply; 19+ messages in thread From: tmoran @ 2000-07-27 0:00 UTC (permalink / raw) >I'm not sure I see your point, given the context. The "out" parameter is not set to null so if the procedure has a bug so that it isn't set, it will retain its previous value. Any uninitialized variable bug can be hard to find. But a pointer is especially hard, and in fact most pointers are automatically initialized to null, which helps a lot. Here the "out" parameter pointer in fact points to an internally correct data structure, just the wrong one, or one that might have been deallocated. I think such a bug might take a while to track down. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-27 0:00 ` tmoran @ 2000-07-26 0:00 ` Pat Rogers 0 siblings, 0 replies; 19+ messages in thread From: Pat Rogers @ 2000-07-26 0:00 UTC (permalink / raw) <tmoran@bix.com> wrote in message news:xRLf5.61$M35.39742@news.pacbell.net... > >I'm not sure I see your point, given the context. > The "out" parameter is not set to null so if the procedure has a bug > so that it isn't set, it will retain its previous value. Any > uninitialized variable bug can be hard to find. But a pointer is > especially hard, and in fact most pointers are automatically > initialized to null, which helps a lot. Here the "out" parameter > pointer in fact points to an internally correct data structure, just > the wrong one, or one that might have been deallocated. I think such > a bug might take a while to track down. Having parsed the above a couple of times, let me try to restate what you're saying, just to be sure I understand it. What I believe you're saying -- and if so I agree with it (which is why I question my understanding of it:) -- is this: Given that the value of the actual is copied in for an access type formal parameter of mode out, if the subprogram has a bug such that the formal is not updated then the actual will retain the old value, and this would be a hard bug to find. If that's what you mean I agree, but it is preferable to copying back junk, which can certainly happen with by-copy types other than access types. At least we don't go off into the weeds when dereferencing the pointer. -- Pat Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-26 0:00 ` Pat Rogers 2000-07-26 0:00 ` tmoran @ 2000-07-27 0:00 ` Ted Dennison 2000-07-27 0:00 ` Pat Rogers 1 sibling, 1 reply; 19+ messages in thread From: Ted Dennison @ 2000-07-27 0:00 UTC (permalink / raw) In article <lZIf5.190$wE4.35361@nnrp3.sbc.net>, "Pat Rogers" <progers@NOclasswideSPAM.com> wrote: > "Ted Dennison" <dennison@telepath.com> wrote in message > news:8lndgv$1om$1@nnrp1.deja.com... > > The problem is that Item is an *out* parameter. That means I won't > > have acces to the pointer's old value inside Read. There's no way I > Further to my previous post, to the effect that one can indeed read > mode out parameters: the access value of the actual is copied into the > formal, so you get a meaningful value coming in even though the mode > is out. See RM 6.4.1{12,13} Wow. That's one I would not have guessed. So there's effectively no difference between "out" and "in out" for access types, composite types with discriminants, or record types with default field values? %-} -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-27 0:00 ` Ted Dennison @ 2000-07-27 0:00 ` Pat Rogers 2000-07-27 0:00 ` Ted Dennison 0 siblings, 1 reply; 19+ messages in thread From: Pat Rogers @ 2000-07-27 0:00 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:8lpeog$gvc$1@nnrp1.deja.com... > In article <lZIf5.190$wE4.35361@nnrp3.sbc.net>, > "Pat Rogers" <progers@NOclasswideSPAM.com> wrote: > > > "Ted Dennison" <dennison@telepath.com> wrote in message > > news:8lndgv$1om$1@nnrp1.deja.com... > > > The problem is that Item is an *out* parameter. That means I won't > > > have acces to the pointer's old value inside Read. There's no way I > > > Further to my previous post, to the effect that one can indeed read > > mode out parameters: the access value of the actual is copied into the > > formal, so you get a meaningful value coming in even though the mode > > is out. See RM 6.4.1{12,13} > > Wow. That's one I would not have guessed. So there's effectively no > difference between "out" and "in out" for access types, composite types > with discriminants, or record types with default field values? %-} As long as the latter two happen to be passed by copy (access types always are). -- Pat Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-27 0:00 ` Pat Rogers @ 2000-07-27 0:00 ` Ted Dennison 2000-07-27 0:00 ` Pat Rogers 0 siblings, 1 reply; 19+ messages in thread From: Ted Dennison @ 2000-07-27 0:00 UTC (permalink / raw) In article <HVXf5.612$wE4.155736@nnrp3.sbc.net>, "Pat Rogers" <progers@NOclasswideSPAM.com> wrote: > "Ted Dennison" <dennison@telepath.com> wrote in message > news:8lpeog$gvc$1@nnrp1.deja.com... > > Wow. That's one I would not have guessed. So there's effectively no > > difference between "out" and "in out" for access types, composite > types > > with discriminants, or record types with default field values? %-} > > As long as the latter two happen to be passed by copy (access types > always are). But if they aren't passed by copy, then they have to be passed by reference, right? In that case there would *also* be no difference. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-27 0:00 ` Ted Dennison @ 2000-07-27 0:00 ` Pat Rogers 0 siblings, 0 replies; 19+ messages in thread From: Pat Rogers @ 2000-07-27 0:00 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:8lpo5p$os0$1@nnrp1.deja.com... > In article <HVXf5.612$wE4.155736@nnrp3.sbc.net>, > "Pat Rogers" <progers@NOclasswideSPAM.com> wrote: > > "Ted Dennison" <dennison@telepath.com> wrote in message > > news:8lpeog$gvc$1@nnrp1.deja.com... > > > Wow. That's one I would not have guessed. So there's effectively no > > > difference between "out" and "in out" for access types, composite > > types > > > with discriminants, or record types with default field values? %-} > > > > As long as the latter two happen to be passed by copy (access types > > always are). > > But if they aren't passed by copy, then they have to be passed by > reference, right? In that case there would *also* be no difference. Yeah, good point. -- Pat Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-26 0:00 'Read for pointers Ted Dennison 2000-07-26 0:00 ` Pat Rogers @ 2000-07-26 0:00 ` Pat Rogers 2000-07-28 0:00 ` Stephen Leake 2000-07-28 0:00 ` Stephen Leake 2 siblings, 1 reply; 19+ messages in thread From: Pat Rogers @ 2000-07-26 0:00 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:8lndgv$1om$1@nnrp1.deja.com... > I've seen it suggested in several places to handle Stream writing of > pointers by writing what the pointer points to instead. That's simple > enough. > > But say I want to make this automatic. Lets say I have a pointer type > declared thusly: > > package Example is > type Handle is private; > > ... > private > > type Instance; > > type Handle is access all Instance; > > end Example; > > The user doesn't even really know or care that Handle is really a > pointer. But they may need to do stream I/O with it. > > The obvious solution is to create my own 'Write and 'Read routines for > Handle. But there's a problem. Following is the profile for 'Read: > > procedure Read > (Stream : access Ada.Streams.Root_Stream_Type'Class; > Item : out Handle > ); > for Handle'Read use Read; > > The problem is that Item is an *out* parameter. That means I won't have > acces to the pointer's old value inside Read. There's no way I can put > the newly read data from the stream into the Instance that Handle > currently points to! You can read mode out parameters in Ada 95 (unlike Ada 83). (Am I missing something?) -- Pat Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-26 0:00 ` Pat Rogers @ 2000-07-28 0:00 ` Stephen Leake 2000-07-28 0:00 ` tmoran 2000-07-29 0:00 ` Pat Rogers 0 siblings, 2 replies; 19+ messages in thread From: Stephen Leake @ 2000-07-28 0:00 UTC (permalink / raw) "Pat Rogers" <progers@NOclasswideSPAM.com> writes: > "Ted Dennison" <dennison@telepath.com> wrote in message > news:8lndgv$1om$1@nnrp1.deja.com... > > package Example is > > type Handle is private; > > > > ... > > private > > > > type Instance; > > > > type Handle is access all Instance; > > > > end Example; > > > > But there's a problem. Following is the profile for 'Read: > > > > procedure Read > > (Stream : access Ada.Streams.Root_Stream_Type'Class; > > Item : out Handle > > ); > > for Handle'Read use Read; > > > > The problem is that Item is an *out* parameter. That means I won't > have > > acces to the pointer's old value inside Read. > > You can read mode out parameters in Ada 95 (unlike Ada 83). (Am I > missing something?) Yes, you are missing something. Suppose the user writes: My_Handle : Handle; (somehow, My_Handle is given some value) Read (Stream, My_Handle); The value of My_Handle is _not_ copied to Item at the procedure call. That only happens for "in" or "in out" parameters, not "out" parameters. Inside the body of Read, you can indeed do something like: Foo := Item; This allows refering to a previously assigned Item. It does _not_ provide access to the user's value My_Handle. -- -- Stephe ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-28 0:00 ` Stephen Leake @ 2000-07-28 0:00 ` tmoran 2000-07-29 0:00 ` Pat Rogers 1 sibling, 0 replies; 19+ messages in thread From: tmoran @ 2000-07-28 0:00 UTC (permalink / raw) >The value of My_Handle is _not_ copied to Item at the procedure call. >That only happens for "in" or "in out" parameters, not "out" parameters. with Ada.Streams, Ada.Text_IO, Ada.Text_IO.Text_Streams; procedure Test is type Instance is new Integer; type Handle is access all Instance; procedure Read (Stream : access Ada.Streams.Root_Stream_Type'Class; Item : out Handle ); for Handle'Read use Read; procedure Read (Stream : access Ada.Streams.Root_Stream_Type'Class; Item : out Handle ) is begin Item.all := 2; Item := new Instance; Item.all := 3; end Read; Dummy_File : Ada.Text_IO.File_Type; Dummy_Stream_Access : Ada.Text_IO.Text_Streams.Stream_Access; P, Saved_P : Handle; begin Ada.Text_IO.Open(Dummy_File, Ada.Text_IO.In_File, "dummy"); Dummy_Stream_Access := Ada.Text_IO.Text_Streams.Stream(Dummy_File); P := new Instance; P.all := 1; Saved_P := P; Ada.Text_IO.Put_Line("P.all=" & Instance'image(P.all) & " Saved_P.all=" & Instance'image(Saved_P.all)); Ada.Text_IO.Put_Line("Handle'Read(Dummy_Stream_Access, P);"); Handle'Read(Dummy_Stream_Access, P); Ada.Text_IO.Put_Line("P.all=" & Instance'image(P.all) & " Saved_P.all=" & Instance'image(Saved_P.all)); Ada.Text_IO.Close(Dummy_File); end Test; produces: P.all= 1 Saved_P.all= 1 Handle'Read(Dummy_Stream_Access, P); P.all= 3 Saved_P.all= 2 So Handle'Read not only returned a P to a new Instance with P.all=3, but it also modified the instance previously pointed to by P, setting Saved_P.all=2. Also, if, due to an error, it hadn't done Item := new Instance; then in fact P would still point to the same thing as Saved_P, to the eventual surprise of the programmer. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-28 0:00 ` Stephen Leake 2000-07-28 0:00 ` tmoran @ 2000-07-29 0:00 ` Pat Rogers 2000-07-31 0:00 ` Stephen Leake 1 sibling, 1 reply; 19+ messages in thread From: Pat Rogers @ 2000-07-29 0:00 UTC (permalink / raw) "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:uaef1lxlw.fsf@gsfc.nasa.gov... > "Pat Rogers" <progers@NOclasswideSPAM.com> writes: > > > "Ted Dennison" <dennison@telepath.com> wrote in message > > news:8lndgv$1om$1@nnrp1.deja.com... > > > > package Example is > > > type Handle is private; > > > > > > ... > > > private > > > > > > type Instance; > > > > > > type Handle is access all Instance; > > > > > > end Example; > > > > > > But there's a problem. Following is the profile for 'Read: > > > > > > procedure Read > > > (Stream : access Ada.Streams.Root_Stream_Type'Class; > > > Item : out Handle > > > ); > > > for Handle'Read use Read; > > > > > > The problem is that Item is an *out* parameter. That means I won't > > have > > > acces to the pointer's old value inside Read. > > > > You can read mode out parameters in Ada 95 (unlike Ada 83). (Am I > > missing something?) > > Yes, you are missing something. > > Suppose the user writes: > > My_Handle : Handle; > > (somehow, My_Handle is given some value) > > Read (Stream, My_Handle); > > The value of My_Handle is _not_ copied to Item at the procedure call. > That only happens for "in" or "in out" parameters, not "out" > parameters. Have a look at RM 6.4.1{12,13} for a surprise. -- Pat Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-29 0:00 ` Pat Rogers @ 2000-07-31 0:00 ` Stephen Leake 2000-07-31 0:00 ` Pat Rogers 2000-07-31 0:00 ` Robert A Duff 0 siblings, 2 replies; 19+ messages in thread From: Stephen Leake @ 2000-07-31 0:00 UTC (permalink / raw) "Pat Rogers" <progers@NOclasswideSPAM.com> writes: > "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message > news:uaef1lxlw.fsf@gsfc.nasa.gov... > > Suppose the user writes: > > > > My_Handle : Handle; > > > > (somehow, My_Handle is given some value) > > > > Read (Stream, My_Handle); > > > > The value of My_Handle is _not_ copied to Item at the procedure > call. > > That only happens for "in" or "in out" parameters, not "out" > > parameters. > > Have a look at RM 6.4.1{12,13} for a surprise. I stand corrected. I guess the Ada designers were trying to prevent garbage pointers. I think I'd prefer the standard "initialized to null" behavior here, for consistency. I guess it's easy enough to remember that "out" is the same as "in out" for access types, and composite types with discriminants. On further thought, I can't think of a time when this behavior is actively bad; it's just not what I thought the rules were. -- -- Stephe ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-31 0:00 ` Stephen Leake @ 2000-07-31 0:00 ` Pat Rogers 2000-07-31 0:00 ` Robert A Duff 1 sibling, 0 replies; 19+ messages in thread From: Pat Rogers @ 2000-07-31 0:00 UTC (permalink / raw) "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:uem4awakr.fsf@gsfc.nasa.gov... > "Pat Rogers" <progers@NOclasswideSPAM.com> writes: > > > "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message > > news:uaef1lxlw.fsf@gsfc.nasa.gov... > > > Suppose the user writes: > > > > > > My_Handle : Handle; > > > > > > (somehow, My_Handle is given some value) > > > > > > Read (Stream, My_Handle); > > > > > > The value of My_Handle is _not_ copied to Item at the procedure > > call. > > > That only happens for "in" or "in out" parameters, not "out" > > > parameters. > > > > Have a look at RM 6.4.1{12,13} for a surprise. > > I stand corrected. I guess the Ada designers were trying to prevent > garbage pointers. That's what the AARM indicates. > I think I'd prefer the standard "initialized to > null" behavior here, for consistency. > > I guess it's easy enough to remember that "out" is the same as "in > out" for access types, and composite types with discriminants. > > On further thought, I can't think of a time when this behavior is > actively bad; it's just not what I thought the rules were. There is, however, an interesting side issue from the part of RM 6.4.1{13} that says no constraint check is done on the incoming value. Keith Thompson (no, the other Keith:) submitted a question and this bit of code that led to AI95-00110: with Ada.Text_IO; use Ada.Text_IO; procedure Foo is type Pointer is access String; P: Pointer := new String'("hello"); subtype Pointer_10 is Pointer(1 .. 10); procedure Proc(Param: out Pointer_10) is begin Put_Line("Param'Length = " & Integer'Image(Param'Length)); end Proc; begin Proc(P); end Foo; Param'Length is clearly 5, which violates the constraint but is not checked. (Evaluation of the attribute is another matter.) The AI is pretty interesting reading (but then I thought the Implementer's Guide was interesting too:). -- Pat Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-31 0:00 ` Stephen Leake 2000-07-31 0:00 ` Pat Rogers @ 2000-07-31 0:00 ` Robert A Duff 1 sibling, 0 replies; 19+ messages in thread From: Robert A Duff @ 2000-07-31 0:00 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes: > I stand corrected. I guess the Ada designers were trying to prevent > garbage pointers. I think I'd prefer the standard "initialized to > null" behavior here, for consistency. I kind of agree. But suppose you pass something as an 'out' parameter, and under some conditions, the called procedure does not assign into it. Do you really want the actual to be set to null in that case? Perhaps so... - Bob ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-26 0:00 'Read for pointers Ted Dennison 2000-07-26 0:00 ` Pat Rogers 2000-07-26 0:00 ` Pat Rogers @ 2000-07-28 0:00 ` Stephen Leake 2000-07-31 0:00 ` Ted Dennison 2 siblings, 1 reply; 19+ messages in thread From: Stephen Leake @ 2000-07-28 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > I've seen it suggested in several places to handle Stream writing of > pointers by writing what the pointer points to instead. That's simple > enough. > > But say I want to make this automatic. Lets say I have a pointer type > declared thusly: > > package Example is > type Handle is private; > > ... > private > > type Instance; > > type Handle is access all Instance; > > end Example; > > The user doesn't even really know or care that Handle is really a > pointer. But they may need to do stream I/O with it. > > The obvious solution is to create my own 'Write and 'Read routines for > Handle. But there's a problem. Following is the profile for 'Read: > > procedure Read > (Stream : access Ada.Streams.Root_Stream_Type'Class; > Item : out Handle > ); > for Handle'Read use Read; > > The problem is that Item is an *out* parameter. That means I won't have > acces to the pointer's old value inside Read. There's no way I can put > the newly read data from the stream into the Instance that Handle > currently points to! But if you are reading from a stream, Handle doesn't yet point to anything! So 'Read needs to allocate an Instance, and set Handle to that. I guess Handle could point to an Instance that the user no longer needs; it should be free'd before the new Instance pointer is assigned. So Handle must be a controlled type. My, this is getting fun :). -- -- Stephe ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 'Read for pointers 2000-07-28 0:00 ` Stephen Leake @ 2000-07-31 0:00 ` Ted Dennison 0 siblings, 0 replies; 19+ messages in thread From: Ted Dennison @ 2000-07-31 0:00 UTC (permalink / raw) In article <uhf99lxx4.fsf@gsfc.nasa.gov>, Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote: > Ted Dennison <dennison@telepath.com> writes: > > > type Handle is access all Instance; > > The problem is that Item is an *out* parameter. That means I won't > > have acces to the pointer's old value inside Read. There's no way I > > can put the newly read data from the stream into the Instance that > > Handle currently points to! > > But if you are reading from a stream, Handle doesn't yet point to > anything! So 'Read needs to allocate an Instance, and set Handle to > that. Not true. In my case, Handle points to some working user data that the client is continually saving off using 'Write, but may in certian situations want to restore using 'Read. It will *always* have a good (non-null) value when 'Read is called. I don't care about the previous value referenced by the pointer, but I defintely do care about the pointer's value itself. > needs; it should be free'd before the new Instance pointer is > assigned. So Handle must be a controlled type. My, this is getting fun > :). Bleach! When this is happening, its in a realtime program in a high-priority task running at 60HZ. You want me to needlessly deallocate then reallocate the same sized memory at 60Hz? Uhhh...no. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2000-07-31 0:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-07-26 0:00 'Read for pointers Ted Dennison 2000-07-26 0:00 ` Pat Rogers 2000-07-26 0:00 ` tmoran 2000-07-26 0:00 ` Pat Rogers 2000-07-27 0:00 ` tmoran 2000-07-26 0:00 ` Pat Rogers 2000-07-27 0:00 ` Ted Dennison 2000-07-27 0:00 ` Pat Rogers 2000-07-27 0:00 ` Ted Dennison 2000-07-27 0:00 ` Pat Rogers 2000-07-26 0:00 ` Pat Rogers 2000-07-28 0:00 ` Stephen Leake 2000-07-28 0:00 ` tmoran 2000-07-29 0:00 ` Pat Rogers 2000-07-31 0:00 ` Stephen Leake 2000-07-31 0:00 ` Pat Rogers 2000-07-31 0:00 ` Robert A Duff 2000-07-28 0:00 ` Stephen Leake 2000-07-31 0:00 ` Ted Dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox