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!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada Annoyances Date: Fri, 23 Jun 2017 22:21:33 +0300 Organization: Tidorum Ltd Message-ID: <4921bd4e-3827-a7ac-7f2d-d60edbc514a3@tidorum.invalid> References: <1ac5a44b-4423-443a-a7bb-2864d9abe78f@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 0Iz+I8Tz0dYHgy2z1I0f3gsz1v37S2rfiF/BW2veiUyeg90ljm Cancel-Lock: sha1:caObWxsH1t4+2s8lZ+9bqNvsSX4= 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:47089 Date: 2017-06-23T22:21:33+03:00 List-Id: On 17-06-23 20:49 , Randy Brukardt wrote: > wrote in message > news:be1619b4-2220-4287-8e67-1af32377d3f7@googlegroups.com... > ... >> Ada forcing tagged types on you to use certain features *is* a >> problem, if only because certain Ada users are forbidden to >> use tagged types altogether and thus are prevented to use a >> lot of useful features. > > Stupid language usage rules are not the problem of the language design, > they're a management problem. Sometimes usage rules are imposed by environment constraints, in particular limited resources in smallish embedded systems, combined with reliability requirements which mean that running out of resources at run time must be avoided. > I can understand banning T'Class (thus banning > dynamic dispatching) and banning controlled types (thus banning hidden calls > that can be harder to analyze), but not banning tagged types themselves. I have so far avoided using tagged types in my embedded applications because they indeed hamper the discovery of resource usage (execution time and stack space) by static analysis, as you said. There are two reasons why tagged types hamper such analysis: 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. Point (a) can be worked around: static analysis tools usually let the analyst specify the possible set of callees for a "dynamic call" (of which dispatching calls are one kind) and the analysis can then encompass all those callees. (Alternatively, the analysis tool can extract the class hierarchy from the debugging information, and itself discover the possible callees.) Point (b) is more difficult and I know of no work-around that can be applied at analysis time. 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; type Child is new Root with record ... end record; -- The compiler checks that Child'Size is at most 128 bits, and -- rejects the program otherwise. It would now be legal to create statically sized data structures using Root'Class, without dynamic memory allocation, by allocating 128 bits for each value of type Root'Class: type Object_List is array (List_Index) of Root'Class; type Object_Pair is record A, B : Root'Class; end record; and so on. With this extension, or some other means to solve point (b), I would start using tagged types in embedded SW. For example, I have a major SW component, used in several projects, which simulates a class hierarchy with variant records and case statements. This component would be greatly improved by using a tagged type instead, but it would need data structures with class-wide components of static (maximum) size. What do people think of a Maximum_Size aspect? Should I consider writing a formal suggestion to ada-comment? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .