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,effb80d4bb7716dd X-Google-Attributes: gid103376,public From: adam@irvine.com Subject: Re: Pointer Arithmetic (was: Wanted: Ada STL....) Date: 1999/02/02 Message-ID: <797na3$obg$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 439872387 References: <790f4q$3l@bgtnsc01.worldnet.att.net> X-Http-Proxy: 1.0 x7.dejanews.com:80 (Squid/1.1.22) for client 192.160.8.21 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Tue Feb 02 20:30:58 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/3.0 (X11; I; Linux 2.0.34 i686) Date: 1999-02-02T00:00:00+00:00 List-Id: In article , Ehud Lamm wrote: > It seems that one problem in implementing STL in Ada95 is the lack of > pointer arithmetic. This causes perofremance problems in real sense (to > be exact the result is worse from a complexity point of view). This is a > "nice" result in that it tells you something about the price you pay for > pointer abstraction etc. However it is sad from a practical point of view. > I haven't really pursued this, so I can't vouch that there isn't some > trick to solve this problem. I don't know how this relates to STL, but I think I can see what the poster is getting at. Pointer arithmetic can be efficient when you're trying to step through an array, since you don't have to keep multiplying an index by a constant value to access the array elements. I'm not sure how much of a difference that makes these days---chips have gotten so fast that multiplication might not be that big a deal any more. But anyway, let's assume for argument's sake that efficiency is a concern and that we want to avoid multiplication if we can. I believe one of the strengths of Ada is that it gives implementors choice about how to implement data. Unless you use Unchecked_Conversion or other overlaying tricks, you really don't care just what bits are stored in a variable. (I don't believe C/C++ gives this kind of flexibility, although I haven't read the standards for those languages.) So is there any reason an implementor couldn't provide pointer arithmetic with a pragma like: type My_Index is range 0 .. 100; Arr : array (My_Index range 1 .. 100) of Some_Nasty_Record_Type; pragma Index_Into_Array (My_Index, Arr); This pragma states that all objects of type "My_Index" will be indexes into the array object Arr, and that therefore they could be implemented as pointers to array elements. So if Index is declared as type "My_Index", then "Index := 1;" would set Index to the address of Arr(1); "Index := Index+3;" would increment Index by three times the size of Some_Nasty_Record_Type; and indexing Arr (e.g. Arr(Index).Field) would be a pointer dereference, as in C. Questions: (1) Is there anything in the RM that would make such an implementation of My_Index illegal? (2) Has any compiler vendor tried something like this? -- Adam -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own