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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,751584f55705ddb7 X-Google-Attributes: gid103376,public From: John G. Volan Subject: Re: Side-effect arithmetic again [was: Ada ... in embedded systems] Date: 1996/03/30 Message-ID: <4jk96p$ftv@dayuc.dayton.saic.com>#1/1 X-Deja-AN: 145070398 distribution: world references: <4iq4k7$1p6@fozzie.sun3.iaf.nl> content-type: text/plain; charset=ISO-8859-1 x-xxmessage-id: organization: Science Applications International Corp. (SAIC) mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-03-30T00:00:00+00:00 List-Id: In article Tucker Taft, stt@henning.camb.inmet.com writes: >In the suggested replacement, >where both operands are the result of 'Pos, the "preference" >rule for root numeric types (8.6(14)) will mean that they will both >be converted to root_integer, whose run-time base range is >defined to be System.Min_Int .. System.Max_Int. >See RM95 8.6(29) and 3.5.4(14). Okay, then it seems that this usage of 'Pos/'Val takes a discrete Item type value and a Standard.Positive value, expands both to the largest available integer size, adds them together, and then contracts the result back down to the size of the discrete Item type. If I've got that right, then this seems an inordinately expensive way of doing a simple addition/subtraction operation, just to achieve generality across all discrete types. (Of course, if Standard.Integer and the position numbers for Item type both already happen to correspond to the largest available integer type on your implementation, then no expansion and contraction would be done. But these days typically Standard.Integer is 32 bits and Standard.Long_Long_Integer is 64 bits, at least with most GNAT ports I've seen.) If we're going to do this for enumerated types, then I'd just assume stick with the original formula of: Item'Val(Item'Pos(This) + By) which would wind up using the "+" for Standard.Integer. As I understand it, whatever range you get for Standard.Integer is guaranteed to be implemented optimally well on whatever target architecture you're compiling for, and that range should correspond to what's possible for enumerated types. For an integer or modular Item type, I'd favor the more direct approach of using whatever "+"/"-" operator that type happened to have, and just let both parameters of the procedure be that type, as I described in the Integer_Arithmetic and Modular_Arithmetic packages. Same deal for Floating_Arithmetic and Fixed_Arithmetic, by the way. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature ( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Humorous_Disclaimer => "These opinions are undefined by SAIC, so" & "any use would be erroneous ... or is that a bounded error now?" ); ------------------------------------------------------------------------