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,efc9f994d31d0d5e X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Limited initialization for non-limited types Date: Wed, 26 Mar 2008 17:13:14 -0500 Organization: Jacob's private Usenet server Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1206569692 4112 69.95.181.76 (26 Mar 2008 22:14:52 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 26 Mar 2008 22:14:52 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:20594 Date: 2008-03-26T17:13:14-05:00 List-Id: "Eric Hughes" wrote in message news:b481036a-41ee-4fc5-a0d0-c73cfef60234@s19g2000prg.googlegroups.com... > Is there any way of getting in-place initialization for non-limited > objects? This would be similar to that for limited types as specified > in ARM05/7.5(8.1/2). There's no way to require it. And I wouldn't expect that to change - *requiring* implementations to be able to call a single function with different return mechanisms seems way over the top. (Of course, implementations are *allowed* to do that if they like.) There is a second reason: implementations are allowed to optimize non-limited controlled types in almost any way that is "correct" (that is, an initialized object gets finalized). OTOH, limited controlled types are not allowed to be optimized at all. Even if if the object is never directly used. The net effect is that the operations of non-limited controlled types cannot depend on the order that the operations will be called (anywhere), while limited controlled can always be depended on. Such dependence in non-limited controlled is just wrong; it's likely to break if the code is moved to a different compiler (or even a newer version of the same compiler, as Bob points out). > Unfortunately, this is not a hypothetical question. I'm writing a > test object used within the unit tests a certain package. The test > object is instrumented for white-box testing; it contains a trace > object as a component. I want to trace the three events of > Ada.Finalization.Controlled. The trace object is associated with the > variable itself, not with any value that the variable might contain. I'd probably suggest finding a different approach. (Not that I can think of one off-hand.) ... > 2) Variable-specific record components. Consider this: > > type X is new Ada.Finalization.Controlled with > record > -- value components (ordinary) > private > -- variable components (persistent) > T : Trace ; > end record ; > > The idea is that components in the private section are simply not > copied under assignment. Interesting, but sounds messy to implement, because it would complicate the "bit-copy" part of the assignment. That's not usually done component-by-component! > 3) Anonymous limited types. I don't see any particular reason why the > semantics couldn't be worked out for the following declaration: > > B : limited Any_Type := Initial_Value_Function ; > > The ARM is littered with references to phrases such as "the limited > view of a type". What are the semantic difficulties with this? For > single declarations they seem to be modest. Isn't this almost the > same as an in-but-not-out parameter to a procedure? Anonymous types are a cancer as it is, we surely don't need any more of them. (Besides, they rarely actually work, since it's usually the case that you need to write a type conversion or membership somewhere, and you can't do that without a name.) > 4) Derived limited types. The ARM states (roughly) that a limited > type must derive from limited types. But what about a type that is > explicitly a limited view of a possibly not-limited type? > > type C is overriding limited new Any_Type ; That's already possible for untagged types - any limited private type can be completed by a non-limited type (including a derivation of some other type). For tagged types, it would lead to a mess because you could use the class-wide root type to copy limited extension components. (And if you try to ban such components, you're going to have to break privacy.) So, just write: package P is type C is limited private; -- Operations on C. private type C is new Any_Type; end P; Randy.