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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Fri, 10 Apr 2015 16:16:02 +0200 Organization: A noiseless patient Spider Message-ID: References: <87h9t95cly.fsf@jester.gateway.sonic.net><04f0759d-0377-4408-a141-6ad178f055ed@googlegroups.com> <871tk1z62n.fsf@theworld.com><87oan56rpn.fsf@jester.gateway.sonic.net><877fts7fvm.fsf@jester.gateway.sonic.net><87twwv66pk.fsf@jester.gateway.sonic.net><32ecaopodr1g.1xqh7ssdpa2ud.dlg@40tude.net><87pp7j62ta.fsf@jester.gateway.sonic.net><87pp7hb2xo.fsf@jester.gateway.sonic.net><5rxvgyes5xg8.1mqq86gacbsb1.dlg@40tude.net><87lhi5ayuv.fsf@jester.gateway.sonic.net> <87oan0aote.fsf@jester.gateway.sonic.net> <878ue3ff6y.fsf@jester.gateway.sonic.net> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 10 Apr 2015 14:15:07 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="24405"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19iG6dAvRdJcfsXq/EgWWwj7D1UhaMbeyM=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: Cancel-Lock: sha1:XZ8rgbB7FKu1Uzw9DokJEFe50KE= Xref: news.eternal-september.org comp.lang.ada:25507 Date: 2015-04-10T16:16:02+02:00 List-Id: On 10.04.15 01:35, Randy Brukardt wrote: > But how to do tracing without a lot of overhead?? One lightweight way of allocating and tracing might be so dumb that it is not always useful. But I don't know if it is never useful, or not useful enough to be considered. The point is to really request memory once, and then to do almost nothing. Nothing new here (arena pools). Imagine a procedure that manipulates a graph. Or tons of matrices. Or a sequence of short messages. You need "new T" for the objects(*). 1 - require the pool to have enough room for Max objects: one stretch of storage. 2 - make Allocate return the address of the next free storage element, etc.; remember the then next free storage element in the pool object. 3 - Deallocate does nothing. When the region ends, Finalize of the pool frees memory. So, I guess tracing overhead is one assignment for keeping track of the next free storage element's address. Depending on the algorithm, this might be wasteful or, on the contrary, use no more memory than the algorithm needs in any case. And the programmer does not need to consider Unchecked_Deallocation and finalization of the objects. (And one doesn't add a tag to all of the objects of that one specific type that the algorithm is using! 1st level cache is a scarce resource… ;-) That tie is inflexible anyway: Rather than turning some final event in an objects life into its only catch all, I'd find it more clear and more explicit to have objects that can react to events, somewhat like POs can react to interrupts. Freeing memory need not be an immediate consequence of some object's finalization. __ (*) With GCC, no large objects can be allocated on the stack anymore.