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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!postnews.google.com!s13g2000prd.googlegroups.com!not-for-mail From: Eric Hughes Newsgroups: comp.lang.ada Subject: Re: Limited initialization for non-limited types Date: Wed, 26 Mar 2008 20:25:05 -0700 (PDT) Organization: http://groups.google.com Message-ID: <05336885-5b45-4b2d-b27c-733c2002ca58@s13g2000prd.googlegroups.com> References: NNTP-Posting-Host: 166.70.57.218 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1206588305 17004 127.0.0.1 (27 Mar 2008 03:25:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 27 Mar 2008 03:25:05 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s13g2000prd.googlegroups.com; posting-host=166.70.57.218; posting-account=5RIiTwoAAACt_Eu87gmPAJMoMTeMz-rn User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20598 Date: 2008-03-26T20:25:05-07:00 List-Id: On Mar 26, 4:13 pm, "Randy Brukardt" wrote: > 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. The real goal I'm looking for is to suppress the extra calls to Initialize/Adjust/Finalize. The main obstacle is that the call to Initialize which has the "right" initial values is in the function body and the call to Initialize which has the ultimate 'Access value is in the declaration. For limited types, I presume this implies that the 'Access value is passed implicitly to the function. Hence for this to work at all there would have to be restrictions on the function used for initialization. The exact restrictions are beside the main point here, only that there is some restriction, which, then, would require some kind of declaration on an acceptable function. (I didn't realize this when I first posted.) So this critique is well taken. It seems that a necessary component of a solution is to require a certain kind of return mechanism. > 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). OK. So there's a specification about how initialization works correctly. I had assumed (silently) that this specification would be expanded to have correct results both for assignment (including initial assignment) and for initialization, and that they would not be identical. So this implies an enlarged specification. I would assume that the same optimization principle would apply to this new piece of specification. There's a syntactic ambiguity between ":=" for initial assignment and ":=" for initialization. In retrospect, I find it unfortunate the same symbol was used. New syntax would be required to distinguish these for non-limited types. > I'd probably suggest finding a different approach. (Not that I can think of > one off-hand.) Well, I have an approach that will work, but it's pretty ugly. I posted in the hope that something would eventually be cleaner. Reviewing: 1) Declaration of a function suitable for non-assignment initialization. 2) New specification of controlled behavior with such initialization. 3) Syntactic distinction between assignment and initialization. I wasn't looking for this when I started this thread, but isn't this exactly what's needed to define a proper constructor function? > > 2) Variable-specific record components. [...] > > 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! I see three consequence with this idea. First, there's an existing assumption that the copy-length is the same as the allocation-length. I presume that all existing compilers conflate these (since there's no existing reason not to). The other assumption in this area is that the offset of the modifiable portion is zero. I see no reason to keep this as a default, but it's not necessarily so in general. My first pass recommendation is that the default layout in memory be two records, one for each half, allocated contiguously, with each part aligned on whatever natural word boundary the compiler already uses. With this layout, record copy is equally efficient as the existing case (except, perhaps, where both lengths must be passed implicitly for some reason). The second consequence is its "interference" with representation clauses. With an arbitrary record layout, let's just assume which includes bit fields, you'd need to generate a read-lvalue/mask-with- rvalue/write sequence to substitute for a straight copy. It's more code, and it might be tricky to get working perfectly, but there's nothing particularly mysterious about it. I'd guess this is where the heavy lifting is. The third consequence is that record extensions would require multiple block memory copies. That means more internal accounting and some extra code size. > > 4) Derived limited types. [...] > 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.) I'll save this discussion for another day. I don't consider my thoughts about it sufficiently well-formed yet for a proper discussion. Eric