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!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Controlled types as interfaces Date: Fri, 29 Aug 2014 18:54:24 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <17zg1do470nci.15209dgoz3ktk.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1409356465 21132 69.95.181.76 (29 Aug 2014 23:54:25 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 29 Aug 2014 23:54:25 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:22004 Date: 2014-08-29T18:54:24-05:00 List-Id: "Robert A Duff" wrote in message news:wcc4mwv731x.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: ... >> Note that in the OP's example, Janus/Ada does NOT treat the enclosing >> record >> as controlled; each individual controlled object (including components) >> is >> managed separately. I did it that way to make unwinding an object in the >> face of exceptions during construction easier (each object is registered >> as >> it is constructed, so all successfully constructed objects get finalized >> and >> none that failed get finalized). GNAT, OTOH, does treat each object > ^ not >> individibly and has to go through some handstands so that objects that >> aren't constructed aren't finalized. > > I think you're missing a "not" there. I don't think so, but I don't claim to understand what GNAT does that well. > Yes, there are some "handstands", > but it's not so bad. I think the only reason it was so hard to > implement is that it was a re-implementation. Doing it that way from > the start would not have been so bad (as is often the case). > > The compiler generates a "deep_initialize" procedure for each type, > which either fully initializes everything, or else finalizes the parts > that got initialized before an exception. Initialize routines like that are fiendishly complex (we do initializes that way), especially because the combination of discriminant dependent components and recursion to handle subcomponents. Trying to include finalization in there would have caused madness, at a minimum when something goes wrong. (They're literally impossible to debug, and I always find something else to do rather than work on those routines. Sorry, Tero. :-) Also, doing that requires that every call and check be effectively wrapped with an exception handler since one has to know the exact point of failure. For checks, that's not too bad as the check could be replaced by a branch. But for calls, that can be expensive depending on the exception handling scheme. (It's probably tractable for GNAT because of the zero-cost exception handling, although that is clearly an additional source of complexity; for Janus which uses a registration scheme, the cost would be way too expensive to use regularly.) As always with compiler construction, YMMV. Randy.