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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 10ad19,23963231b5359f74 X-Google-Attributes: gid10ad19,public X-Google-Thread: 107a89,23963231b5359f74 X-Google-Attributes: gid107a89,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 11440e,23963231b5359f74 X-Google-Attributes: gid11440e,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-ArrivalTime: 2001-06-11 04:05:10 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!newsfeed00.sul.t-online.de!t-online.de!newsfeed.r-kom.de!feeder01.news.de.uu.net!news-1.bank.dresdner.net!not-for-mail From: James Kanze Newsgroups: comp.lang.ruby,comp.lang.ada,comp.lang.awk,comp.lang.clarion,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml Subject: Re: Long names are doom ? Date: Mon, 11 Jun 2001 12:56:03 +0200 Organization: Dresdner Bank AG Message-ID: <3B24A3C3.4B703FFC@dresdner-bank.com> References: <9f2nks$ibd$0@dosa.alt.net> <3B177EF7.2A2470F4@facilnet.es> <9f8b7b$h0e$1@nh.pace.co.uk> <9f8r0i$lu3$1@nh.pace.co.uk> <9fgagu$6ae$1@nh.pace.co.uk> <9fjgha$blf$1@nh.pace.co.uk> <35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com> <9fli1b$4aa$1@nh.pace.co.uk> <3B20E1B0.3EC7FEBB@dresdner-bank.com> <3B219DB3.4BF2A68A@acm.org> Reply-To: default@dresdner-bank.com NNTP-Posting-Host: ffzj09tz.bank.dresdner.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mozilla 4.7 [en]C-CCK-MCD drebazen10 (WinNT; I) X-Accept-Language: en,fr,de Xref: archiver1.google.com comp.lang.ruby:10544 comp.lang.ada:8533 comp.lang.awk:2975 comp.lang.clarion:21625 comp.lang.java.programmer:75235 comp.lang.pl1:965 comp.lang.vrml:3706 Date: 2001-06-11T12:56:03+02:00 List-Id: Patricia Shanahan wrote: > James Kanze wrote: > > Pete Thompson wrote: > > [...] > > > Well, sure. Pointer arithmetic in C/C++ is inherently unsafe > > > and encourages obfuscation. However, it also promotes > > > flexibility. > > Just curious, but what can you do with pointer arithmetic in C/C++ > > that you couldn't do otherwise, in a cleaner fashion? > ... > Manage memory. A memory allocator, such as malloc, or the > corresponding kernel code, or the code underlying "new", has a split > view of memory. It must perform calcuations to determine where to > put the the newly created object. It must return a pointer to it. True. Although there is something to be said for considering the memory as one big array, and the "pointers" as indexes into it. In fact, in this case, C's pointers have just enough type checking to get in the way and make the code a sloppy mess of typecasting. IMHO, a better solution would be to use real arrays (and indexes) where arrays are appropriate, and have an untyped pointer to raw memory for this sort of thing. -- James Kanze mailto:kanze@gabi-soft.de Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627