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,4e5770c49b971630 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: High-Integrity OO and controlled types Date: Sun, 01 May 2011 17:29:10 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1304285350 8035 192.74.137.71 (1 May 2011 21:29:10 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 1 May 2011 21:29:10 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:9PvPqNDT+j1s6yIUCnTtOyh0gUA= Xref: g2news2.google.com comp.lang.ada:20084 Date: 2011-05-01T17:29:10-04:00 List-Id: Maciej Sobczak writes: > "Controlled types are not supported since they require extensive run- > time support." > > This is surprising to me. I don't see anything in controlled types > that would require "extensive run-time support". Most of the "extensive run-time support" comes from heap-allocated objects containing controlled parts. If you say (for example, perhaps in a nested scope): type A is access T'Class; type T2 is new T with ...; X : A := new T2'(...); the language requires that Unchecked_Deallocation of X calls Finalize on all the controlled subcomponents of X.all, plus X.all itself if that's controlled. Also, that finalization of type A finalizes all objects in the "collection" that still exist (U_D wasn't called). This requires that the implementation keep track of which objects (that have some controlled parts) still exist. So "new" has to put the object on some sort of list, and U_D has to take it off the list, and finalization of the access type has to worry about all the objects still on the list, and worry about Finalize operations that (try to) do "new", putting more objects on the list. And that "list" (or whatever it is) has to be protected from concurrent access, via some sort of locking. Note that for "new T'Class'(...)", it is not necessarily known at compile time whether the new object has some controlled parts. Finalization also needs to deal with partially-initialized objects, and finalize exactly those subcomponents that were successfully initialized. That's all "extensive run-time support". >...Obviously, there is > some implicit additional code required for controlled types to work, > but as far as I understand this additional code can be entirely > generated by the compiler (in many cases even the dynamic dispatch can > be omitted) and no run-time library is necessary for it at all. In theory, yes, all of it could be compiler-generated code. But you really wouldn't want that. - Bob