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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4fe0da28a190b761 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder3.cambrium.nl!feed.tweaknews.nl!newsfeed.kamp.net!newsfeed.kamp.net!news.k-dsl.de!news.uni-stuttgart.de!news.belwue.de!LF.net!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: Storage management Date: Sun, 02 Nov 2008 15:27:58 +0100 Message-ID: <87abciurrl.fsf@mid.deneb.enyo.de> References: <87fxmbog1u.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: idssi.enyo.de 1225636078 32451 212.9.189.177 (2 Nov 2008 14:27:58 GMT) X-Complaints-To: Cancel-Lock: sha1:uTXGQUdn3CIgFX5pM3Wnjyxy1gA= Xref: g2news1.google.com comp.lang.ada:2555 Date: 2008-11-02T15:27:58+01:00 List-Id: * Robert A. Duff: > Florian Weimer writes: > >> What is the current state of the art with regard to programmer support >> for storage management? >> >> With GNAT, Ada.Finalization adds tons of run-time calls to deal with >> abort deferral (even with pragma Restrictions (No_Abort_Statements)), >> puts the object on some sort of list, and does some secondary stack >> allocations which I don't understand. Clearly, this is not supposed >> to be used in performance-critical code, so I doubt it can be used for >> a generic smart pointer implementation. (Object allocation in inner >> loops is generally a bad idea, but this overhead is also incurred when >> copying smart pointers around.) > > AdaCore is actively working on making finalization much more efficient > (e.g. avoiding all those finalization lists, when possible). This sounds interesting. Unfortunately, the language-mandated overhead (primarily abort deferral) is difficult to get rid of. I hope that there will be a configuration pragma which eliminates it, even if it means using a self-compiled run-time. >> Is there some other approach? Can limited types be used to enforce >> linearity (in the sense of linear types, cf. >> and >> )? > > Yes, you can do better with limited types (derive from > Limited_Controlled instead of Controlled). Hmm. What I want is to mark certain subprograms as consumers, and get a warning when a subprogram is exited without calling a consumer subprogram for a local variable of limited type. OTOH, with overflow checking, there's a chance of raising an exception almost all the time, so I'll need something like Clear (Ref); exception when others => Clear (Ref); raise; end Proc; at the end of each procedure. So it's not actually desirable, either, even if tools support (maybe based on ASIS?) to enforce this coding style. > There is some intention to support proper GC at AdaCore, but it's going > to be rather far in the future -- not a whole lot of (paying) customer > demand for that. Meanwhile, you can try the Boehm "conservative" GC. I know, but I fear that some aspects are difficult to get 100% right. For instance, it seems necessary to change the way the secondary stack is allocated, so that it is scanned for pointers, too. I'm not sure if this can be done with a purely library-based approach.