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!feeder.eternal-september.org!feed.usenet.farm!feeder3.usenet.farm!feeders.as203319.net!feeder01.as203319.net!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada Annoyances Date: Tue, 4 Jul 2017 22:30:23 +0300 Organization: Tidorum Ltd Message-ID: References: <1ac5a44b-4423-443a-a7bb-2864d9abe78f@googlegroups.com> <4921bd4e-3827-a7ac-7f2d-d60edbc514a3@tidorum.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 7j+Tk1S+T17GwSK4V/96KAvKCr2yGDuFH/b9S7M1Vwhs8qUlWr Cancel-Lock: sha1:Fkgs3UvfjolW/CqiMbXIR/jsbkc= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:47286 Date: 2017-07-04T22:30:23+03:00 List-Id: (Apologies for a delayed reply.) On 17-06-30 00:12 , Robert A Duff wrote: > Niklas Holsti writes: > >> There are two reasons why tagged types hamper such analysis: > > As Randy pointed out, it is more correct to say that class-wide types do > that. Tagged types by themselves do not cause these problems. > Tagged types without class-wide types are not super useful, > but they are somewhat useful. > >> a) dispatching calls (as you said), where the actual callee is >> determined by run-time values (tags) which are hard to predict by static >> analysis >> >> b) the non-static size of class-wide objects (of type T'Class), which >> means that the compiler and/or the programmer must use dynamic >> allocation (usually heap or secondary stack) for such objects. > ... >> For some time, I have had in mind a possible Ada extension to solve >> point (b): an attribute/aspect that would let the programmer set a >> static upper bound on the size of any object in T'Class. If we call this >> aspect Maximum_Size (or perhaps Maximum_Size'Class), the programmer >> could use it like this: >> >> type Root is tagged record ... end record >> with Maximum_Size => 128; > > Something like that was considered and rejected for Ada 9X. > Part of the problem is that it seems so low level to be talking > about sizes. It's not even portable. You are right, but this feature would be used only or mainly in embedded programs, which usually already contain unportable, low-level stuff: task stack sizes, record representation clauses, etc. > And not maintainable -- if you > delete a big type, or make it smaller, you're now wasting space. If the feature would be adopted, I imagine a friendly compiler would (at least optionally) tell me that I am wasting space, or that the given Maximum_Size is too small, and what would be the minimum valid value (as GNAT does now for 'Size clauses that give a too-small size) even if it requires some bind-time or link-time global check. That is a quality-of-implementation issue. > It would be better to have the compiler compute the maximum > size needed. That would require the compiler to do a fairly > global analysis, which is something Ada compilers are not > set up to do. Well, the "binder" part of the compilation system does some global stuff. And I would not be surprised if link-time "relocation"-type computations could be (mis-)used to compute the maximum size of any type in a class. Some compilers already support stack-size analysis, which is a similar global analysis. >> type Object_List is array (List_Index) of Root'Class; >> >> type Object_Pair is record >> A, B : Root'Class; >> end record; > > Would you allow: > > X : Object_List (1..10); > Y : Object_Pair; > > ? I would like to allow that (default initialized components of type Root'Class), but I would not much mind having to initialize such components explicitly. > If so, what is the 'Tag of the various components? > "Undefined" is not a very satisfying answer. I agree that "undefined" would not be good. The natural answer seems to be that the default initial tag is that of the Root type, but then we must assume that it is not an abstract type. > These things are analogous to records with defaulted discriminants. Yes, that has been my mental model (and it is the implementation used in the main SW component that I would like to switch over to class-wide types). > The language makes some (unsuccessful!) attempt to prevent > uninitialized discriminants. Interesting -- I did not know that the attempt is not fully successful. Is it easy to explain when the attemp fails? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .