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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Examining individual bytes of an integer Date: Thu, 18 Oct 2018 10:01:58 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <9d90fa3e-f800-4086-bf97-a65474a8140a@googlegroups.com> <4ddbc9bf-0e2e-466d-8238-d8f709b985e1@googlegroups.com> <35f53cd9-4979-49b8-a5df-2c1cf0764507@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:54624 Date: 2018-10-18T10:01:58+02:00 List-Id: On 2018-10-18 00:10, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:pq6r7i$1o47$1@gioia.aioe.org... >> On 2018-10-17 00:33, Randy Brukardt wrote: >> >>> That's the model for the entire compiler: all objects are >>> statically sized, and if needed, the actual data is found by indirection. >> >> That makes me missing RM rule (not advice): for any instance of >> >> new X >> >> Allocate of the corresponding storage pool is called exactly once. > > I would fight that at every level, since it would make a useful > implementation of discriminated records impossible. Ada has always been very > clear that non-contiguous representations are allowed. I know, but on the other hand it would make a lot of useful applications non-portable. > It might make sense to introduce some sort of aspect to require a contigious > representation for an array or record, so long as that's only required to be > supported on sensible types. I would rather consider a general method for handling all sorts of type constraints in a regular manner available for the programmer. This should include stripping constraints when statically known when the object is passed as a parameter and adding constraints when a statically constrained object gets dynamically constrained (e.g. slices, conversion to T'Class). We could use hidden parameters for this (such objects cannot be used for interfacing with other languages anyway, if that is a concern). Another point is calculation of such constraints in a separate body (possibly static) when doing assignment or allocation. Presently reasonable object initialization is impossible when constraints are dynamic. The same case: static checks for dimensioned arithmetic are impossible because the constraint (dimension) must be calculated in the same body as the operation itself, but we want it calculated and checked at compile time instead. > In particular, this type should work with raising Storage_Error or some > other exception on all Ada compilers: > > type Rec (D : Natural) is record > Arr : String (1 .. D); > end record; > > C0Rec : constant Rec(0) := (D => 0, Arr => ""); > C1Rec : constant Rec(1) := (D => 1, Arr => "R"); > A_Rec : Rec := C0Rec; > > A_Rec := C1Rec; > A_Rec := (D => 3, Arr => "RLB"); > > A type like this pretty much requires discontiguous representations and > reallocation on assignment. It is no loss, Storage_Error is OK to me. IMO no built-in type shall use hidden dynamic allocation, except when required by the target OS (e.g. for tasks). Anything that is impossible to implement otherwise must be moved to the library (like Unbounded_String). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de