Re: warning: Storage_Error will be raised at run-time

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

Tucker Taft <stt@HOUDINI.CAMB.INMET.COM> 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
=============================================================================