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,bd45e29f9dafca87 X-Google-Attributes: gid103376,public From: Ashley Deas Eachus Subject: Re: bitwise comparators Date: 2000/02/05 Message-ID: <389C4F0D.E5541B98@earthlink.net>#1/1 X-Deja-AN: 581949741 Content-Transfer-Encoding: 7bit References: <3880D375.7E363123@hotmail.com> <38829638.0@news.pacifier.com> <3882FC1C.2BA8C959@hotmail.com> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-ELN-Date: Sat Feb 5 08:21:44 2000 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 949767704 63.24.57.12 (Sat, 05 Feb 2000 08:21:44 PST) Organization: EarthLink Network, Inc. MIME-Version: 1.0 NNTP-Posting-Date: Sat, 05 Feb 2000 08:21:44 PST Newsgroups: comp.lang.ada Date: 2000-02-05T00:00:00+00:00 List-Id: Brian Rogoff wrote: > C is also my primary language, and at the risk of annoying Robert Eachus :-), > let me add "nested subprograms" to your list. And the ability to have local > arrays whose dimension depends on a local or parameter. And ... No annoyance, or maybe a little in the terminology. ;-) I specifically distinguished between nested procedures and nested functions. But the fact that most nested procedures in Ada indicate design flaws does not mean that nested procedures are not a very powerful feature in Ada. Quite the opposite. My complaint, if you can call it that, it that nested procedures in Ada are a great design abstraction. However, when the design is realized, almost all such procedures should be transformed into more appropriate constructs. Don't use a sledgehammer to swat flies. Of course, many of the abstractons that the nested procedure can be specialized to are also powerful. In fact, nested generic procedures are more like an M1A1 tank. Unlike nested procedures however, they are not overused... > I agree with Alexander that Ada is a larger language and to learn all of > its features is much harder than to learn all of the features of C, but > I've found it a much more rewarding language as well. If you're > comfortable with C, just start with the C level subset of Ada and add > knowledge as you need it. With Ada 95, you really do have all of the > features of C worth having. Ada was designed to favor readers over writers, and a lot of the "duplicate" features are for just that purpose--to allow the author to better communicate his intent to the reader of the program. Part of the pressure on authors to favor the reader is that code that sends the wrong message looks ugly to good Ada programmers, so you will see lots of discussion here of the "best" way to implement some abstraction, even though all of the proposed language will probably generate identical machine code. So take discussions here about while loops vs. exit statements--and my comments about nested procedures--with a large grain of salt. Back to the original topic, I would probably use an array of Booleans as the best representation of the original problem: type Register is array(1..32) of Boolean; for Register'size use 32; Some_Register: Register; for Some_Register'Address use ...; pragma Volitile(Some_Register); constant Low_Order_Bit := ...; .... loop -- setup code exit when Some_Register(Low_Order_Bit); -- functional code end loop; or if you prefer: -- setup code while not Some_Register(Low_Order_Bit) loop -- functional code -- setup code end loop; As you can see, the exit when version is better when there is significant setup to be done for the test--the traditional loop and a half, and the while loop is cleaner if there is no setup required.