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,903f8471df09a778 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: warning: Storage_Error will be raised at run-time Date: 1997/12/15 Message-ID: #1/1 X-Deja-AN: 298518739 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <97121515433681@psavax.pwfl.com> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-12-15T00:00:00+00:00 List-Id: Marin David Condic, 561.796.8997, M/S 731-96 (condicma@PWFL.COM) wrote: : Maybe this one has been dealt with before. Using GNAT (GNAT 3.09 - : Sun Unix) I compile the attached code and get the following error : messages: : procedure Test is : type Variant_Type (Size : Natural := 0) is record : Count : Natural ; : Table : String (1..Size) ; : end record ; : Variant : Variant_Type ; : begin : null ; : end Test ; : test.adb:5:31: warning: creation of object of this type may raise Storage_Error : test.adb:8:05: warning: Storage_Error will be raised at run-time : My best guess is that the implementation takes a look at the : "(Size : Natural := 0)" part and decides that it needs to allocate : 1..Natural'Last bytes for the Table field of every object of type : Variant_Type. I can see how this would make it simple to handle : assignments to objects of type Variant_Type since they would have : already allocated memory for the worst case scenario. This seems : like a bad implementation choice in that, while it may be very : fast, doesn't allow the user much leeway. The alternative is to use the heap implicitly when an assignment needs to enlarge the object. This approach was adopted by Alsys under some conditions in their Ada 83 product, and something similar is supported by RR (and Meridian Ada 83) by using a level of indirection for nested arrays, but most other vendors did not embrace this approach. I believe the main reason is that implicit use of the heap, particularly as a side effect of a relatively "benign" looking operation like assignment, is a no-no in a real-time/safety-critical language. In Ada 95, if you want this kind of automatic "growing" data structure, then you can program it using controlled types. That seems like a better solution to me, because it gives the programmer full, explicit control over any use of the heap. : ... : While this sort of static allocation may be simple to implement : and fast at run time, it seems to defeat a major purpose of : discriminated records: the ability to allocate just what you need : at run time to accomodate widely varying space demands. Otherwise, : why not just go with a fixed size array in the record since that's : what you're going to get anyway? The purpose of discriminated records is not so much to accomodate individual growing objects, but rather to accommodate multiple objects of different sizes, which are nevertheless all of the same type. Furthermore, given our recent news thread on the implicit overhead of holey enumeration types, you can be sure someone would be complaining about the implicit overhead of assigning to unconstrained discriminated records. Implicit overhead is almost always bad news, IMHO. If there is to be overhead, the programmer ought to be explicitly writing and controlling the implementation of that "overhead" computation. : MDC : Marin David Condic, Senior Computer Engineer Voice: 561.796.8997 : Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600 Fax: 561.796.4669 : West Palm Beach, FL, 33410-9600 Internet: CONDICMA@PWFL.COM : =============================================================================== : Glendower: "I can call spirits from the vasty deep." : Hotspur: "Why so can I, or so can any man; but will they come when : you do call for them?" : -- Shakespeare, "Henry IV" : =============================================================================== -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA