* Re: Flexible Strings (was Equality operator...) @ 1997-04-30 0:00 W. Wesley Groleau (Wes) 1997-04-30 0:00 ` Matthew Heaney 0 siblings, 1 reply; 30+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-04-30 0:00 UTC (permalink / raw) I never had a problem implementing an Ada-83 equivalent of bounded strings so that no heap was required. Did it pretty much as Matt Heaney suggested, after reviewing a couple of "free" dynamic_strings packages and finding that nearly every operation leaked heap. The one thing I really missed, however, is still not available in Ada 95: assigning string literals to these things. I think that using unary "+" is a C-like solution (i.e., sacrificing "intuitive" readability to save keystrokes). Defining a function that looked like a type conversion was better for the READER, but since you can't use the actual type name, it posed a memory inconvenience on the writer. --------------------------------------------------------------------------- W. Wesley Groleau (Wes) Office: 219-429-4923 Hughes Defense Communications (MS 10-41) Home: 219-471-7206 Fort Wayne, IN 46808 (Unix): wwgrol@pseserv3.fw.hac.com -- SPAM should be sent to I.want.one@mailbombs.for.idiots.org If you want to be prosecuted under 27 USC 227, go ahead and send it here. --------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-04-30 0:00 Flexible Strings (was Equality operator...) W. Wesley Groleau (Wes) @ 1997-04-30 0:00 ` Matthew Heaney 1997-05-01 0:00 ` Robert Dewar 1997-05-02 0:00 ` Kevin Cline 0 siblings, 2 replies; 30+ messages in thread From: Matthew Heaney @ 1997-04-30 0:00 UTC (permalink / raw) In article <9704301422.AA07755@most>, "W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> wrote: >I never had a problem implementing an Ada-83 equivalent of bounded strings >so that no heap was required. Did it pretty much as Matt Heaney suggested, >after reviewing a couple of "free" dynamic_strings packages and finding >that nearly every operation leaked heap. Many people don't realize that Ada was more or less designed to that you don't have to use heap. The problem with Ada 83 is that when you do need it, memory leaks are bound to happen, because clients often forget to clean up the data structure. Thankfully, this has been corrected in Ada 95. And just to remind everyone, an access type (or even an array type) is a low-level primitive. Clients of a (high-level) abstraction shouldn't have to manipulate access objects directly - use access types to implement an (unbounded) abstraction. Pointers are strictly an implementation feature of the language, for use by the programmer to craft higher-level abstractions. >The one thing I really missed, however, is still not available in Ada 95: >assigning string literals to these things. I think that using unary "+" >is a C-like solution (i.e., sacrificing "intuitive" readability to save >keystrokes). Defining a function that looked like a type conversion was >better for the READER, but since you can't use the actual type name, >it posed a memory inconvenience on the writer. I often think that automatic type conversions such as are available in C++ would be useful. You're right, it seems that declare S : String_Buffer := "initial value of S"; begin ... would be OK. But I don't know. Norm Cohen had a post once about how difficult it is to reason about the correctness of software where automatic conversions were taking place. The bad thing is that what is happening at run-time isn't obvious from reading the code, because conversion routines are being invoked automatically. Not being able to understand what's happening at run-time by reading the static source text is what originally prompted Dijkstra to admonish against the use of the goto. It seems that Microsoft's Hungarian notation is a desperate attempt to maintain intellectual control of when automatic conversions are happening in C. Where do you draw the line about syntactic difficultness vs semantic correctness: Automatic_Conversion: declare SA : constant String_Buffer_Array := ("I'd", "gladly", "lose", "me", "to", "find", "you"); begin Explicit_Conversion: declare SA : constant String_Buffer_Array := ( To_String_Buffer ("I'd"), To_String_Buffer ("gladly"), To_String_Buffer ("lose"), To_String_Buffer ("me"), To_String_Buffer ("to"), To_String_Buffer ("find"), To_String_Buffer ("you")); begin A_Happy_Medium: declare SA : constant String_Buffer_Array := (+"I'd", +"gladly", +"lose", +"me", +"to", +"find", +"you") begin Yes, explicit conversion makes it obvious that conversion is happening, but you tend to lost the forest through the trees with the middle approach above. I got the "+" idea from Barnes' book. Don't think of it as a hack; think of it as what it is: the identity operator. It's a happy medium between the 2 extremes. There's probably a comprimise in there somewhere. Everyone is still realing from the heights of automatic conversions in Algol 68 - that vastly complicated the language - and Ada 83's staticness was an (over)reaction to that. Things have been loosened up a bit in Ada 95, but there's probably room for more loosening. But how far do you go with syntactic ease before you comprimise semantic characteristics? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-04-30 0:00 ` Matthew Heaney @ 1997-05-01 0:00 ` Robert Dewar 1997-05-02 0:00 ` Kevin Cline 1 sibling, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-05-01 0:00 UTC (permalink / raw) Wes said <<The problem with Ada 83 is that when you do need it, memory leaks are bound to happen, because clients often forget to clean up the data structure. Thankfully, this has been corrected in Ada 95. >> That's a ferocious and incorrect over-generalization. Of course it is possible to use the heap in Ada 83 programs without having memory leaks. In fact I would guess that the majority of all Ada programs ever written are in this category. Yes, you can program memory leaks in Ada 83 if you are sloppy. No, Ada 95 does not magically prevent this, although the use of finalization can help, if used carefully -- if used carelessly it can make things worse, by obscuring where the leaks are taking place. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-04-30 0:00 ` Matthew Heaney 1997-05-01 0:00 ` Robert Dewar @ 1997-05-02 0:00 ` Kevin Cline 1997-05-03 0:00 ` Jon S Anthony 1997-05-03 0:00 ` Robert Dewar 1 sibling, 2 replies; 30+ messages in thread From: Kevin Cline @ 1997-05-02 0:00 UTC (permalink / raw) mheaney@ni.net (Matthew Heaney) wrote: >In article <9704301422.AA07755@most>, "W. Wesley Groleau (Wes)" ><wwgrol@PSESERV3.FW.HAC.COM> wrote: > >>I never had a problem implementing an Ada-83 equivalent of bounded strings >>so that no heap was required. Did it pretty much as Matt Heaney suggested, >>after reviewing a couple of "free" dynamic_strings packages and finding >>that nearly every operation leaked heap. > >Many people don't realize that Ada was more or less designed to that you >don't have to use heap. Heap usage is required for programs which solve problems whose size is unknown and run on machines with unknown memory resources. Embedded applications don't have these requirements, so dynamic allocation wasn't interesting to the Ada '83 design team. > >The problem with Ada 83 is that when you do need it, memory leaks are bound >to happen, because clients often forget to clean up the data structure. >Thankfully, this has been corrected in Ada 95. Too late, too late... >Explicit_Conversion: >declare > SA : constant String_Buffer_Array := ( > To_String_Buffer ("I'd"), > To_String_Buffer ("gladly"), > To_String_Buffer ("lose"), > To_String_Buffer ("me"), > To_String_Buffer ("to"), > To_String_Buffer ("find"), > To_String_Buffer ("you")); This is about the point where C++ programmers turn away laughing. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-02 0:00 ` Kevin Cline @ 1997-05-03 0:00 ` Jon S Anthony 1997-05-03 0:00 ` Robert Dewar 1 sibling, 0 replies; 30+ messages in thread From: Jon S Anthony @ 1997-05-03 0:00 UTC (permalink / raw) In article <3F2AA8DEC61418AE.502E81A8ECA1C4E7.3A25DE2FB38755A4@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes: > Heap usage is required for programs which solve problems whose size > is unknown and run on machines with unknown memory resources. > Embedded applications don't have these requirements, so dynamic allocation > wasn't interesting to the Ada '83 design team. This is where I start laughing. Any reason why you think stating this sort of laughable, completely unsupported and in direct conflict with the facts opinion is of any use whatsoever? > >Explicit_Conversion: > >declare > > SA : constant String_Buffer_Array := ( > > To_String_Buffer ("I'd"), > > To_String_Buffer ("gladly"), > > To_String_Buffer ("lose"), > > To_String_Buffer ("me"), > > To_String_Buffer ("to"), > > To_String_Buffer ("find"), > > To_String_Buffer ("you")); > > This is about the point where C++ programmers turn away laughing. As they go back to trying to get their templates to work - or just try to figure out what they were even trying to say with them... /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-02 0:00 ` Kevin Cline 1997-05-03 0:00 ` Jon S Anthony @ 1997-05-03 0:00 ` Robert Dewar 1997-05-04 0:00 ` Kevin Cline 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-05-03 0:00 UTC (permalink / raw) Kevin Cline said <<Heap usage is required for programs which solve problems whose size is unknown and run on machines with unknown memory resources. Embedded applications don't have these requirements, so dynamic allocation wasn't interesting to the Ada '83 design team.>> This is nonsense and in no way reflects reality. Of course the Ada 83 design team recognized the importance of dynamic allocation. This is why Ada 83 has a full facility for this capability, comparable to that provided in many other languages (such as C, PL/1, Pascal). Ada 83 did NOT require garbage collection, but the design went out of its way to accomodate garbage collection (in strong contrast to the design of C for example). In fact the designers (and Fisher in particular in his role as DoD mentor of this project) were hopeful that technology would be developed to allow the effective use of garbage collection even in real time programs. Ada 83 also did not provide user defined finalization. I really can't recall that ever being discussed as a possibility -- perhaps the concept was not even sufficiently familiar in the late 70's when Ada was designed. But to say that dynamic allocatoin wasn't interesting to the design team is just plain wrong. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-03 0:00 ` Robert Dewar @ 1997-05-04 0:00 ` Kevin Cline 1997-05-04 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Kevin Cline @ 1997-05-04 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >But to say that dynamic allocatoin wasn't interesting to the design team >is just plain wrong. Evidently it wasn't important enough for the standard to mandate any useful semantics for unchecked_deallocation. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-04 0:00 ` Kevin Cline @ 1997-05-04 0:00 ` Robert Dewar 1997-05-06 0:00 ` Kaz Kylheku 1997-05-09 0:00 ` Erik Magnuson 0 siblings, 2 replies; 30+ messages in thread From: Robert Dewar @ 1997-05-04 0:00 UTC (permalink / raw) Kevin Cline said <<Evidently it wasn't important enough for the standard to mandate any useful semantics for unchecked_deallocation.>> That shows a misunderstanding of language semantics. There is no easy way to formalize what it means to free storage that would encompass all possible dynamic allocation techiques, including effects of fragmentation etc. For example, if we try to define that certain classes of programs should run for ever without getting storage error, then it is still a semantically valid implementation to just use up virtual memory for ever (if necessary asking for new tapes to be loaded to store the old junk). So no language standard can meaninfuly specify formal semantiocs for what deallocation might mean, beyond specifying that reference to freed storage is in an appropriate sense incorrect. So Ada is no different from C or Pascal or any other lanuage here. I suspect that Kevin is not the kind of person who spends his time studying formal standards, but if you want to follow this up, for example go look at the definition of Dispose in the ANSI Pascal standard. What does the Ada standard say about Unchecked_Deallocation: 9 Free(X), when X is not equal to null first performs finalization, as described in 7.6. It then deallocates the storage occupied by the object designated by X. If the storage pool is a user-defined Nice, but of course deallocate is not really formally defined, then we have the implementation advice: 17 For a standard storage pool, Free should actually reclaim the storage. again "actually reclaim" is not formally defined. BUT, does this matter in practice? Of course not, all Ada compilers always have followed this advice for the standard storage pool, and it would be surprising if it were otherwise. This is exactly the same situation as observing that all C compilers actualy free storage when free is used. Is it possible to make a formally conforming implementation in which unchecked deallocation is useless. Most certainly. It is also possible to make a formally conforming impl,ementation in which all integr additions take one hour to complete. Bothy implementations are formally correct according to the standard, both are totally useless! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-04 0:00 ` Robert Dewar @ 1997-05-06 0:00 ` Kaz Kylheku 1997-05-07 0:00 ` Robert Dewar ` (3 more replies) 1997-05-09 0:00 ` Erik Magnuson 1 sibling, 4 replies; 30+ messages in thread From: Kaz Kylheku @ 1997-05-06 0:00 UTC (permalink / raw) In article <dewar.862755569@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >So no language standard can meaninfuly specify formal semantiocs for >what deallocation might mean, beyond specifying that reference to freed >storage is in an appropriate sense incorrect. > >So Ada is no different from C or Pascal or any other lanuage here. I suspect >that Kevin is not the kind of person who spends his time studying formal >standards, but if you want to follow this up, for example go look at the >definition of Dispose in the ANSI Pascal standard. Actually Ada must be different here. If were were discussing C, we wouldn't need to generate a week long thread regarding what malloc() and free() are, and how to use them. >What does the Ada standard say about Unchecked_Deallocation: > > 9 Free(X), when X is not equal to null first performs finalization, > as described in 7.6. It then deallocates the storage occupied by > the object designated by X. If the storage pool is a user-defined > > >Nice, but of course deallocate is not really formally defined, then we have >the implementation advice: > >17 For a standard storage pool, Free should actually reclaim the storage. > >again "actually reclaim" is not formally defined. > >BUT, does this matter in practice? Of course not, all Ada compilers always >have followed this advice for the standard storage pool, and it would be >surprising if it were otherwise. This is exactly the same situation as >observing that all C compilers actualy free storage when free is used. But the C standard firmly says that ``The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation'' (ISO 9899:1990 7.10.3.2 The free function). This pretty much constitutes a requirement that the C implementation actually deallocate when free is called, which carries more weight than a mere observation about what all existing implementations do. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-06 0:00 ` Kaz Kylheku @ 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Kevin Cline ` (2 subsequent siblings) 3 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-05-07 0:00 UTC (permalink / raw) <<But the C standard firmly says that ``The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation'' (ISO 9899:1990 7.10.3.2 The free function). This pretty much constitutes a requirement that the C implementation actually deallocate when free is called, which carries more weight than a mere observation about what all existing implementations do.>> That's a misconception. The above statement is one of intent, but it has no semantic force, because it would be impossible to specify the conditions under which storage could be reused. For example if the total heap size is 2N words, and we allocate two blocks of N and then free them, then can we allocate a single 2N word block -- the C standard is silent on this, and indeed has to be. So the above paragraph is not "firmly" saying anything. An implementation that ignores free is formally conformant. It would take the attitude that the storage is indeed made available for further allocation, but unfortunately none of your subsequent requests were able to be filled using this storage. Of course a C compiler that abused this too much would be useless and no one would use it, just as an Ada compiler that ignored unchecked deallocation would also be useless. Note that the Ada RM does indeed say: 17 For a standard storage pool, Free should actually reclaim the storage. which has just as much force from a formal point of view as the statementin the C standard. In the Ada RM it is Implementation Advice, which is much more honest. In the C standard it is also implementation advice, but it is less obvious that this is the case, as we seel from Kaz's post. It is a very common misconception for those without experience in what semantic definition is about, and what as-if semantics are about, to want to put statements like this into a language definition, but it is misleading and confusing. However, there is usually enough vocal support for such semantic nonsense that it creeps in from time to time in any language standard (the Ada RM is not without its examples of this kind of thing!) Actually I think the Implementation Advice sections in the RM are very helpful, because, since they are non-normative, you can use rather informal ("you know what I mean") kind of language, and say things that you could not say at all in normative text. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-06 0:00 ` Kaz Kylheku 1997-05-07 0:00 ` Robert Dewar @ 1997-05-07 0:00 ` Kevin Cline 1997-05-07 0:00 ` Robert A Duff ` (3 more replies) 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Robert A Duff 3 siblings, 4 replies; 30+ messages in thread From: Kevin Cline @ 1997-05-07 0:00 UTC (permalink / raw) In article <dewar.862755569@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >So no language standard can meaninfuly specify formal semantiocs for >what deallocation might mean, beyond specifying that reference to freed >storage is in an appropriate sense incorrect. > >So Ada is no different from C or Pascal or any other lanuage here. I suspect >that Kevin is not the kind of person who spends his time studying formal >standards, but if you want to follow this up, for example go look at the >definition of Dispose in the ANSI Pascal standard. I was a member of ANSI X3H3 (PHIGS) for two years. I read the Ada'83 standard cover to cover. I've read most of the C++ DWP. Perhaps there is not a lot of difference in theory between Ada and C storage management, but there is a huge practical difference. In C or C++, the application programmer can take complete control of the allocation process in a couple of ways. In C++, new and delete can be redefined globally or on a class-by-class basis. Additionally, the compiler vendor's implementation of malloc and free can be replaced with one more carefully tuned to the particular application. Although not mandated by the standard, almost all C compilers do link malloc and free from their run-time library, and replacement implementations can be linked instead. Few Ada compilation systems are so open. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-07 0:00 ` Kevin Cline @ 1997-05-07 0:00 ` Robert A Duff 1997-05-07 0:00 ` Matthew Heaney ` (2 subsequent siblings) 3 siblings, 0 replies; 30+ messages in thread From: Robert A Duff @ 1997-05-07 0:00 UTC (permalink / raw) In article <53F35740C6EF076C.14BEEF8227919F71.39E2B6FED1F30314@library-proxy.airnews.net>, Kevin Cline <clines@delete_this.airmail.net> wrote: >I was a member of ANSI X3H3 (PHIGS) for two years. I read the Ada'83 standard >cover to cover. I've read most of the C++ DWP. Perhaps there is not a lot of >difference in theory between Ada and C storage management, but there is a huge >practical difference. In C or C++, the application programmer can take >complete control of the allocation process in a couple of ways. In C++, new >and delete can be redefined globally or on a class-by-class basis. >Additionally, the compiler vendor's implementation of malloc and free can be >replaced with one more carefully tuned to the particular application. >Although not mandated by the standard, almost all C compilers do link malloc >and free from their run-time library, and replacement implementations can be >linked instead. Few Ada compilation systems are so open. What you say may be true of Ada 83, but Ada 95 allows user-defined storage pools. You can use whatever allocation strategy you like. This is a required feature of all Ada compilers. It much more flexible than globally replacing malloc, because you get control on a per-access-type basis. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-07 0:00 ` Kevin Cline 1997-05-07 0:00 ` Robert A Duff @ 1997-05-07 0:00 ` Matthew Heaney 1997-05-07 0:00 ` Jon S Anthony 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Jon S Anthony 3 siblings, 1 reply; 30+ messages in thread From: Matthew Heaney @ 1997-05-07 0:00 UTC (permalink / raw) In article <53F35740C6EF076C.14BEEF8227919F71.39E2B6FED1F30314@library-proxy.airnews.ne t>, clines@delete_this.airmail.net (Kevin Cline) wrote: >Perhaps there is not a lot of >difference in theory between Ada and C storage management, but there is a huge >practical difference. In C or C++, the application programmer can take >complete control of the allocation process in a couple of ways. In C++, new >and delete can be redefined globally or on a class-by-class basis. >Additionally, the compiler vendor's implementation of malloc and free can be >replaced with one more carefully tuned to the particular application. >Although not mandated by the standard, almost all C compilers do link malloc >and free from their run-time library, and replacement implementations can be >linked instead. Few Ada compilation systems are so open. I'm confused. Isn't that what storage pools are for in Ada 95? I can create a pool so that new and Unchecked_Deallocation call routines I define, on a type-by-type basis. What's the difference? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-07 0:00 ` Matthew Heaney @ 1997-05-07 0:00 ` Jon S Anthony 0 siblings, 0 replies; 30+ messages in thread From: Jon S Anthony @ 1997-05-07 0:00 UTC (permalink / raw) In article <mheaney-ya023680000705970214190001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes: > I'm confused. Isn't that what storage pools are for in Ada 95? I can Yes. > create a pool so that new and Unchecked_Deallocation call routines I > define, on a type-by-type basis. What's the difference? The Ada route affords you rather more control over the implementation and use of the pool and the "access types" assigned to it. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-07 0:00 ` Kevin Cline 1997-05-07 0:00 ` Robert A Duff 1997-05-07 0:00 ` Matthew Heaney @ 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Jon S Anthony 3 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-05-07 0:00 UTC (permalink / raw) Kevin Cline said <<I was a member of ANSI X3H3 (PHIGS) for two years. I read the Ada'83 standard cover to cover. I've read most of the C++ DWP. Perhaps there is not a lot of difference in theory between Ada and C storage management, but there is a huge practical difference. In C or C++, the application programmer can take complete control of the allocation process in a couple of ways. In C++, new and delete can be redefined globally or on a class-by-class basis. Additionally, the compiler vendor's implementation of malloc and free can be replaced with one more carefully tuned to the particular application. Although not mandated by the standard, almost all C compilers do link malloc and free from their run-time library, and replacement implementations can be linked instead. Few Ada compilation systems are so open.>> Apparently you have not kept up with the times, you are comparing an obsolete version of Ada to C++, which is rather inappropriate, considering that Ada 95 is standardized several years before C++! So I suggest you bring yourself up to date before making statements about what "few Ada compilation systems" may or may not provide. Our convention in this newsgroup is that Ada undecorated means the current version of Ada, i.e. Ada 95 (note that the Ada 95 standard is now over two years old, there are over 50 validated compilers, and Ada 95 is available on virtually every common architecture, so we are not talking science fiction here). One of the important features in Ada 95 is the storage pool mechanism, which provides considerably more flexibility than the corresponding C++ mechanisms. All versions of GNAT, and most if not all, other Ada 95 technologies fully support this storage pool feature. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-07 0:00 ` Kevin Cline ` (2 preceding siblings ...) 1997-05-07 0:00 ` Robert Dewar @ 1997-05-07 0:00 ` Jon S Anthony 3 siblings, 0 replies; 30+ messages in thread From: Jon S Anthony @ 1997-05-07 0:00 UTC (permalink / raw) In article <53F35740C6EF076C.14BEEF8227919F71.39E2B6FED1F30314@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes: > I was a member of ANSI X3H3 (PHIGS) for two years. I read the > Ada'83 standard cover to cover. No longer relevant. > I've read most of the C++ DWP. Perhaps there is not a lot of > difference in theory between Ada and C storage management, but there > is a huge practical difference. OK, let's hear it. > In C or C++, the application programmer can take complete control of > the allocation process in a couple of ways. In C++, new and delete > can be redefined globally or on a class-by-class basis. That's what Ada provides with storage pools. In fact, it is rather tighter as you can control the usage of the "pointer types" much more. > Additionally, the compiler vendor's implementation of malloc and > free can be replaced with one more carefully tuned to the particular > application. First this is (as you point out, but apparently promptly forget) and implementation issue and not a language issue. Second, this has been done in several Ada implementations. So, you still haven't given an example. > Although not mandated by the standard, almost all C compilers do So, again irrelevant. > link malloc and free from their run-time library, and replacement > implementations can be linked instead. Few Ada compilation systems > are so open. There is no reason whatsoever to keep you from doing this as long as you know what the link names for the alloc/dealloc for the standard pool are. Typically this will in fact be good ol' malloc/free. So, just replace them. If not, get the names and replace them. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-06 0:00 ` Kaz Kylheku 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Kevin Cline @ 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Robert A Duff 3 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-05-07 0:00 UTC (permalink / raw) <<But the C standard firmly says that ``The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation'' (ISO 9899:1990 7.10.3.2 The free function). This pretty much constitutes a requirement that the C implementation actually deallocate when free is called, which carries more weight than a mere observation about what all existing implementations do.>> Let me give a possible implementation of the C standard. Suppose we are on a machine with huge address space, and lots of virtual memory. We assume for example a 256-bit virtual address space. Now our C implementation works this way, malloc always returns the next sequentially available location. Free works by simply removing the relevant pages from the page table. This is a perfectly defensible and usable implementation of C. Would it violate the standard? Of course not! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-06 0:00 ` Kaz Kylheku ` (2 preceding siblings ...) 1997-05-07 0:00 ` Robert Dewar @ 1997-05-07 0:00 ` Robert A Duff 1997-05-07 0:00 ` Robert Dewar 1997-05-08 0:00 ` Robert I. Eachus 3 siblings, 2 replies; 30+ messages in thread From: Robert A Duff @ 1997-05-07 0:00 UTC (permalink / raw) In article <5kocg6$hln@bcrkh13.bnr.ca>, Kaz Kylheku <kaz@vision.crest.nt.com> wrote: >But the C standard firmly says that ``The free function causes the space >pointed to by ptr to be deallocated, that is, made available for further >allocation'' (ISO 9899:1990 7.10.3.2 The free function). This pretty much >constitutes a requirement that the C implementation actually deallocate >when free is called, which carries more weight than a mere observation >about what all existing implementations do. It *sounds* firm, but it isn't really saying anything precise. For example, it doesn't address the issue of fragmentation. If I deallocate 1000 objects of size 100 bytes each, does that mean I can now allocate a single 100,000-byte object in that space? After all, it says that storage is "available for allocation". Do you interpret this requirement to require compaction of storage? Sure sounds like it, but that surely wasn't the intent. Can you write a test program that detects the difference between a C implementation that obeys the above "requirement", and one that doesn't? If not, then it should be viewed merely as Implementation Advice, from a formal point of view. Of course, I admit that the C standard is easier to understand on this particular point, if you're just a programmer trying to write programs, and not a language lawyer. The Ada standard goes out of its way to raise questions of this nature, unfortunately. Nonetheless, I claim that the requirements of C and Ada are identical with respect to whether free/Unch_Dealloc must/should reclaim storage. They're just written in a different style. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-07 0:00 ` Robert A Duff @ 1997-05-07 0:00 ` Robert Dewar 1997-05-08 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-05-07 0:00 UTC (permalink / raw) Bob said <<Of course, I admit that the C standard is easier to understand on this particular point, if you're just a programmer trying to write programs, and not a language lawyer. The Ada standard goes out of its way to raise questions of this nature, unfortunately. Nonetheless, I claim that the requirements of C and Ada are identical with respect to whether free/Unch_Dealloc must/should reclaim storage. They're just written in a different style.>> Well you are the author, so if you say the C standard is easier to understand on this point, I suppose that must have some force. But let me quote again the words you wrote here in the Ada standard: 17 For a standard storage pool, Free should actually reclaim the storage. That sure seems like an easy-to-understand unambiguous statement of intent to me, I don't see it any harder to understand than the referenced statement from the C standard. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-07 0:00 ` Robert A Duff 1997-05-07 0:00 ` Robert Dewar @ 1997-05-08 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 30+ messages in thread From: Robert I. Eachus @ 1997-05-08 0:00 UTC (permalink / raw) In article <E9sAq2.HE8@world.std.com> bobduff@world.std.com (Robert A Duff) writes: > Of course, I admit that the C standard is easier to understand on this > particular point, if you're just a programmer trying to write programs, > and not a language lawyer. The Ada standard goes out of its way to > raise questions of this nature, unfortunately. Nonetheless, I claim > that the requirements of C and Ada are identical with respect to whether > free/Unch_Dealloc must/should reclaim storage. They're just written in > a different style. The three reasons that the Ada standard doesn't always require deallocation to do anything are finalization, storage pools, and tasking. It is easy to say, that Ada should require that storage is always freed, but if you free a running task, or an object whose finialization never completes, or an object in a storage pool with a user supplied Deallocate procedure, the standard can't require immediate deallocation. In all other cases, as I read 13.11.2(10) the wording is pretty similar to the C standard. And of course the three exceptions above are not that likely to disturb anyone in real programs. (Unless the actual behavior of the Deallocate or Finalize routine involved is due to a bug, not design.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-04 0:00 ` Robert Dewar 1997-05-06 0:00 ` Kaz Kylheku @ 1997-05-09 0:00 ` Erik Magnuson 1997-05-10 0:00 ` John G. Volan 1997-05-10 0:00 ` Robert Dewar 1 sibling, 2 replies; 30+ messages in thread From: Erik Magnuson @ 1997-05-09 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > BUT, does this matter in practice? Of course not, all Ada compilers always > have followed this advice for the standard storage pool, and it would be > surprising if it were otherwise. This is exactly the same situation as > observing that all C compilers actualy free storage when free is used. > > Is it possible to make a formally conforming implementation in which > unchecked deallocation is useless. Most certainly. It is also possible > to make a formally conforming impl,ementation in which all integr > additions take one hour to complete. Bothy implementations are formally > correct according to the standard, both are totally useless! Robert, your claim is a little broad here. I have used 2 different Ada 83 compilers runtimes for embedded targets that did NOT implement any storage reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to null. (One of these was the small runtime from a company you used to work with!) Now, both of these compilers also had versions that supported reclaiming storage. But for small, embedded systems, it is often nice to have a simple "new" that you can use at startup without including any overhead for UC. If you believe that these compilers were useless, you had better not fly on any modern commercial airliner. -- Erik ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-09 0:00 ` Erik Magnuson @ 1997-05-10 0:00 ` John G. Volan 1997-05-10 0:00 ` Robert Dewar 1997-05-12 0:00 ` Erik Magnuson 1997-05-10 0:00 ` Robert Dewar 1 sibling, 2 replies; 30+ messages in thread From: John G. Volan @ 1997-05-10 0:00 UTC (permalink / raw) Erik Magnuson wrote: > Robert, your claim is a little broad here. I have used 2 different Ada 83 > compilers runtimes for embedded targets that did NOT implement any storage > reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to ^^^^^^^^^^^^^^^^^^^^ ^^ Unchecked_Deallocation UD Well, we knew what you meant to say. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Disclaimer => "These opinions were never defined, so using them " & "would be erroneous...or is that just nondeterministic now? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-10 0:00 ` John G. Volan @ 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` Matthew Heaney 1997-05-12 0:00 ` Erik Magnuson 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-05-10 0:00 UTC (permalink / raw) John Volan said <<Erik Magnuson wrote: > Robert, your claim is a little broad here. I have used 2 different Ada 83 > compilers runtimes for embedded targets that did NOT implement any storage > reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to>> (UC => UD as per later clarification) For an Ada 83 compiler with a narrow intended target of use (embedded targets), this may not be a bad choice. Many coding standards for high reliability code allow dynamic allocation, but do NOT allow dynamic freeing (the former is safe and easy to analyse, the latter potentially dangerous and very hard to analyze). So, I can certainly see that this choice might make sense for such a compiler. I was really thinking in terms of general purpose Ada 83 compilers when I made the statement. But in any case, the storage pools of Ada 95 give a much greater level of control. For examle, in the embedded case, you could use the storage pools to a) completely forbid deallocatoin b) ignore deallocation c) implement an alloc/free that had bounded time behavior etc. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-10 0:00 ` Robert Dewar @ 1997-05-10 0:00 ` Matthew Heaney 1997-05-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Matthew Heaney @ 1997-05-10 0:00 UTC (permalink / raw) In article <dewar.863277551@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >But in any case, the storage pools of Ada 95 give a much greater level >of control. For examle, in the embedded case, you could use the storage >pools to > >a) completely forbid deallocatoin >b) ignore deallocation >c) implement an alloc/free that had bounded time behavior a) By forbid do you mean detect (and therefore prevent) deallocation at compile time? Can you explain these with examples? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-10 0:00 ` Matthew Heaney @ 1997-05-11 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-05-11 0:00 UTC (permalink / raw) Matthew asks <<>a) completely forbid deallocatoin >b) ignore deallocation >c) implement an alloc/free that had bounded time behavior a) By forbid do you mean detect (and therefore prevent) deallocation at compile time? Can you explain these with examples?>> a) body = "raise Program_Error" b) body = "null" c) body = "complicated allocatoin algorithm left as reader excercise :-) By forbid I mean raise Program_Error, if you want to prevent dealloation at compile time, you use pragma Restrictions (it's all in the RM!) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-10 0:00 ` John G. Volan 1997-05-10 0:00 ` Robert Dewar @ 1997-05-12 0:00 ` Erik Magnuson 1 sibling, 0 replies; 30+ messages in thread From: Erik Magnuson @ 1997-05-12 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > Erik Magnuson wrote: > > reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to > ^^^^^^^^^^^^^^^^^^^^ ^^ > Unchecked_Deallocation UD > > Well, we knew what you meant to say. Thanks. Somehow the threads on "no code for Unchecked_Conversion" and this one collided in my local namespace... (Would I have made the same mistake if the routines were called Conversion_Unchecked and Deallocation_Unchecked ;-) -- Erik ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-09 0:00 ` Erik Magnuson 1997-05-10 0:00 ` John G. Volan @ 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` Matthew Heaney 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-05-10 0:00 UTC (permalink / raw) Erik said <<Robert, your claim is a little broad here. I have used 2 different Ada 83 compilers runtimes for embedded targets that did NOT implement any storage reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to null. (One of these was the small runtime from a company you used to work with!) Now, both of these compilers also had versions that supported reclaiming storage. But for small, embedded systems, it is often nice to have a simple "new" that you can use at startup without including any overhead for UC. If you believe that these compilers were useless, you had better not fly on any modern commercial airliner.>> (finally I see your original post, rather than a quote of a piece of it) It is DEFINITIELY appropriate for an Ada 83 compiler to offer a choice of storage allocators in this manner. Actually it is interesting to note that from what you say, they DID provide unchecked deallocation that worked via an option. In fact I can imagine an Ada 83 compiler for an embedded system which simply completely ignored UC under all circumstances, and as you rightly point out, this is often an appropriate choice for small embedded systems. Actually what you really want in this case is not a UC that does nothing at runtime, you want to declare access types for which UD (oops UC => UD throughout, I'm copying your mistake :-) is simply not permitted, period. Note that in Ada 95, providing you are using a compiler, such as GNAT, that fully supports annex H, then you have *exactly* what you need via pragma Restrictions (No_Unchecked_Deallocation); this will cause a program to be illegal if it attempts to instantiate Unchecked_Deallocation -- just what you want for your small embedded system example. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-10 0:00 ` Robert Dewar @ 1997-05-10 0:00 ` Matthew Heaney 0 siblings, 0 replies; 30+ messages in thread From: Matthew Heaney @ 1997-05-10 0:00 UTC (permalink / raw) In article <dewar.863287346@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >Note that in Ada 95, providing you are using a compiler, such as GNAT, that >fully supports annex H, then you have *exactly* what you need via > > pragma Restrictions (No_Unchecked_Deallocation); > >this will cause a program to be illegal if it attempts to instantiate >Unchecked_Deallocation -- just what you want for your small embedded system >example. Is this restriction global, or can you forbid deallocation on a per access type basis? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <199705010554.WAA24507@ni1.ni.net>]
* Re: Flexible Strings (was Equality operator...) [not found] <199705010554.WAA24507@ni1.ni.net> @ 1997-05-01 0:00 ` W. Wesley Groleau (Wes) 1997-05-02 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: W. Wesley Groleau (Wes) @ 1997-05-01 0:00 UTC (permalink / raw) (Also posted to comp.lang.ada) :> >I never had a problem implementing an Ada-83 equivalent of bounded strings :> >so that no heap was required. Did it pretty much as Matt Heaney suggested, :> >after reviewing a couple of "free" dynamic_strings packages and finding :> >that nearly every operation leaked heap. :> :> The problem with Ada 83 is that when you do need it, memory leaks are bound :> to happen, because clients often forget to clean up the data structure. The problem with the packages I was offered was that the clients COULDN'T clean up the heap. These guys had every string on the heap, and if a client wanted to say A := A & B the result was a new allocation overwriting the previous pointer in A. :> I got the "+" idea from Barnes' book. Don't think of it as a hack; think :> of it as what it is: the identity operator. It's a happy medium between :> the 2 extremes. I agree with you that automatic conversion is generally harmful. And that too much explicit conversion is information hiding of the wrong sort, i.e., hiding the abstraction in implementation clutter. The thing with "+" is more an issue of retraining one's instincts--after more than 35 years, it's hard not to think of it as something associated with quantities. But then, the strangeness of it is a point in its favor because it catches the attention. If it were routine, being only a single character, it could easily be overlooked. --------------------------------------------------------------------------- W. Wesley Groleau (Wes) Office: 219-429-4923 Hughes Defense Communications (MS 10-41) Home: 219-471-7206 Fort Wayne, IN 46808 (Unix): wwgrol@pseserv3.fw.hac.com -- SPAM should be sent to I.want.one@mailbombs.for.idiots.org If you want to be prosecuted under 27 USC 227, go ahead and send it here. --------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Flexible Strings (was Equality operator...) 1997-05-01 0:00 ` W. Wesley Groleau (Wes) @ 1997-05-02 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-05-02 0:00 UTC (permalink / raw) Wes said <<I agree with you that automatic conversion is generally harmful. And that too much explicit conversion is information hiding of the wrong sort, i.e., hiding the abstraction in implementation clutter. The thing with "+" is more an issue of retraining one's instincts--after more than 35 years, it's hard not to think of it as something associated with quantities. But then, the strangeness of it is a point in its favor because it catches the attention. If it were routine, being only a single character, it could easily be overlooked.>> Jean Ichbiah argued strongly during the Ada 95 design for introducing one additional unary operator that would have no predefined meaning, to be used for these kind of conversion operations. I supported that, and suggested the possibility of using the international currency conversion symbol for this purpose (it is sometimes called pillow). However, we seemed to be alone, and others did not like the idea, so must not be a good idea after all :-) ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~1997-05-12 0:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-04-30 0:00 Flexible Strings (was Equality operator...) W. Wesley Groleau (Wes) 1997-04-30 0:00 ` Matthew Heaney 1997-05-01 0:00 ` Robert Dewar 1997-05-02 0:00 ` Kevin Cline 1997-05-03 0:00 ` Jon S Anthony 1997-05-03 0:00 ` Robert Dewar 1997-05-04 0:00 ` Kevin Cline 1997-05-04 0:00 ` Robert Dewar 1997-05-06 0:00 ` Kaz Kylheku 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Kevin Cline 1997-05-07 0:00 ` Robert A Duff 1997-05-07 0:00 ` Matthew Heaney 1997-05-07 0:00 ` Jon S Anthony 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Jon S Anthony 1997-05-07 0:00 ` Robert Dewar 1997-05-07 0:00 ` Robert A Duff 1997-05-07 0:00 ` Robert Dewar 1997-05-08 0:00 ` Robert I. Eachus 1997-05-09 0:00 ` Erik Magnuson 1997-05-10 0:00 ` John G. Volan 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` Matthew Heaney 1997-05-11 0:00 ` Robert Dewar 1997-05-12 0:00 ` Erik Magnuson 1997-05-10 0:00 ` Robert Dewar 1997-05-10 0:00 ` Matthew Heaney [not found] <199705010554.WAA24507@ni1.ni.net> 1997-05-01 0:00 ` W. Wesley Groleau (Wes) 1997-05-02 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox