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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!solnet.ch!solnet.ch!newsfeed.freenet.de!151.189.20.20.MISMATCH!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Thu, 24 Mar 2005 00:01:14 +0100 From: Georg Bauhaus Organization: future apps GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <1110329098.642196@athnrd02> <1110361741.551255@athnrd02> <422edaec$0$26554$9b4e6d93@newsread4.arcor-online.net> <1111464133.508323@athnrd02> <423fe9df$0$11476$9b4e6d93@newsread2.arcor-online.net> <1111521825.653841@athnrd02> <424094b0$0$11481$9b4e6d93@newsread2.arcor-online.net> <1111568404.687226@athnrd02> <42416659$0$11476$9b4e6d93@newsread2.arcor-online.net> <1111611226.253249@athnrd02> In-Reply-To: <1111611226.253249@athnrd02> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4241f47a$0$24073$9b4e6d93@newsread4.arcor-online.net> NNTP-Posting-Date: 23 Mar 2005 23:58:03 MET NNTP-Posting-Host: 5e5b1680.newsread4.arcor-online.net X-Trace: DXC=bkL^DG2]RNe;XK28C2J>>h:ejgIfPPlddjW\KbG]kaMhea\9g\;7Nmekm3eDF7gWShUUng9_FXZ=c>:=P9Ihe`Bh@Z?dZ]MOide X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:9844 comp.lang.c++:46930 comp.realtime:1641 comp.software-eng:5245 Date: 2005-03-23T23:58:03+01:00 List-Id: Ioannis Vranos wrote: >> The fastest possible element access in C++ is dereferencing a pointer. >> The fastest possible element access in STL/C++ is varying with container >> and method. >> >> Compare >> >> type Floor_Number is -2 .. 52; >> -- sky scraper >> >> type Door_Count is array(Floor_Number) of Natural; >> >> versus >> >> typedef char Floor_Number; >> typedef std::map Door_Count; > I can't understand why your code has faster access (I assume you mean > run-time efficiency). Door_Count array access is faster because while it acts like std::map, it is really an array. Omitting the association of the indexing number numbers (-2 .. 52) with the floors for the moment, these tests should demonstrate: #include #include // GNU: #include , __gnu_cxx::hash_map #include #include #define M 55 // array size #define N 10000 // assigments #define R 5000 // runs struct Test { // compare random access to keyed access void arrays() { int a[M]; for (int k = 0; k < N; ++k) a[k % M] = k; } void valarrays() { std::valarray a(M); for (int k = 0; k < N; ++k) a[k % M] = k; } void vectors() { std::vector a(M); for (int k = 0; k < N; ++k) a[k % M] = k; } void maps() { std::map a; for (int k = 0; k < N; ++k) a[k % M] = k; } void hash_maps() { std::hash_map a; for (int k = 0; k < N; ++k) a[k % M] = k; } }; int main() { Test t; for (int run = 0; run < R; ++run) t.arrays(); // t.valarrays(); // t.vectors(); // t.maps(); // t.hash_maps(); return 0; } > To give another example, .NET does not provide such an array container > either, in its own containers collection. So why such a mainstream > framework does not provide an array type with negative indexing either? C# does provide fixing arrays. I think we can't buy high speed computing components from the producers of .NET. However, Fortran for .NET is available. (Doesn't mean the producers of libraries will use non-default index value in Fortran code.) So is APL. > This is not some kind of general proof, but for me it is an indication. > Again, I agree that boundary checking etc are useful and should be added > in C++ perhaps with additional keywords. Have you had a look at D? > Just to be technically accurate. C++ has fixed size built in arrays. It > doesn't provide range checking for them though. OK. And lets see what happens when the C99 arrays will be adopted. Georg