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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Fri, 11 May 2018 10:51:51 +0300 Organization: Tidorum Ltd Message-ID: References: <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> <87po27fbv9.fsf@nightsong.com> <87in7x62vw.fsf@nightsong.com> <878t8szdtk.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net SxPoctF3wMKMhXDi+S5NXgqBLwWIN56RaHrVEp+F6EgriJsFL/ Cancel-Lock: sha1:YYLPlNBkR/C4Poo6OVv7ag5QMYA= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader02.eternal-september.org comp.lang.ada:52247 Date: 2018-05-11T10:51:51+03:00 List-Id: On 18-05-11 02:15 , Dennis Lee Bieber wrote: > On Thu, 10 May 2018 23:47:25 +0300, Niklas Holsti > declaimed the following: >> >> The concept of "dynamic allocation" is interestingly vague. All >> real-time applications I've seen have dynamic allocation in various data >> buffers and queues, even if they never use the system heap. Of course, >> the designers foresee that the buffers and queues can become full, and >> design the application to be robust and degrade gracefully if that happens. >> > In my limited (4 years) exposure, the closest thing to "dynamic > allocation" took place during program initialization. Your "buffers and > queues" are allocated and set-up before the software transitions into > "running" state. Anything could take place during said initialization, but > once "running" everything was from pre-allocated memory regions. Yes yes, but at run-time the program allocates space dynamically, as needed, _in_ the buffers and queues, though usually not by the "new" keyword but by some application-defined "allocate buffer block" or "enqueue" operation. And these allocations can fail at run-time, at least under overload conditions. In Ada, one might define the buffers and queues as storage pools (themselves statically allocated) and use the "new" keyword to allocate space in a buffer or queue, and Unchecked_Deallocation to release the space. That would be entirely equivalent to the standard way of using statically allocated buffers and queues, but now the program would, probably, violate the coding rules that forbid "dynamic allocation", at least in the opinion of the product assurance staff. > And nothing is ever freed -- it merely moves from one application > controlled list/queue structure to another. Which dynamically frees the space in the first list/queue, from which the data are removed. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .