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!feeder.erje.net!1.eu.feeder.erje.net!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada Annoyances Date: Wed, 05 Jul 2017 16:03:47 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1ac5a44b-4423-443a-a7bb-2864d9abe78f@googlegroups.com> <4921bd4e-3827-a7ac-7f2d-d60edbc514a3@tidorum.invalid> NNTP-Posting-Host: shell02.theworld.com Mime-Version: 1.0 Content-Type: text/plain X-Trace: pcls7.std.com 1499285027 3115 192.74.137.72 (5 Jul 2017 20:03:47 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 5 Jul 2017 20:03:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:1QOrmvtn1dED8R88/t4DkDOEEvY= Xref: news.eternal-september.org comp.lang.ada:47304 Date: 2017-07-05T16:03:47-04:00 List-Id: Niklas Holsti writes: > (Apologies for a delayed reply.) No need to apologize. I certainly only pay attention to comp.lang.ada occasionally. > 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. I would use it even in nonembedded systems. I don't buy the idea that just because some of one's embedded code needs to be nonportable/low-level, it's OK to force other stuff to be, when it's not logically necessary. If you're not interfacing with external hardware or similar, the compiler should compute record layouts/sizes. >> 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. If it can warn about too-large max size, then it can compute the max size for you. Yes, it has to be a global analysis. Too-small max size is easy -- that can be done at compile time for each type. > 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. Well, if you implemented this feature in GNAT, you'd be proven right. I don't think AdaCore is going to spend time on it any time soon. > Some compilers already support stack-size analysis, which is a similar > global analysis. Yes. ARG has always shied away from requiring such things. > 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. OK. >> 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. But root types are usually abstract. >> 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? Quite easy: Uninit : Integer; X : Some_Record (Discrim => Uninit); In a simple case like that, compilers likely warn. But it's not hard to hide the uninitialized variable from the compiler. E.g. a component of a heap-allocated record -- compilers can't warn about that, because it would cause too many false positives. - Bob