* Unconstrained type Unchecked_Deallocation @ 2000-03-05 0:00 Andy Askey 2000-03-06 0:00 ` Ted Dennison 0 siblings, 1 reply; 13+ messages in thread From: Andy Askey @ 2000-03-05 0:00 UTC (permalink / raw) I have a byte array type that is used to generate byte-arrays dynamically. I want to dynamically deallocate these byte-arrays. Can I use the following to deallocate memory? If not, any suggestions? package tst_pkg is type Byte_Atype is array (integer range <>) of character; type Byte_Ptype is access Byte_Atype; procedure Free(The_Array : in out Byte_Ptype); end tst_pkg; package body tst_pkg is procedure Deallocate is new Ada.Unchecked_Deallocation( Byte_Atype, Byte_Ptype); procedure Free(The_Array : in out Byte_Ptype) is begin Deallocate(The_Array); end; end tst_pkg; The real question is will the Free procedure deallocate all the bytes allocated with the following? my_bytes : Byte_Ptype; begin my_bytes := new Byte_Atype(1..100); tst_pkg.Free(my_bytes); end; Thanx. Andy -- Andy Askey ajaskey@mindspring.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-03-05 0:00 Unconstrained type Unchecked_Deallocation Andy Askey @ 2000-03-06 0:00 ` Ted Dennison 2000-03-06 0:00 ` John English 2000-03-06 0:00 ` tmoran 0 siblings, 2 replies; 13+ messages in thread From: Ted Dennison @ 2000-03-06 0:00 UTC (permalink / raw) In article <lup5csoc69dj9ko2q7fbdduf8n0i4h09ll@4ax.com>, Andy Askey <ajaskey@mindspring.com> wrote: > I have a byte array type that is used to generate byte-arrays > dynamically. I want to dynamically deallocate these byte-arrays. Can > I use the following to deallocate memory? > package tst_pkg is > type Byte_Atype is array (integer range <>) of character; > type Byte_Ptype is access Byte_Atype; > > procedure Free(The_Array : in out Byte_Ptype); > end tst_pkg; > > package body tst_pkg is > procedure Deallocate is new Ada.Unchecked_Deallocation( > Byte_Atype, Byte_Ptype); > > procedure Free(The_Array : in out Byte_Ptype) is > begin > Deallocate(The_Array); > end; > end tst_pkg; That ought to work just fine. However, I don't see the benifit of doing this over just naming the instantiation of Unchecked_Deallocation "Free" in the first place. They have the same parameter profile and the same mission. > The real question is will the Free procedure deallocate all the bytes > allocated with the following? > > my_bytes : Byte_Ptype; > begin > my_bytes := new Byte_Atype(1..100); > tst_pkg.Free(my_bytes); > end; Of course. If not, your compiler is seriously broken! -- 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] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-03-06 0:00 ` Ted Dennison @ 2000-03-06 0:00 ` John English 2000-03-06 0:00 ` Ted Dennison [not found] ` <38C566CE.6283C0AD@rational.com> 2000-03-06 0:00 ` tmoran 1 sibling, 2 replies; 13+ messages in thread From: John English @ 2000-03-06 0:00 UTC (permalink / raw) Ted Dennison wrote: > That ought to work just fine. However, I don't see the benifit of doing > this over just naming the instantiation of Unchecked_Deallocation "Free" > in the first place. They have the same parameter profile and the same > mission. Possibly to avoid creating a dependence between the package spec and Unchecked_Deallocation? Might make it easier to move to a different allocation/deallocation regime at a later date, e.g. when porting... ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-03-06 0:00 ` John English @ 2000-03-06 0:00 ` Ted Dennison [not found] ` <38C566CE.6283C0AD@rational.com> 1 sibling, 0 replies; 13+ messages in thread From: Ted Dennison @ 2000-03-06 0:00 UTC (permalink / raw) In article <38C3D82F.C9F81832@bton.ac.uk>, John English <je@bton.ac.uk> wrote: > Ted Dennison wrote: > > That ought to work just fine. However, I don't see the benifit of > > doing this over just naming the instantiation of > > Unchecked_Deallocation "Free" in the first place. They have the same > > parameter profile and the same mission. > > Possibly to avoid creating a dependence between the package spec and > Unchecked_Deallocation? Might make it easier to move to a different > allocation/deallocation regime at a later date, e.g. when porting... Assuming that in real life that code is split between the spec and body? That's a good possiblity. The best reason I could think of was the possibility that this is just an example of a routine that in real life also needs to contain some other cleanup code. But I find often with beginners they just don't know any better, so its best to point out inefficencies and possible alternate techniques. -- 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] 13+ messages in thread
[parent not found: <38C566CE.6283C0AD@rational.com>]
* Re: Unconstrained type Unchecked_Deallocation [not found] ` <38C566CE.6283C0AD@rational.com> @ 2000-03-08 0:00 ` Robert Dewar 2000-03-08 0:00 ` Larry Kilgallen 2000-04-05 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 13+ messages in thread From: Robert Dewar @ 2000-03-08 0:00 UTC (permalink / raw) In article <38C566CE.6283C0AD@rational.com>, Mark Lundquist <mark@rational.com> wrote: > Right, hiding the instantiation of Unchecked_Deallocation is > often a good idea. This is stated without justification. Please give your reasons for this, I don't see it at all. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-03-08 0:00 ` Robert Dewar @ 2000-03-08 0:00 ` Larry Kilgallen 2000-04-05 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 13+ messages in thread From: Larry Kilgallen @ 2000-03-08 0:00 UTC (permalink / raw) In article <8a6f5s$5st$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > In article <38C566CE.6283C0AD@rational.com>, > Mark Lundquist <mark@rational.com> wrote: > >> Right, hiding the instantiation of Unchecked_Deallocation is >> often a good idea. > > This is stated without justification. Please give your reasons > for this, I don't see it at all. These days I tend to name my instantiations of Unchecked_Deallocation Unchecked_<something-or-other>. The fact that an instantiation exists is plain, and if I wanted to hide the instantiation it would give it a scope larger than I want. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-03-08 0:00 ` Robert Dewar 2000-03-08 0:00 ` Larry Kilgallen @ 2000-04-05 0:00 ` Robert I. Eachus 2000-04-06 0:00 ` P. S. Norby 2000-04-06 0:00 ` Robert Dewar 1 sibling, 2 replies; 13+ messages in thread From: Robert I. Eachus @ 2000-04-05 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <38C566CE.6283C0AD@rational.com>, > Mark Lundquist <mark@rational.com> wrote: > > > Right, hiding the instantiation of Unchecked_Deallocation is > > often a good idea. > > This is stated without justification. Please give your reasons > for this, I don't see it at all. There are occaisions where you may want in the future to change the management mechanism for some type, by a means other than using storage pools. However, in Ada 95 this seems like a long stretch. In any case, if the fact that a type is an access type is visible--as it has to be to do the instantiation, I don't see much reason to hide the deallocation operation. Unchecked_Conversion is a very different case. I think I invented the name "Unchecked Perversion" for visible instantiations of Unchecked_Conversion--it really is that bad. Putting an instance of Unchecked_Conversion substantially increases the coupling throughout a program with no corresponding benefit. As an example--and one I ran into often in the early days of Ada--consider an unchecked conversion as follows: type Foo is access Bar; function UC is new Unchecked_Conversion(Foo, Integer); Now try to port the code to an Ada implementation where Integer is 16 bits. You think you can just redefine UC, but it is not that easy. The worst horror of this type I ever ran into took over a week to rehide a public conversion between two "slightly different" record layouts. The most embarrassing part of that was that the initial author's intent was to speed up access by not using record variants, and the properly hidden code was significantly faster. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-04-05 0:00 ` Robert I. Eachus @ 2000-04-06 0:00 ` P. S. Norby 2000-04-06 0:00 ` Robert Dewar 1 sibling, 0 replies; 13+ messages in thread From: P. S. Norby @ 2000-04-06 0:00 UTC (permalink / raw) Robert I. Eachus wrote: > > Unchecked_Conversion > "Unchecked Perversion" I recall someone, in a presentation at SIGAda, mistakenly (?) refering to it as "unchecked_confusion"! P.S. Norby "Software engineers are, in many ways, similar to normal people" -- Scott Adams "No excuses. No embarrassment. No apologies... Ada -- the most trusted and powerful programming language on earth, or in space." -- S. Tucker Taft \\\ \\\ \\\ \\\ \\\ \\\ \\\ \\\ \\\ ( :) ( :) ( :) ( :) ( :) ( :) ( :) ( :) ( :) /// /// /// /// /// /// /// /// /// (Speaking only for myself) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-04-05 0:00 ` Robert I. Eachus 2000-04-06 0:00 ` P. S. Norby @ 2000-04-06 0:00 ` Robert Dewar 2000-04-09 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 13+ messages in thread From: Robert Dewar @ 2000-04-06 0:00 UTC (permalink / raw) In article <38EBAAD6.3EA21F14@earthlink.net>, "Robert I. Eachus" <rieachus@earthlink.net> wrote: > type Foo is access Bar; > function UC is new Unchecked_Conversion(Foo, Integer); > > Now try to port the code to an Ada implementation where > Integer is 16 > bits. You think you > can just redefine UC, but it is not that easy. This is complete nonsense as far as I am concerned. The difficulty of conversion here is completely unaffected by whether the unchecked conversion is in the body or in the spec. In either case we have conversions that must be dealt with, and the set of problems is identical in the two cases. The *only* difference is in whether stuff has to be recompiled or not, and even this does not apply if there is a pragma Inline around. Otherwise it makes no semantic difference AT ALL whether the UC is in the spec or body. Calling it unchecked_perversion does not make an argument :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-04-06 0:00 ` Robert Dewar @ 2000-04-09 0:00 ` Robert I. Eachus 2000-04-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 13+ messages in thread From: Robert I. Eachus @ 2000-04-09 0:00 UTC (permalink / raw) Robert Dewar wrote: > This is complete nonsense as far as I am concerned. The > difficulty of conversion here is completely unaffected by > whether the unchecked conversion is in the body or in the > spec. In either case we have conversions that must be dealt > with, and the set of problems is identical in the two cases. Sorry, it is completely different. Say you have two types, at least one of which is private,and an instantiation of Unchecked_Conversion in the body of the package defining the private type. To be more specific: package Foo is type Foo_Type is private; function Create(Value: Integer) return Foo_Type; -- Initially U_C .... end Foo; If at some later date it is necessary to change the conversion, perhaps to target a machine with a different word length, only the specification and body of Foo will need to be modified. (The package specification will need to be modified to change the declaration of Foo_Type--the function declaration need not change.) Now let's try unchecked perversion: package Foo is type Foo_Type is private; function Create is new Unchecked_Conversion(Integer, Foo_Type); ... end Foo; Now if you need to make a change it is extremely hard. The privacy of Foo_Type has been completely lost, so any section of code can depend on the equivalence of Integer and Foo_Type. This includes, and this is where the name comes from, all units which can see Integer, even those without a with clause for Foo. At a minimum, you end up having to inspect the source for the entire program just to estimate how much work is required to change the representation of Foo_Type. In the worst case, and I have run into a couple, you end up paying the compiler vendor to provide, 32-bit Integer, or 32-bit access types in response to a size clause, etc. The worst such unchecked perversions are those which convert between two predefined types--in Ada 83 days usually System.Address and Standard.Integer. There have been several occaisons where a quick review of the code revealed this problem, and the solution was to force the choice of a particular compiler, or just to limit the possible choices. So yes, I do think that this is a very nasty thing to do, especially when avoiding the problem only requires a couple extra lines of code. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-04-09 0:00 ` Robert I. Eachus @ 2000-04-09 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 13+ messages in thread From: Robert Dewar @ 2000-04-09 0:00 UTC (permalink / raw) In article <38F0B641.2346CF95@earthlink.net>, "Robert I. Eachus" <rieachus@earthlink.net> wrote: > Robert Dewar wrote: > > > This is complete nonsense as far as I am concerned. The > > difficulty of conversion here is completely unaffected by > > whether the unchecked conversion is in the body or in the > > spec. In either case we have conversions that must be dealt > > with, and the set of problems is identical in the two cases. > > Sorry, it is completely different. <<detailed discussion snipped>> Your discussion boils down to worrying about a class of programmers who have the following characteristics. 1. They would not dream of looking in a body, and taking liberties with information derived therefrom. 2. They will look at an unchecked conversion in the spec and feel free to do stupid things. OK, maybe there are such programmers, but I have not met them. I meet really two classes of programmes in this kind of respect. 1. Those who are careful, and know that it would be folly to depend on the representational equivalence implied by an unchecked conversion, whether or not it is in the spec or the body. 2. Those who will do what they like, regardless of what is nice, and will not hesitate a moment to draw the same (bad) conclusion from an unchecked conversion in the body as in the spec. I think trying to make this out as an important methodological issue is bogus. After all, if you have a function in the spec whose spec is that it convers from integer to address by the moral equivalent of unchecked conversion, then you can draw evil conclusions just from this spec. I cannot imagine some wonderful high level semantic description of this conversion that is at an abstraction level different from unchecked conversion (assuming a reasonable implementation thereof). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-04-09 0:00 ` Robert Dewar @ 2000-04-12 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 13+ messages in thread From: Robert I. Eachus @ 2000-04-12 0:00 UTC (permalink / raw) Robert Dewar wrote: > Your discussion boils down to worrying about a class of > programmers who have the following characteristics. > > 1. They would not dream of looking in a body, and taking > liberties with information derived therefrom. > > 2. They will look at an unchecked conversion in the spec and > feel free to do stupid things. Yep, on a large project, if there is an unchecked conversion in the interface, programmers will assume that it is part of the interface and can be treated as such. These same programmers may never have the opportunity to look at the corresponding body, which may be written by a group at a different location, or even a different company. In fact, I have seen unchecked perversion where the specs were common, and the bodies were written by two different companies several thousand miles apart. Moving to a different platform was a killer... > OK, maybe there are such programmers, but I have not met them. The luxury of being an academic. ;-) That smiley is because Robert Dewar has spent as much time in the trenches as I have. I just used to get called in on the really bad cases. I literally can't tell you how many times I have been called in to declare the corpse dead--and yes, there have been a few times when it wasn't. If I can I'd like to write a paper on how to tell that a software project is dead. In one sentence, if fixing a bug will on average introduce at least one new bug, stop. The trick is to be able to determine that ahead of time, and stop earlier. (Or even on time. It is a characteristic of failed software projects that the quality of the bug report database is poor.) > I meet really two classes of programmes in this kind of respect. > 1. Those who are careful, and know that it would be folly to > depend on the representational equivalence implied by an > unchecked conversion, whether or not it is in the spec or the > body. But would never dream of putting the Unchecked_Conversion in the visible part of the package... > 2. Those who will do what they like, regardless of what is nice, > and will not hesitate a moment to draw the same (bad) conclusion > from an unchecked conversion in the body as in the spec. But to make use of the fact, they often have to put in their own instances of Unchecked_Conversion and get caught that way. > I think trying to make this out as an important methodological > issue is bogus. After all, if you have a function in the spec > whose spec is that it convers from integer to address by the > moral equivalent of unchecked conversion, then you can draw > evil conclusions just from this spec. I cannot imagine some > wonderful high level semantic description of this conversion > that is at an abstraction level different from unchecked > conversion (assuming a reasonable implementation thereof). No, the conclusions that you can draw from the function in the spec are not evil. If for example the body of a visible conversion function is an instance of Unchecked_Conversion from Integer to System.Address, and the program is moved to a different platform where the two have different sizes, then it will usually be possible to replace that body without changing the semantics. (Of course there will normally be more than one operation in the package that needs to be rewritten. But still, you are within one package body, and don't have to look throughout the program.) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Unconstrained type Unchecked_Deallocation 2000-03-06 0:00 ` Ted Dennison 2000-03-06 0:00 ` John English @ 2000-03-06 0:00 ` tmoran 1 sibling, 0 replies; 13+ messages in thread From: tmoran @ 2000-03-06 0:00 UTC (permalink / raw) >> The real question is will the Free procedure deallocate all the bytes >> allocated with the following? >Of course. If not, your compiler is seriously broken! The real question is why the questioner started on the assumption that Unchecked_Deallocation didn't work in a standard situation, but but was happily accepted by the compiler in that situation. With most Ada compilers, it's better to start on the assumption the compiler, as well as the language, was not designed by amateurs. If you think something is broken, try it with a test program. If that proves it is in fact broken, then it's reasonable to ask (perhaps on c.l.a.) if the error is in the compiler or the language. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2000-04-12 0:00 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-05 0:00 Unconstrained type Unchecked_Deallocation Andy Askey 2000-03-06 0:00 ` Ted Dennison 2000-03-06 0:00 ` John English 2000-03-06 0:00 ` Ted Dennison [not found] ` <38C566CE.6283C0AD@rational.com> 2000-03-08 0:00 ` Robert Dewar 2000-03-08 0:00 ` Larry Kilgallen 2000-04-05 0:00 ` Robert I. Eachus 2000-04-06 0:00 ` P. S. Norby 2000-04-06 0:00 ` Robert Dewar 2000-04-09 0:00 ` Robert I. Eachus 2000-04-09 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert I. Eachus 2000-03-06 0:00 ` tmoran
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox