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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-15 18:58:57 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!212.74.64.35!colt.net!newspeer.clara.net!news.clara.net!news-hub.cableinet.net!blueyonder!internal-news-hub.cableinet.net!news1.cableinet.net.POSTED!not-for-mail From: Tony Gair Subject: Re: Ada and pointers Newsgroups: comp.lang.ada References: <9ldto7$9pg$1@nh.pace.co.uk> <9lei8f$gmu$1@houston.jhuapl.edu> User-Agent: KNode/0.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-ID: Date: Thu, 16 Aug 2001 01:46:11 GMT NNTP-Posting-Host: 62.31.154.215 X-Complaints-To: http://www.blueyonder.co.uk/abuse X-Trace: news1.cableinet.net 997926371 62.31.154.215 (Thu, 16 Aug 2001 02:46:11 BST) NNTP-Posting-Date: Thu, 16 Aug 2001 02:46:11 BST Organization: blueyonder (post doesn't reflect views of blueyonder) Xref: archiver1.google.com comp.lang.ada:11967 Date: 2001-08-16T01:46:11+00:00 List-Id: > >> Well, the statement is true enough because after all, dynamic allocation >> and the things done by pointers are really a kind of fiction. Memory is >> basically one big array that you index with integers, so obviously, a >> non-dynamic/non-pointer solution must exist. Anything you do with >> pointers could be implemented with a one dimensional array and integer >> indexes - because that's what the compiler translates it into. >> I find it difiicult to believe that this is obvious in any way. It also dismisses the point of programmer error, none of us are infallible and its when some of us assume we are infallible and source omnipotent that our greatest and most widely known screw ups strike >> However, that doesn't mean that one should avoid access types in all >> cases. Sometimes it is the most natural expression of the solution. Its >> just that you should generally use them sparingly and isolate them as >> best you can. Ada lets you do this rather well. (Some OOP-style >> programming relies heavily on access types so you've got to make design >> trade offs - use the OOP for its benefits at the risk of having lots more >> pointers flying around or avoid/isolate the pointers and implement a >> solution that may not be as extensible.) Access types aren't a "bad" >> thing - you just don't want to be forced into using them at every >> conceivable turn as you must in C/C++. >> >> MDC >> -- > > Also note that there are some circumstances in which an access type is > effectively required. Cohen's "Ada as a Second Language" lists several in > section 8.5 I believe. As an Ada newbie, I have already run across a few > of these situations, namely: recursive types and variable sized arrays (or > to paraphrase Cohen, "simulating variable sized arrays." I suppose I could > have framed the solution differently to avoid these cases, but frankly, > I'm not exactly sure how. > This could be to make converted c and c++ programmers happy. They get very unhappy when they have their pointers removed. > As an aside, I have had some limited experience with FORTRAN code which > uses a giant array with many integer index pointers into it. It even has > its own memory management of this array, of sorts. I must say that trying > to follow this code is no fun at all, even though it is heavily > documented. It seems to me, the original coders of many years ago could > really have used a language like Ada95. > > jtd > Thanks for all the answers.