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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Flexible Strings (was Equality operator...) Date: 1997/05/10 Message-ID: #1/1 X-Deja-AN: 240634412 References: <9704301422.AA07755@most> <3F2AA8DEC61418AE.502E81A8ECA1C4E7.3A25DE2FB38755A4@library-proxy.airnews.net> <3374220A.74D0@sprintmail.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-05-10T00:00:00+00:00 List-Id: John Volan said < Robert, your claim is a little broad here. I have used 2 different Ada 83 > compilers runtimes for embedded targets that did NOT implement any storage > reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to>> (UC => UD as per later clarification) For an Ada 83 compiler with a narrow intended target of use (embedded targets), this may not be a bad choice. Many coding standards for high reliability code allow dynamic allocation, but do NOT allow dynamic freeing (the former is safe and easy to analyse, the latter potentially dangerous and very hard to analyze). So, I can certainly see that this choice might make sense for such a compiler. I was really thinking in terms of general purpose Ada 83 compilers when I made the statement. But in any case, the storage pools of Ada 95 give a much greater level of control. For examle, in the embedded case, you could use the storage pools to a) completely forbid deallocatoin b) ignore deallocation c) implement an alloc/free that had bounded time behavior etc.