Re: bitwise comparators

[Ashley Deas Eachus <rieachus@earthlink.net>]

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.