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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!seas.gwu.edu!mfeldman From: mfeldman@seas.gwu.edu (Michael Feldman) Newsgroups: comp.lang.ada Subject: Re: implicit array type conversion Message-ID: <2052@sparko.gwu.edu> Date: 27 Jul 90 17:13:43 GMT References: <1990Jul26.132742.3828@planck.uucp> <1469@software.software.org> Reply-To: mfeldman@seas.gwu.edu () Distribution: na Organization: The George Washington University, Washington D.C. List-Id: In article <1469@software.software.org> collard@software.org (David Collard) writes: >In article <1990Jul26.132742.3828@planck.uucp> acsu.buffalo.edu!planck!hercules!westley () writes: > > type STRING(Len : Natural := 0) is > record > S : Standard.STRING(1..Len); > end record; > > B : String; > >If you change your declaration to this, then the assignment will not >raise a constraint error. >HOWEVER it still will not work because when the discriminant does have >a default and an object is declared using the default , then the compiler >will try to allocate enough space for the maximum value for the discriminant >(probably over 2 billion if Natural is 32 bits) which is > 1) Too much memory > 2) Is beyond the maximum length for a string on some machines. Well, maybe. Actually it is implementation-dependent. TeleSoft indeed allocates for the maximum, so the space never needs to be reallocated. Meridian allocates only a header block, then allocates dynamically as much space as is needed. What can other readers report about their compilers? The above example shows VERY POOR use of the type system, since a string is not likely to grow to integer'last characters. The correction below is just the right approach. This is also a good example of how Ada, for better or worse, leaves most storage-management issues to the implementer. I think this is appropriate, by the way, but one has to realize that it is so. Often the implementation dependent surprises can be minimized by intelligent use of types, as in this case. >What will work is: > > type String_Index is range 0..100; > > type String(Len : String_Index := 0) is > record > S : Standard.String(1..Natural(Len)); > end record; > > B : String; > > >But note that if the range of String_Index is large, you may be using >a lot more memory than is apparent. > >The discriminated record is not intended to support dynamic allocation >of different sized objects. If you really want dynamic allocation then >use an access type. I'm not sure I agree with this. I think people should try to minimize their use of access types, though this is clearly a matter of taste which we shouldn't get religious about. Discriminated records and unconstrained arrays - and a number of other features - aid in reducing the amount of recourse to access types. Given the risks and storage management problems associated - in all languages - with pointers, I encourage the use of these language-provided pointer-avoidance schemes. There is no free lunch, as the time/space tradeoffs inherent in this example make quite clear, and of course there is still no substitute for common sense. --------------------------------------------------------------------------- Prof. Michael Feldman Department of Electrical Engineering and Computer Science The George Washington University Washington, DC 20052 +1-202-994-5253 mfeldman@seas.gwu.edu ---------------------------------------------------------------------------