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,b8b8a54001adc4d2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.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: Possible Ada deficiency? Date: 08 Jan 2005 15:03:09 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> <1104544963.930877.75170@c13g2000cwb.googlegroups.com> <1104595073.731663.180100@c13g2000cwb.googlegroups.com> NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1105214589 24436 69.38.147.31 (8 Jan 2005 20:03:09 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 8 Jan 2005 20:03:09 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:7573 Date: 2005-01-08T15:03:09-05:00 List-Id: Jeffrey Carter writes: > Robert A Duff wrote: > > The main thing is that the compiler needs to know the size of a private > > type in order to allocate things, unless it treats all private types as > > dynamic-sized, which would be annoying -- you shouldn't have to pay an > > efficiency cost to get the benefits of encapsulation, information > > hiding, etc. So if the full type were in the body, the compiler would > > have to look at the body (at least in optimizing mode). > > It's always seemed to me that such types could be implemented as access > types, allocated where declared, deallocated when they went out of > scope, and with all operations dealing with the designated value, not > the access value. That could work. But you don't *need* to do any heap allocation. If you say: subtype My_String is String(1..X); where X is a run-time quantity, and: type R is record A, B, C: My_String; end record; Obj: R; most compilers will implement Obj as a contiguous hunk of storage. Accessing the components of Obj requires adding the appropriate offsets to the address of Obj (at run time). But it's still more efficient than putting the three strings on the heap. Note that the upper bound of My_String is typically stored just once -- not in every object of type R. And the lower bound need not be stored at all. (If A,B,C were aliased, then every object of type R would typically contain 3 lower bounds and 3 upper bounds.) If the compiler can't see the full type of a private type, then it could do the same thing as for My_String -- just assume that the size is a run-time quantity. And, I suppose, assume worst-case alignment. But I still don't like it. I think there should be *zero* overhead for making a type private. > All such types would, of course, be passed by reference. Well, that would require changing the current rules, which require pass-by-copy for a private type if the full type is elementary. (I don't much like the existing rules in this area, but I'm not sure the change suggested here would be an improvement. It would be seriously incompatible, for one thing.) - Bob