From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2925b133078d1557 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Flexible Strings (was Equality operator...) Date: 1997/04/30 Message-ID: #1/1 X-Deja-AN: 238585205 References: <9704301422.AA07755@most> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-04-30T00:00:00+00:00 List-Id: In article <9704301422.AA07755@most>, "W. Wesley Groleau (Wes)" 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 (818) 985-1271