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: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: warning: Storage_Error will be raised at run-time Date: 1997/12/16 Message-ID: <97121608442667@psavax.pwfl.com>#1/1 X-Deja-AN: 298700564 Sender: Ada programming language Comments: To: stt@houdini.camb.inmet.com X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" X-VMS-Cc: SMTP%"stt@HOUDINI.CAMB.INMET.COM",CONDIC Newsgroups: comp.lang.ada Date: 1997-12-16T00:00:00+00:00 List-Id: Tucker Taft writes: >: ... >: 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. > I think that was kind of what I was shooting at: I may need one object with 5 characters in it and another object with a thousand. If that means that all objects of the type have to allocate a thousand bytes, then it seems like you loose any advantage of having a discriminant - just allocate the string to be a thousand bytes long from the get-go. The DEC Ada compiler at least gives the appearance of doing what I'm looking for in this case - at least it never issued any warnings about Storage_Error. Is there any way to coerce the compiler into the behavior I want? (Allocating what I request off of the stack?) >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. > Yeah. And the bad news is that I'd probably be one of them complaining about speed. Of course in the particular case I'm dealing with at the moment, I'm building a fairly straightforward application on a Sun with no realtime constraints. Hence, dynamic behavior is not much of a concern - but wantonly wasting memory is. What would be nice is having some method of toggling between one implementation method and the other - perhaps a pragma? Or would it be more sensible to invent a different kind of "record" type which did dynamic allocation? 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 ============================================================================= "Outside of a dog, a book is man's best friend; inside a dog, it's too dark to read..." -- Groucho Marx =============================================================================