From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Proposal: Auto-allocation of Indefinite Objects Date: Mon, 10 Aug 2020 10:57:44 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> NNTP-Posting-Host: 2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:59700 List-Id: On 10/08/2020 02:39, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:rfv3gf$1bbo$1@gioia.aioe.org... >> I don't want the compiler deciding where Q is allocated, especially >> because this could break things: >> >> 1. Large object moved to the stack > > The compiler is buggy IMHO if this breaks something. Any compiler has to be > able to deal with objects that exceed the maximum stack frame, and move > those to somewhere that they will fit (or reject completely). > > Yes, most compilers are buggy this way (including mine in a few cases). So > what? > >> 2. Lock-free code starting using heap lock when moved from the stack. > > Expecting a compiler not to use the heap is silly in any case (outside of > the No_Heap restriction - use that in Janus/Ada and the compiler refuses to > do anything outside of elementary types). The compiler is supposed to be > making the programmer's life easier, not adding new hurdles. > >> The mechanism should be transparent. I do not like Unbounded_String for >> many reasons. Fiddling with the heap is one of them. I do not know which >> heuristic it uses to reduce reallocation and how much extra memory it >> takes under which circumstances. > > That's the idea of such mechanisms. If you really need control, you do not > use these abstractions and instead write the stuff yourself explicitly using > access types and the like. Right, that is my take on the proposal. If I am ready to compromise on #1 and #2, I can use an abstraction hiding pool access. Otherwise I want a language construct being more safe than raw access types. > Otherwise, you use containers and unbounded strings, and they do what they > do. No, from the abstraction point of view they do not. They indeed abstract the memory allocation aspect, but they do that at the cost of *everything* else. Unbounded_String is no string anymore. Container is neither array nor record type. Unbounded_String must be converted forth and back. For containers I must use ugly hacks like iterators to make them resemble arrays and records introducing whole levels of complexity to fight through every time the compiler or I miss something. In most cases I prefer to keep a clear array or record interface at the expense of manual memory management. > There's no free lunch. I think with a better type system there could be a whole banquet. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de