bitwise comparators

bitwise comparators

[Alexander Van Hecke]

hello,

I want to do the following :
OK_to_proceed : BOOLEAN := FALSE;
data : Unsigned_8;

while (not OK_to_proceed) loop
    -- do stuff
    OK_to_proceed := (data BITWISE AND 2#1#);
end loop;

so I want to exit the loop if bit one of data is set, but I don't know
what the bitwise and is!

alex

Re: bitwise comparators

[David C. Hoos, Sr.]

Alexander Van Hecke <alexke@hotmail.com> wrote in message
news:3880D375.7E363123@hotmail.com...
> hello,
>
> I want to do the following :
> OK_to_proceed : BOOLEAN := FALSE;
> data : Unsigned_8;
>
> while (not OK_to_proceed) loop
>     -- do stuff
>     OK_to_proceed := (data BITWISE AND 2#1#);
> end loop;
>
> so I want to exit the loop if bit one of data is set, but I don't know
> what the bitwise and is!
Do you have a copy of the Ada Language Reference Manual?

If so, a search for bit-wise reveals that bit-wise logical operators
are defined for modular types.

If not, the Reference Manual is distributed in Windows Help file
format with GNAT for winnt, or is available at
ftp://ftp.cs.nyu.edu/pub/gnat/rm9x-v5.95/ in two formats,
and browsable HTML form at http://www.adapower.com/rm95/index.html

It's amazing how many questions can be answered by perusing the
readily-available resources.

Re: bitwise comparators

[Bryce Bardin]

Alexander Van Hecke wrote:
> 
> hello,
> 
> I want to do the following :
> OK_to_proceed : BOOLEAN := FALSE;
> data : Unsigned_8;
> 
> while (not OK_to_proceed) loop
>     -- do stuff
>     OK_to_proceed := (data BITWISE AND 2#1#);
> end loop;
> 
> so I want to exit the loop if bit one of data is set, but I don't know
> what the bitwise and is!
> 
> alex


Data : Interfaces.Unsigned_8;

Bit_0 : constant := 2**0; -- Clearer intent than 2#1# or 1 
-- This might be given an application-specific name and
-- (optionally) be given an explicit type, e.g.:
Command_Accepted : constant Interfaces.Unsigned_8
    := 2**0; -- Evaluated at compilation time.

loop
  -- Do something that changes the value of Data.
  exit when (Data and Command_Accepted) = Command_Accepted;
end loop;

Re: bitwise comparators

[Jeff Carter]

In article <3880D375.7E363123@hotmail.com>,
  Alexander Van Hecke <alexke@hotmail.com> wrote:
> hello,
>
> I want to do the following :
> OK_to_proceed : BOOLEAN := FALSE;
> data : Unsigned_8;
>
> while (not OK_to_proceed) loop
>     -- do stuff
>     OK_to_proceed := (data BITWISE AND 2#1#);
> end loop;
>
> so I want to exit the loop if bit one of data is set, but I don't know
> what the bitwise and is!

If Unsigned_8 is a modular type, such as Interfaces.Unsigned_8, then
the operator "and" performs a bitwise and between values of the type:

   Data and 1

The result of this is of type Unsigned_8. You have a number of options
to convert this to Boolean:

   OK_To_Proceed := Boolean'Val (Data and 1);

is probably the best. Others include comparing the result to 1 (OK) and
using an unchecked conversion (not recommended).

I think that

loop
   exit when OK_To_Proceed;

is easer to read and understand than the negative logic used with a
while loop.
--
Jeff Carter
"Now go away or I shall taunt you a second time."
-- Monty Python and the Holy Grail


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: bitwise comparators

[DuckE]

Alexander Van Hecke <alexke@hotmail.com> wrote in message
news:3880D375.7E363123@hotmail.com...
> hello,
>
> I want to do the following :
> OK_to_proceed : BOOLEAN := FALSE;
> data : Unsigned_8;
>
> while (not OK_to_proceed) loop
>     -- do stuff
>     OK_to_proceed := (data BITWISE AND 2#1#);
> end loop;
>
> so I want to exit the loop if bit one of data is set, but I don't know
> what the bitwise and is!

Caution: You've caught me in a "chatty" mood.

As others have responded, if Unsigned_8 is a modular type, you can use the
"AND" operator and just change your code to read:

while (not OK_to_proceed) loop
    -- do stuff
    OK_to_proceed := (data and 2#1#) /= 0;
end loop;

Note: in Ada booleans and integer or modular types are two different
critters so you cannot assign an integer to a boolean.

I'd also like to point out that the "while" construct you are using is
common for 'C' or Pascal, but in Ada you could use a "loop" construct with
"exit when"

loop
  -- do stuff
  exit when (data and 2#1#) /= 0;
end loop;

And eliminate the need for an OK_to_proceed variable.  Of course this is a
matter of style preference.

The other thing I'd like to point out is with Ada you can explicity map bits
within memory using representation clauses, for example:

  type status_register is
    record
       data_ready : boolean;
    end record;

  for status_register use
    record
       data_ready at 0 range 0..0;
    end record;

  for status_register'size use 8;

  register : status_register;
  for register'address use -- fill in the address of the register here

And then the loop becomes:

loop
  -- do stuff
  exit when register.data_ready
end loop;

Which eliminates explicit bit masking altogether.  Of course you may have to
use a volatile pragma to make sure the value gets loaded for each test.

SteveD

>
> alex
>

Re: bitwise comparators

[Alexander Van Hecke]

> I'd also like to point out that the "while" construct you are using is
> common for 'C' or Pascal, but in Ada you could use a "loop" construct with
> "exit when"
>

thank you all for your response!
As many of you have pointed out, I could have used exit when ...
But as you probably noticed, I have a C background and I'm not that familiar
with Ada.  I think it's a nice feature of Ada that you can write 'readable'
code, but IMHO Ada takes a lot longer to learn, there are more constructs,
keywords, etc...  In a word, the language is more complicated, yet not
necessarily more powerfull (hope I don't get flamed for this :-)).   In C you'd
have one while loop, and you'd put your condition in the while expression and
that's it.  Nothing more to learn about it!
What's your opinion on this?

alex

Re: bitwise comparators

[David C. Hoos, Sr.]

Alexander Van Hecke <alexke@hotmail.com> wrote in message
news:3882FC1C.2BA8C959@hotmail.com...
> > I'd also like to point out that the "while" construct you are using is
> > common for 'C' or Pascal, but in Ada you could use a "loop" construct
with
> > "exit when"
> >
>
> thank you all for your response!
> As many of you have pointed out, I could have used exit when ...
> But as you probably noticed, I have a C background and I'm not that
familiar
> with Ada.  I think it's a nice feature of Ada that you can write
'readable'
> code, but IMHO Ada takes a lot longer to learn, there are more constructs,
> keywords, etc...  In a word, the language is more complicated, yet not
> necessarily more powerfull (hope I don't get flamed for this :-)).   In C
you'd
> have one while loop, and you'd put your condition in the while expression
and
> that's it.  Nothing more to learn about it!
> What's your opinion on this?
>

Ada makes it cleaner to exit from the middle of a loop, IMO.

Try doing multi-tasking in Ada and in C if you want a real contrast where
the
Ada solution code is much simpler than the C.

Re: bitwise comparators

[tmoran]

>code, but IMHO Ada takes a lot longer to learn, there are more constructs,
>keywords, etc...  In a word, the language is more complicated,
  The "Pascal"ish subset is certainly pretty simple.  You only need
to learn the fancy stuff as you need it.  As for keywords, surely
the use of "{}" in
  if(x > 0)x=0;
  if(y > 0){x=0;y=0}:
requires more of the beginner than
  if x > 0 then x := 0;end if;
  if y > 0 then x := 0;y := 0;end if;

>In a word, the language is more complicated,
>yet not necessarily more powerfull...
  ID2 := ID1;
vs
  memcpy(&ID1, &ID2, sizeof ID1);
where a and b can, in Ada, be characters, floats, arrays, structures,
bit fields, or anything else.  In Ada you can change the type of ID's
from integer to string to structure to bit field without changing
all the assignment statements in your program.  You also only need
to remember ":=", not "=" and also "memcpy".  And, for those whose
brilliant programming is only constrained by their typing speed,
the former takes fewer, and more easily accessible, keystrokes.

>> I'd also like to point out that the "while" construct you are using is
>> common for 'C' or Pascal, but in Ada you could use a "loop" construct with
>> "exit when"
  Your original "while" was perfectly legal Ada.  Things like using
exit statements in loops are niceties.  It is true that Ada programmers
tend to worry more about questions like whether
  while (not OK_to_proceed) loop
vs
  loop
    exit when OK_to_proceed;
is more likely to result in mistakes by a later maintenance programmer.
That's just another aspect of "power", should you choose to use it.

Re: bitwise comparators

[Mike Silva]

Alexander Van Hecke wrote in message <3882FC1C.2BA8C959@hotmail.com>...
>...IMHO Ada takes a lot longer to learn, there are more constructs,
>keywords, etc...  In a word, the language is more complicated, yet not
>necessarily more powerfull (hope I don't get flamed for this :-)).   In C
you'd
>have one while loop, and you'd put your condition in the while expression
and
>that's it.  Nothing more to learn about it!
>What's your opinion on this?


Since by your tone I think this is a genuine question and not a stinkbomb,
here's an off-the-cuff list of Ada features I find "more powerful" than C
(my primary language):

Strong typing
Multitasking
Generics
Tagged Types
Packages
Exceptions
Discriminants
Arrays indexed over arbitrary ranges, including enumerations
Much greater control over variable range and representation
Runtime error checking

C may be one of the harder languages from which to learn Ada, since C is so
forgiving (encouraging?) of "write now, think later" coding.  With Ada if
you try this (and what C programmer hasn't, in the beginning?) you'll just
find yourself entangled in web of compiler errors.  It's frustrating, but it
soon becomes clear that those errors are really questions that the language
is asking you -- most of which you must answer anyway (whatever your
language) to solve your problem, while other Ada-specific questions (such as
typing issues) are there to help keep you from making the careless mistakes
that often makes programming in C an asymptotic exercise.  Ada, being a
language that likes to have all its ducks in a row, just asks you to answer
all these questions sooner.

HTH (from somebody who was where you are very recently)

Mike

Re: bitwise comparators

[Alexander Van Hecke]

Mike Silva wrote:

> Since by your tone I think this is a genuine question and not a stinkbomb,

it was a genuine question :-)

>
> here's an off-the-cuff list of Ada features I find "more powerful" than C
> (my primary language):
>
> Strong typing
> Multitasking
> Generics
> Tagged Types
> Packages
> Exceptions
> Discriminants
> Arrays indexed over arbitrary ranges, including enumerations
> Much greater control over variable range and representation
> Runtime error checking

I'm not sure why you think these features are more _powerful_ than in C.  I'd
label these features as more _advanced_.  C is an old language (allthough I'm
not sure at all about Ada), but nearly all those things you sum up are
_possible_ in C, maybe they're not as easy as in Ada and require the programmer
to explicitly program them (which may take a lot of code), but they're
possible.

Don't get me wrong, I'm not trying to make Ada look bad here, but I think my
previous statement stands : suppose you have no previous programming experience
whatsoever, I think that C is a lot easier to learn than Ada is.  I'd say that
Ada is a more advanced language (i.e. has more advanced features), as there are
many languages that are more advanced than C.

Again, I'm not trying to start a heavy discussion here about C versus Ada.  I
was just wondering what you all thought about it.  I want to emphasize here
that my experience with Ada is _very_ limited (and probably will stay that way,
I'm using it now for an exercise I have to make - I'm a final year student
computer science).  I must admit, I was curious about the possibilities of Ada
:-)

greetings,
alex

Re: bitwise comparators

[Gautier]

<<
1  Strong typing
2  Multitasking
3  Generics
4  Tagged Types
5  Packages
6  Exceptions
7  Discriminants
8  Arrays indexed over arbitrary ranges, including enumerations
9  Much greater control over variable range and representation
10 Runtime error checking
>>
Alexander Van Hecke:
> I'm not sure why you think these features are more _powerful_ than in C.

* Take the example of exceptions (but the tasking, that I don't practice, is a better one).
  With the years, compiler makers tend to implement them the most efficiently
  (zero-cost when no exception occurs, at least). If you want to program it in C,
  you have to invent them; for years your home-made exception model will be slow,
  will crash a lot etc. And it won't work on another machine, compiler or even
  memory model. Other C resources won't be able to use them; if they use them,
  exception codes will interfer.
* So you will avoid exceptions, but you'll have to carry error codes everywhere
  in the process -> slower. (I think to Unzip - see
  http://members.xoom.com/gdemont/unzipada.htm )
* This is an example where features are a the same time advanced _and_ powerful.
  Among the list, 1,2,6,9 (at least) are effectively used by optimizers
  in GNAT Ada 95 and DEC Ada (83) - the compilers I know. A real Ada bonus.
  1-9 save a huge portability effort, 10 (that uses 1-9) save incredible time
  of run-time debugging. I'll add that 1,8,9 catches most errors at compile-time:
  it means that the 1/100 sec of slower Ada compilation replace 1 hour of debugging
  in Fortran/C...

> I'd label these features as more _advanced_.  C is an old language (allthough I'm
> not sure at all about Ada),

Ada (83) is about 20 years younger... 

> but nearly all those things you sum up are
> _possible_ in C, maybe they're not as easy as in Ada and require the programmer
> to explicitly program them (which may take a lot of code), but they're
> possible.

Of course. You can even program it in assembler ;-). It depend ho many
lifes you have to do it!
Seriously: to implement basic features of Ada, say

  * packages (getting rid of makefiles with a working auto-make, check .h against .c)
  * exceptions (*working* exceptions - read c++ ngs to see that it is not trivial)
  * generics (same remark about c++ templates...)
  * strong type, with possibility of checking bounds

as your home-made C preprocessor and you'll be very old!

> Don't get me wrong, I'm not trying to make Ada look bad here, but I think my
> previous statement stands : suppose you have no previous programming experience
> whatsoever, I think that C is a lot easier to learn than Ada is.  I'd say that
> Ada is a more advanced language (i.e. has more advanced features), as there are
> many languages that are more advanced than C.

My idea about easy or not: all psychological, a question of image.
* C has a better image (the funny 1960 experimental macro-assembler, the hippie era)
* Ada has an horrific one (government, army, commitee, heavy, expensive). This image has
improved much over the past 4 years thanks to GNAT, the Ada95 norm and fast computers
that reach decent compilation times. More is to be done...
A problem with Ada (IMHO): some Ada advocates are a bit arrogant, prefer to boast
that one can do such and such thing in Ada instead of showing simple examples,
providing resources on the Internet. Many people just didn't see Ada sources!

> Again, I'm not trying to start a heavy discussion here about C versus Ada.

It seems well started I fear!
No problem if this is argumented and not (too) religious...

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: bitwise comparators

[David Starner]

On Mon, 17 Jan 2000 18:19:18 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote:
>Mike Silva wrote:
>> here's an off-the-cuff list of Ada features I find "more powerful" than C
>> (my primary language):
>>
>> Strong typing
>> Multitasking
>> Generics
>> Tagged Types
>> Packages
>> Exceptions
>> Discriminants
>> Arrays indexed over arbitrary ranges, including enumerations
>> Much greater control over variable range and representation
>> Runtime error checking
>
>I'm not sure why you think these features are more _powerful_ than in C.  I'd
>label these features as more _advanced_. 
Is this more than a difference in terminology?

>C is an old language (allthough I'm
>not sure at all about Ada), but nearly all those things you sum up are
>_possible_ in C, maybe they're not as easy as in Ada and require the programmer
>to explicitly program them (which may take a lot of code), but they're
>possible.

Anything possible in one language is possible in another language, from a 
theoritical perspective. Multitasking is impossible (from a practical 
perspective) in C without add on libraries. Setjmp/longjmp exceptions should 
be much more inefficent in C then in Ada. In pure C89, there is no way to 
gain control over variable range, short of using outside tools like Autoconf.

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: bitwise comparators

[Mike Silva]

Alexander Van Hecke wrote in message <38834F16.FE5DE77F@hotmail.com>...
>>
>> here's an off-the-cuff list of Ada features I find "more powerful" than C
>> (my primary language):
>>
>> Strong typing
>> Multitasking
>> Generics
>> Tagged Types
>> Packages
>> Exceptions
>> Discriminants
>> Arrays indexed over arbitrary ranges, including enumerations
>> Much greater control over variable range and representation
>> Runtime error checking
>
>I'm not sure why you think these features are more _powerful_ than in C.
I'd
>label these features as more _advanced_.  C is an old language (allthough
I'm
>not sure at all about Ada), but nearly all those things you sum up are
>_possible_ in C, maybe they're not as easy as in Ada and require the
programmer
>to explicitly program them (which may take a lot of code), but they're
>possible.

I interpreted "powerful" to mean faster and/or easier.  It's true that
anything you can do in Ada you can do in C, given enough manually-coded
conditional statements (each of which, of course, is capable of being
miscoded).  Much of Ada's "power" comes from the availability of constructs
that more closely or naturally map to the problem universe, while more of
Ada's power comes from all the extra grunt work the compiler (and runtime)
do to ensure the integrity of the problem universe; code which would have to
be written manually to do the same job (but not as well) in C, assuming it
got written at all.
>
>Don't get me wrong, I'm not trying to make Ada look bad here, but I think
my
>previous statement stands : suppose you have no previous programming
experience
>whatsoever, I think that C is a lot easier to learn than Ada is...

Sometimes I wonder what language I'll teach my kids when they get old
enough.  It may very well be Ada, but it won't be C -- too low-level and
unstructured.  It's quite feasible to learn and use subsets of Ada and add
on as desired.

If you want Ada to be C you'll always be fighting it -- you need to make a
concious decision to "write Ada" in Ada.

Mike

Re: bitwise comparators

[Charles Hixson]

I think that it was Douglas Hofstadter to invented FLOOP, the minimal language
in one can write a program to do anything that can be programmed in any other
computer language (of course Turing got there first, but FLOOP is more
accessible).  It's a really simple language.  And it takes a lot of work to do
anything.  But by some measures of power, one can't be any more powerful.
OTOH, subroutine libraries, structured programming, type checking, etc. make the
actual creation of the program much easier.  On this measure Ada95 does well,
though most versions lack such features as built-in garbage collection,
color-codeing IDE's that also help one with screen painting, and other advanced
features.  The core of Ada95 is designed to help one catch errors at compile
time, and this is a great good, and, in itself, a "powerful" feature.  It lacks
other powerful features that would make it a workable RAD environment.  Much of
this can be fixed by further development, but there may be some limitations to a
statically bound language.  However, just because a dynamically bound language
had different limitations doesn't mean that they are better limitations.  It
depends on what you need.

Re: bitwise comparators

[Brian Rogoff]

On Mon, 17 Jan 2000, Mike Silva wrote:
> Alexander Van Hecke wrote in message <3882FC1C.2BA8C959@hotmail.com>...
> >...IMHO Ada takes a lot longer to learn, there are more constructs,
> >keywords, etc...  In a word, the language is more complicated, yet not
> >necessarily more powerfull (hope I don't get flamed for this :-)).   In C
> you'd
> >have one while loop, and you'd put your condition in the while expression
> and
> >that's it.  Nothing more to learn about it!
> >What's your opinion on this?
> 
> 
> Since by your tone I think this is a genuine question and not a stinkbomb,
> here's an off-the-cuff list of Ada features I find "more powerful" than C
> (my primary language):
>
> Strong typing
> Multitasking
> Generics
> Tagged Types
> Packages
> Exceptions
> Discriminants
> Arrays indexed over arbitrary ranges, including enumerations
> Much greater control over variable range and representation
> Runtime error checking

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 ...

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.

The only downside is that Ada is so nice that its minor flaws look awful 
(e.g. lack of in/out function params) whereas in C and kin there are so 
many flaws that even the big ones don't bother me much ;-).

-- Brian

> C may be one of the harder languages from which to learn Ada, since C is so
> forgiving (encouraging?) of "write now, think later" coding.  With Ada if
> you try this (and what C programmer hasn't, in the beginning?) you'll just
> find yourself entangled in web of compiler errors.  It's frustrating, but it
> soon becomes clear that those errors are really questions that the language
> is asking you -- most of which you must answer anyway (whatever your
> language) to solve your problem, while other Ada-specific questions (such as
> typing issues) are there to help keep you from making the careless mistakes
> that often makes programming in C an asymptotic exercise.  Ada, being a
> language that likes to have all its ducks in a row, just asks you to answer
> all these questions sooner.
> 
> HTH (from somebody who was where you are very recently)
> 
> Mike
> 
> 
> 
> 

Re: bitwise comparators

[Ashley Deas Eachus]

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.

Re: bitwise comparators

[Jeff Carter]

Ashley Deas Eachus wrote:
>        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 := ...;

It's scary when Robert Eachus writes something like this. Can I assume
you meant

   Low_Order_Bit : constant Positive := ...;

?


Here we have my problem with using an array of Booleans: This code is
not portable. On some machines Some_Register (1) is the LSB, on others,
Some_Register (32). When you move it, you have to remember to make sure
that this index is correct; it's very easy to forget that check, and the
code will still compile and run. The resulting error may be
intermittent, and finding it may be difficult.

> ....
>         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.

The "exit when" version is cleaner in both cases, because it uses
positive logic, which has been demonstrated to be easier to understand
(at least by us mere mortals :).

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: bitwise comparators

[Andy]

Ashley Deas Eachus wrote:
> ....
>         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.

Of course, when the setup is significant, you could always use a local
procedure :-)
 
___________________________________________

   Andy Starritt
___________________________________________

Re: bitwise comparators

[Brian Rogoff]

On Sat, 5 Feb 2000, Ashley Deas Eachus wrote:
> 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.

Hmmm, I'll have to go back and look, or simply ask you to expand on this,
since from what follows I must have misunderstood your position. The time
I *really* rely on nested procedures is when I'm instantiating a nested
procedure as a parameter of some generic subprogram, and simulating
downward funargs. Its rare that I feel I need them, and probably worse for
me than for some others since it can be argued that I'm programming FP
style in Ada. 
 
>     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 think if Ada had a better way to do downward funargs (like Bob Duff's
limited access to subprogram) I would have much use for nested generic 
procedures any more.

> > 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.

OK, but I'm still interested in why people prefer one style to another, and 
even if I'll often disagree (suffixes on types, use clauses, etc.) I find
it important to understand the reasons for certain preferences.

-- Brian

Re: bitwise comparators

[Robert Iredell Eachus]

Brian Rogoff wrote:

> Hmmm, I'll have to go back and look, or simply ask you to expand on this,
> since from what follows I must have misunderstood your position. The time
> I *really* rely on nested procedures is when I'm instantiating a nested
> procedure as a parameter of some generic subprogram, and simulating
> downward funargs. Its rare that I feel I need them, and probably worse for
> me than for some others since it can be argued that I'm programming FP
> style in Ada.

      Exactly.  There is nothing "wrong" with ordinary nested procedures.  It is just
that
when you need context or locall declared types, the "right" abstraction is so often a
generic instantiation or task entry that a nested procedure has become a red flag to me.

Try this.  Take some random package body that contains nested procedures, and move all
the nested procedures out into the package body.  Does the package compile and run just
fine?

      Incidently, if you look through the gnat source,  I will probably appear to be the
most
egregious violators of this rule.   (My sins appear in the run-time packages for the IS
Annex,
in processing Picture strings.  However, recursive descent parsers are a very special
case...

Re: bitwise comparators

[Matthew Heaney]

In article <3882FC1C.2BA8C959@hotmail.com> , Alexander Van Hecke 
<alexke@hotmail.com>  wrote:

> But as you probably noticed, I have a C background and I'm not that familiar
> with Ada.  I think it's a nice feature of Ada that you can write 'readable'
> code, but IMHO Ada takes a lot longer to learn, there are more constructs,
> keywords, etc...  In a word, the language is more complicated, yet not
> necessarily more powerfull (hope I don't get flamed for this :-)).   In C
you'd
> have one while loop, and you'd put your condition in the while expression and
> that's it.  Nothing more to learn about it!
> What's your opinion on this?

But you could have written your loop without using while:

  for (;;) {
    -- do something
    if (data & 1) break;
  }

In Ada, instead of using a null for loop to do the job, we just use a
loop.

As far as keywords go, I consider that a specious comparison.  In C, you
have to know which operator symbol to use, and then try to remember the
difference between "&" and "&&".  Ouch!

In Ada, if you want to do a bitwise and expression, you just say "and",
which is more natural.  In this case, it is *easier* to learn Ada than
C.

--
If we let the Creationists have their way, we may as well go whole hog.
Let us reintroduce the flat-earth theory, the chemistry of the four
elements, and mediaeval astrology.  For these outworn doctrines have
just as much claim to rival current scientific views as Creationism does
to challenge evolutionary biology.

Abusing Science: The Case Against Creationism
Philip Kitcher

Re: bitwise comparators

[Gautier]

> In C you'd
> have one while loop, and you'd put your condition in the while expression and
> that's it.  Nothing more to learn about it!
> What's your opinion on this?

The situation seems the same to me: both have for and while loops. Ada has
a conditionless loop in addition. Isn't there an exit statement in C ?
(I'm in the reverse situation...)

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: bitwise comparators

[Keith Thompson]

Gautier <gautier.demontmollin@maths.unine.ch> writes:
> The situation seems the same to me: both have for and while loops. Ada has
> a conditionless loop in addition. Isn't there an exit statement in C ?

Yes, C's break statement is similar to Ada's exit statement.  A major
difference is that a C break statement terminates the innermost
enclosing loop or switch statement; it doesn't let you terminate an
outer loop.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: bitwise comparators

[Ole-Hjalmar Kristensen]

Keith Thompson <kst@cts.com> writes:

> Gautier <gautier.demontmollin@maths.unine.ch> writes:
> > The situation seems the same to me: both have for and while loops. Ada has
> > a conditionless loop in addition. Isn't there an exit statement in C ?
> 
> Yes, C's break statement is similar to Ada's exit statement.  A major
> difference is that a C break statement terminates the innermost
> enclosing loop or switch statement; it doesn't let you terminate an
> outer loop.
> 
> -- 
> Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
> Welcome to the last year of the 20th century.

C also has the continue statement. which is not so widely used, but
which is handy sometimes. Btw., I really like the Ada loop constructs,
especially the exit <named loop> construct which you mentioned.  The C
for statement is very general, but I have a nagging feeling that in
many instances a construct like Ada's 

loop 
...  
   exit when ...  
...
end loop; 

is a more maintainable alternative than trying to cram too much into
the for(...)  part of a C for loop.

-- 
E pluribus Unix

Re: bitwise comparators

[Jeff Carter]

In article <3882FC1C.2BA8C959@hotmail.com>,
  Alexander Van Hecke <alexke@hotmail.com> wrote:
> But as you probably noticed, I have a C background and I'm not that
familiar
> with Ada.  I think it's a nice feature of Ada that you can
write 'readable'
> code, but IMHO Ada takes a lot longer to learn, there are more
constructs,
> keywords, etc...  In a word, the language is more complicated, yet not
> necessarily more powerfull (hope I don't get flamed for this :-)).
In C you'd
> have one while loop, and you'd put your condition in the while
expression and
> that's it.  Nothing more to learn about it!
> What's your opinion on this?

Of course Ada takes longer to learn than C. Ada is a high-level
language (averaging 41 statements to implement a function point) and C
is a low-level language (128 statements/function point). Ada has
packages, private types, exceptions, generics, tasks, protected
objects, block statements, fixed-point types, user-defined numeric
types, true enumeration types, true arrays, and record types with
discriminants, none of which are found in C. C just has integers,
floating-point numbers, pointers, and functions, so of course Ada takes
longer to learn.

As for being "more powerfull", there are different forms of power. The
terseness of C that you refer to is one of its weaknesses, while Ada's
readability is one of the most powerful qualities a language can have.

Ada makes creating and using abstractions easier than C (packages for
encapsulation and information hiding; private types for information
hiding).

Ada makes code reuse easier than C (packages for namespace control;
generics for tailoring).

Ada makes handling exceptional situations easier and more readable
(exceptions and exception handlers; block statements for localizing
scope).

Ada makes concurrent code much easier and more readable (tasks,
protected objects, time types).
--
Jeff Carter
"Now go away or I shall taunt you a second time."
-- Monty Python and the Holy Grail


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: bitwise comparators

[Alexander Van Hecke]

This seems like an attack on C/C++!  I'm sorry, but I have to react on this

> Ada has
> packages,

C was ment to be used modular and for reuse : put your code in separate .c
and .h files.

> private types,

C has that!

> exceptions,

you can program exceptions in C.  I never said that C has all these things,
but you can program them, and there are masses of libraries available that
have just what you need.

> generics,

use structs and callback functions and you have perfect generic types!

> tasks,

threads


true enumeration types, true arrays,
enumeration types in Ada are no different than they are in C.  Just because
you have some fancy attributes (SUCC, PRED) doesn't mean that they are
different or more powerful!  You can write functions that do exactly the
same, even more, these functions have already been written numerous times
and are available.
With true arrays, do you mean out of bound checking, etc?  This can be done
with _proper_ programming in C!

none of which are found in C.
^^^^^^^^^^^^^^^^^^^^^^^
ahum.

> C just has integers, floating-point numbers, pointers, and functions, so
> of course Ada takes
> longer to learn.
>
> Ada makes creating and using abstractions easier than C (packages for
> encapsulation and information hiding; private types for information
> hiding).

Would you agree that C++ is just as good in that as Ada.  Don't forget that
ANY C++ code can be easily translated into C?
For that matter, everything else you mentioned (namespace control, (easy)
generics, exceptions and exception handlers, typing) is easily achieved in
C++ (and thus C).

As I have said already a few times, and as I said in my original post : I
THINK IT'S A NICE FEATURE OF ADA THAT YOU CAN WRITE READABLE CODE, BUT THAT
DOES NOT NECESSARILY MEAN THAT THE LANGUAGE IS MORE POWERFUL!  It might be
easier to use once you've mastered it, but it also is harder to learn.

excuse me for being so impolite, but I had to get this off my chest.

alex

Re: bitwise comparators

[Gautier]

Alexander Van Hecke wrote:

> This seems like an attack on C/C++!  I'm sorry, but I have to react on this

> > Ada has packages,

> C was ment to be used modular and for reuse : put your code in separate .c
> and .h files.

I feel you miss something. The .h files are just included texts; the
`defines' in one can influence another so the inclusion order is delicate;
there is no link (apart a moral one) between the .h and the .c and - correct me
if I'm wrong - a standard C compiler won't check the integrity between
.h and .c ... In addition, the most resources on the Net break your .h <-> .c rule...

> > exceptions,

> you can program exceptions in C.  I never said that C has all these things,
> but you can program them, and there are masses of libraries available that
> have just what you need.

Aaah but are they compatible between each other ? Maybe there are masses
of incompatible libraries ? And masses of software component that use
these incompatible libraries (I hope no)?
Your argument is valid if you're toying with _your_ exceptions, on _your_ PC...

So C hasn't this feature; it can be simulated, with some effort.
Ada has it. So, where is the problem ?

You could invent a language without subprograms and say: <<it's easy, I just
have to paste the code where it is needed>>... Without loops: <<just
if's and goto's>>. Without types at all - detected at run-time.
Such regressive trends exist, but (1) does it help the programmer and
(2) does it lead to efficient code (optimized subtypes, generics, exceptions,
inlining) ?

> > generics,

> use structs and callback functions and you have perfect generic types!

You imagine a rather inefficient way to implement generics. Try the _real_
genericity and see how an Ada compiler instanciates it at compile-time,
optimized... Wouldn't a C macro better fit (question) ?

Too much energy for holy war tonight - I prefer programming. My advice:
Take some time to learn the <<Pascal subset>>, take a week to toy with
Ada (the programming language, I mean), make _your_ idea if you can!

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: bitwise comparators

[Alexander Van Hecke]

>
>
> > use structs and callback functions and you have perfect generic types!
>
> You imagine a rather inefficient way to implement generics.

As a matter of fact, this way is more efficient than using templates!  Templates have to
be copied and filled in -> lots of overhead.  If you use callback functions in structs,
all you have to do is link the correct pointers to the adresses of the functions and
that's it.

greetings,
alex

Re: bitwise comparators

[David Starner]

On Mon, 17 Jan 2000 22:28:41 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote:
>> > use structs and callback functions and you have perfect generic types!
>>
>> You imagine a rather inefficient way to implement generics.
>
>As a matter of fact, this way is more efficient than using 
>templates!  Templates have to be copied and filled in -> 
>lots of overhead.  If you use callback functions in structs,
>all you have to do is link the correct pointers to the 
>adresses of the functions and that's it.

It sounds like you're complaining about compile time work,
which is irrelevant in most cases. Templates are not copied
and filled in at runtime. Templates are efficent at runtime,
unlike your method, especially for numeric work (you're 
substituting a call to a function for every addition in
the code. That kills performance.)

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: bitwise comparators

[Gautier]

Alexander Van Hecke wrote:

> > > use structs and callback functions and you have perfect generic types!

> > You imagine a rather inefficient way to implement generics.

> As a matter of fact, this way is more efficient than using templates!  Templates have to
> be copied and filled in -> lots of overhead.  If you use callback functions in structs,
> all you have to do is link the correct pointers to the adresses of the functions and
> that's it.

I see - indeed for some "percent bar" feedback purposes I do so if callback
doen't need to be inlined+optimized. It saves space.
But genericity embrace more than functions but all sorts of parameters.
One usage is to produce lots of overhead, but for each instance an optimized
code for it. A trivial example of it is the PKZip `explode' method that
appears in 2 versions, almost the same, apart of 2 parameters.
As variables they would slow down the code, so it is preferable to
instanciate twice the code with these numbers built-in and let the optimizer
squeeze the shifts etc. But, only one copy of source is needed 

generic
  needed: integer;
  mask:   unsigned_32;
procedure explode_lit ( tb, tl, td : p_Table_list; bb, bl, bd : integer );
(etc.)
Then, the instanciations:
-- **************** exploding, method: 8k slide, 3 trees *****************

procedure explode_lit8 is new explode_lit( 7, 16#7F# );

-- **************** exploding, method: 4k slide, 3 trees *****************

procedure explode_lit4 is new explode_lit( 6, 16#3F# );

See http://members.xoom.com/_XMCM/gdemont/uza_html/unz_expl__adb.htm#60_11

For that a C macro would fit a best, wouldn't it ?

But you can do more abstracted things like...
generic                              -- to provide:
          type ring_elt is private;                  -- ring element type 
          zero, one: ring_elt;                       -- 0 and 1 elements

          with function "-" (a:ring_elt) return ring_elt;    -- unary oper.
          with function "+" (a,b:ring_elt) return ring_elt;  -- binary oper.
          with function "*" (a,b:ring_elt) return ring_elt;

package Frac is
  type frac_elt is record a,b:ring_elt; end record;        -- define fraction

  frac_0: constant frac_elt:= (zero,one); 
  frac_1: constant frac_elt:= (one,one); 
(...)
and use it for creating rational numbers:
  package Rationals is new Frac_Euclid(Integer, 0,1, "-","+","-","*","/");
then rational polynomials:
  package Rationals.Polynomials is new
             Polynomials( frac_elt, frac_0, frac_1, "-","+","-","*","/","=" ); 
then using Frac again to create rational functions!

(end of generic trip - the subject is so wide... )

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: bitwise comparators

[Ted Dennison]

In article <388394E0.55D1E913@maths.unine.ch>,
  Gautier <gautier.demontmollin@maths.unine.ch> wrote:
> Alexander Van Hecke wrote:
>
> > C was ment to be used modular and for reuse : put your code in
> > separate .c and .h files.
>
> I feel you miss something. The .h files are just included texts; the
> `defines' in one can influence another so the inclusion order is
> delicate; there is no link (apart a moral one) between the .h and the
> .c and - correct me if I'm wrong - a standard C compiler won't check
> the integrity between .h and .c ... In addition, the most resources on
> the Net break your .h  <-> .c rule...

That's just about the biggest problem in my book. Using ".h" files that
way is just a convention that many C developers follow. There's no teeth
to it, and there are many other ways the include feature can be
(ab)used. For instance, I've seen several C systems where included
files have no extention (".h") on them. There are even several places in
the vxWorks kernel source code where ".c" files are #include'd. I can be
indignant that the developers would do such a thing to poor unsuspecting
readers like myself, but its perfectly legal (and running) C.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: bitwise comparators

[David Starner]

On Mon, 17 Jan 2000 20:26:42 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote:
>This seems like an attack on C/C++!  I'm sorry, but I have to react on this
>
>> Ada has
>> packages,
>
>C was ment to be used modular and for reuse : put your code in separate .c
>and .h files.

int mktemp() can conflict with something in another file. No use of header
files can fix that.
David.library.mktemp never will. 

>
>> private types,
>
>C has that!
C has access control? Where?

>> exceptions,
>
>you can program exceptions in C.  
But it doesn't have them, and good exception handling needs to
be handled by the compiler. 

>> generics,
>
>use structs and callback functions and you have perfect generic types!
No type safety, large runtime overhead, and poor readibility is perfect?

>> tasks,
>
>threads
Which aren't a part of C, and most thread libraries aren't portable among
systems (Unix -> Windows -> Mac -> bare hardware).

>With true arrays, do you mean out of bound checking, etc?  This can be done
>with _proper_ programming in C!
So in other words, with enough work, you can add real arrays to C? The point
is you have to add them, they don't come with the language.

>none of which are found in C.
>^^^^^^^^^^^^^^^^^^^^^^^
>ahum.
It's correct. Because you can add them, doesn't mean they're found in the
language.

>> C just has integers, floating-point numbers, pointers, and functions, so
>> of course Ada takes
>> longer to learn.
>>
>> Ada makes creating and using abstractions easier than C (packages for
>> encapsulation and information hiding; private types for information
>> hiding).
>
>Would you agree that C++ is just as good in that as Ada. 
No.

>Don't forget that
>ANY C++ code can be easily translated into C?
No. With sufficent work, C++ code can be translated into C, but you're
going to rewrite several core systems in process. You're going to have
to munge names, write vtables and all sorts of grungy stuff.

>For that matter, everything else you mentioned (namespace control, (easy)
>generics, exceptions and exception handlers, typing) is easily achieved in
>C++ (and thus C).
Not and thus C. It's not that simple. And frequently, your implementations
are going to be low quality without some very low level and implemenation
specific work.

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: bitwise comparators

[Alexander Van Hecke]

>
> C has access control? Where?

the items you put in a struct are default public.  private is a C keyword though.  It
is perfectly possible to hide some data items.

>
>
> >> exceptions,
> >
> >you can program exceptions in C.
> But it doesn't have them, and good exception handling needs to
> be handled by the compiler.
>
> >> generics,
> >
> >use structs and callback functions and you have perfect generic types!
> No type safety, large runtime overhead, and poor readibility is perfect?
>
> >> tasks,
> >
> >threads
> Which aren't a part of C, and most thread libraries aren't portable among
> systems (Unix -> Windows -> Mac -> bare hardware).
>

I understand what you're saying, and you're right too!  As I already said, Ada is a
programming language of a later generation, and thus has more features ( = things you
could do with previous generation languages, but were perhaps difficult / erroneous to
program) that the compiler does for you.  Never forget that this almost always has a
direct impact on the speed of your programs (cfr. Java which resembles C++ (not in
every point of course) but is WAY slower because of all kinds of automatic checking /
copying / testing ...)!  However, this does not mean that you can do 'more' with this
language.  I think I should have explained more carefully what I mean by 'powerful' :
it has nothing to do with how complicated your compiler is (and I will be fair, it's
very good if your compiler checks for errors (like typing errors) that are otherwise
hard to find), but I'd say it's the ability of a language to be _able_ to program
everything you want to, _even if the language was not designed to solve the problem
you're trying to solve_!  In this way Prolog is a very powerful language for AI
programs, but it's really poor when it comes to, let's say, string manipulation.

I think that is a good point for C : easy to learn, possibilities are enormous, used
everywhere (OSses, programs, ...), and very extendible.  I can't think of anything
that can not be written in C.  I must say, I had never heard of Ada except for the
context of embedded systems.

>
> >With true arrays, do you mean out of bound checking, etc?  This can be done
> >with _proper_ programming in C!
> So in other words, with enough work, you can add real arrays to C? The point
> is you have to add them, they don't come with the language.

Indeed you're right.

> >Don't forget that
> >ANY C++ code can be easily translated into C?
> No. With sufficent work, C++ code can be translated into C, but you're
> going to rewrite several core systems in process. You're going to have
> to munge names, write vtables and all sorts of grungy stuff.

I know with certainty that the first couple of versions of the GNU C++ compiler, which
is by the way a very respected and widespread compiler, did just that : converting C++
to C and then compiling this code with the usual gcc compiler.   I rephrase : 'any C++
code can be translated to C code'.

I do not want to start a war here between C/C++ and Ada!  Both of the languages have
their pro and cons.

greetings,
alex

Re: bitwise comparators

[David Starner]

[It would be easier if you kept lines below 75-80 characters.
Thanks.]
On Mon, 17 Jan 2000 22:23:18 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote:
>>
>> C has access control? Where?
>
>the items you put in a struct are default public. 
>private is a C keyword though.  It
>is perfectly possible to hide some data items.

No, private is not a ISO C89 keyword. My books don't
mention it, and gcc (an ISO C compiler) gives a parse
error for struct bob {private: int a;}; it gives no
error for struct bob {int private;};, which it should
if private is a reserved word. I think you've been
confused by a bad C/C++ compiler.

>but I'd say it's the ability of a language to be _able_ to program
>everything you want to, _even if the language was not designed to solve 
>the problem you're trying to solve_!  In this way Prolog is a very 
>powerful language for AI programs, but it's really poor when it comes to,
>let's say, string manipulation.

That's a bad definition. Computing theory says the problems you can solve
with Bourne shell scripts is exactly equal to the problems you can solve
in C or Prolog or Intercal or an assembly language with one instruction
(decrement and jump if zero.)

>I know with certainty that the first couple of versions of the GNU C++ 
>compiler, which is by the way a very respected and widespread compiler, 
>did just that : converting C++ to C and then compiling this code with 
>the usual gcc compiler. 

No. cfront (an early C++ compiler by Stroustroup) did that, but the GNU
C++ compiler has always been a native compiler.

>I rephrase : 'any C++ code can be translated 
>to C code'.
Any C++ code can be translated to Lisp or Ada, too. But you said it could
be done easily, which is the contestable point.

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: bitwise comparators

[Preben Randhol]

Alexander Van Hecke <alexke@hotmail.com> writes:

| >
| > C has access control? Where?
| 
| the items you put in a struct are default public.  private is a C keyword though.  It
| is perfectly possible to hide some data items.

No it isn't. I think you are talking of C++ here not C.

-- 
Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/]     
         "Det eneste trygge stedet i verden er inne i en fortelling." 
                                                      -- Athol Fugard

Re: bitwise comparators

[Fraser]

paene lacrimavi postquam Alexander Van Hecke <alexke@hotmail.com> scripsit:

> I understand what you're saying, and you're right too!
> As I already said, Ada is a programming language of a
> later generation, and thus has more features ( = things
> you could do with previous generation languages, but
> were perhaps difficult / erroneous to >program) that
> the compiler does for you.  Never forget that this almost
> always has a direct impact on the speed of your programs
> (cfr. Java which resembles C++ (not in every point of
> course) but is WAY slower because of all kinds of automatic
> checking / copying / testing ...)!

Java is slower because of the VM, which most compilers target.  This
has little to do with the checking that Java has to do, which is
not much.  

The performance impact of run time checks is not as heavy as you
might think, because the Ada compiler has access to an awful lot
of type information that can be used to remove a bunch of them.

Sure, you can use a class to implement a checked array type in
C++, but how on earth do you safely optimise these checks away?
Safe Ada can be much faster than safe C++.  I say "can be" rather
than "is" because I'm too scared issue general pronouncements
like that, but in my experience the word "is" is appropriate.

> However, this does not mean that you can do 'more' with this
> language.

In principle, no, but in practice a language that allows you to
get where you need to be faster and with less errors is a language
that allows you to do more.  Instead of tracking down array bounds
violations, and fiddly pointer references, I can write more code.

> I think I should have explained more carefully what I mean by 'powerful' :
[ ... ]
> I'd say it's the ability of a language to be _able_ to program
> everything you want to, _even if the language was not designed
> to solve the problem you're trying to solve_!

This is not a useful definition, because it includes just about
everything!  I am "able" to program any particular task with a
large number of languages.  Where's the distinction?

> In this way Prolog is a very powerful language for AI
> programs, but it's really poor when it comes to, let's
> say, string manipulation.

Prolog has great string manipulation.  A string is just a list
of characters, and handling lists is something Prolog is very
good at.

> I think that is a good point for C : easy to learn, possibilities
> are enormous, used everywhere (OSses, programs, ...), and very extendible.

C is not easy to learn.  Students have to deal with pointers at a
very early stage, and this is unfortunate.  IMHO.

What do you mean by extensible?

> I can't think of anything that can not be written in C.

Write me a C program that determines whether another program terminates :)

> I must say, I had never heard of Ada except for the context of
> embedded systems.

Personally, I've used Ada for compilers, natural language understanding,
an interactive fiction engine, a medieval computer war game, an editor,
an editor extension language, a parser generator, a database system, a
large multiplayer game, a chip emulator, and a bunch of other stuff which
I can't remember just now.  The closest I've come to embedded systems is
targeting an Ada compiler to the Commodore 64.

cheers,
Fraser.

Re: bitwise comparators

[Bertrand Augereau]

By the way, does somebody know any commercial game that was (even partly)
written using Ada?

Re: bitwise comparators

[Ted Dennison]

In article <862pgc$ae6$1@netserv.univ-lille1.fr>,
  "Bertrand Augereau" <Augereau.Bertrand@ec-lille.fr> wrote:
> By the way, does somebody know any commercial game that was (even
> partly) written using Ada?

I know of quite a few flight simulators that were written in Ada. They'd
all cost more that the average Joe is willing to shell out. (Motion
bases and domed projection systems aren't cheap.) But some of them
are sold commercially. If you've got the dough, the appropriate
companies would be more than happy to sell you one.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: bitwise comparators

[Marin D. Condic]

Ted Dennison wrote:
> 
> In article <862pgc$ae6$1@netserv.univ-lille1.fr>,
>   "Bertrand Augereau" <Augereau.Bertrand@ec-lille.fr> wrote:
> > By the way, does somebody know any commercial game that was (even
> > partly) written using Ada?
> 
> I know of quite a few flight simulators that were written in Ada. They'd
> all cost more that the average Joe is willing to shell out. (Motion
> bases and domed projection systems aren't cheap.) But some of them
> are sold commercially. If you've got the dough, the appropriate
> companies would be more than happy to sell you one.
> 
Isn't that the wonderful part of our industry? They let us play with the
world's most expensive and sophisticated video games all day long and
then, once a week, whether we need it or not, they give us a paycheck!
:-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: bitwise comparators

[Ted Dennison]

In article <3885F3D8.CB073BFF@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> Isn't that the wonderful part of our industry? They let us play with
> the world's most expensive and sophisticated video games all day long
> and then, once a week, whether we need it or not, they give us a
> paycheck! :-)

I might have some empathy with that viewpoint. But as its remotely
possible that my boss might one day see this message, I'd rather take
this oppertunity to express how incredibly hard the work is, and the
best college we'll be able to afford for our kids may be Burger U. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: bitwise comparators

[Ted Dennison]

In article <85vr1s$9qe1@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
> On Mon, 17 Jan 2000 20:26:42 +0100, Alexander Van Hecke
<alexke@hotmail.com> wrote:
> >This seems like an attack on C/C++!  I'm sorry, but I have to react
on this
> >
> >> Ada has
> >> packages,
> >
> >C was ment to be used modular and for reuse : put your code in
> >separate .c and .h files.
>

Its tough to keep a straight face while reading this. You must not have
used the packging features of languages like Ada and Modula much to make
this statement. There simply is no comparison in the amount of
modularity and reusability between them.


> int mktemp() can conflict with something in another file. No use of
> header files can fix that.

A real-world example: We are using vxWorks here at work. xvWorks has no
processes, every task in the system is effectively a lightweight thread.
You can kind of think of the entire system, kernel and all, as one big
program.

We had some C code to handle reading of radio database files developed
for previous projects that we decided to reuse in our system, rather
than rewrite it in Ada (a quite sensible decision). When we took this
system out to the hardware, we had a devil of a time getting networking
to do anything. We eventually discovered that we couldn't even ping the
loopback address succesfully. That made no sense whatsoever.

After a couple of days, one of the engineers found the problem. This
completely unrelated reused C code of ours had a routine named
"checksum". Apparently, the TCP/IP stack *also* has a checksum routine,
and they are not the same.

Now a longtime C programmer would probably be indignant that neither
author used the standard idiom (aka: hack) of tacking on some kind of
namespace designator to the front of the routine's name to prevent this
kind of disasterous clash. But the engineer in you should realize that
it is silly to yell at someone for screwing up when they have been
presented with an error-prone system in the first place. Someone was
*bound* to screw up eventually.

In Ada this won't happen, because in Ada everything automaticly has its
package's namespace, and the default is *not* to export the symbol to
the system. If there is a namespace clash, the code won't compile in the
first place. So we *never* have any such trouble with our Ada routines.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: bitwise comparators

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]


Alexander Van Hecke <alexke@hotmail.com> a �crit dans le message :
38836CF2.AB738B8B@hotmail.com...
>
> Would you agree that C++ is just as good in that as Ada.

No.

> Don't forget that
> ANY C++ code can be easily translated into C?

Please, do not forget that every programming language can be easily
translated
into machine code ! That is what is done by a compiler :)

Ok, and what can we conclude from there ?

Pascal.

--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: pascal.obry@edf.fr        |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|   http://ourworld.compuserve.com/homepages/pascal_obry
--|
--|   "The best way to travel is by means of imagination"

Re: bitwise comparators

[Jeff Carter]

Alexander Van Hecke wrote:
> 
> This seems like an attack on C/C++!  I'm sorry, but I have to react on this

It wasn't meant as an attack, merely an enumeration of why Ada takes
longer to learn than C.

> 
> > Ada has
> > packages,
> 
> C was ment to be used modular and for reuse : put your code in separate .c
> and .h files.

These do not provide the many benefits of packages.

> 
> > private types,
> 
> C has that!

I've never seen them.

> 
> > exceptions,
> 
> you can program exceptions in C.  I never said that C has all these things,
> but you can program them, and there are masses of libraries available that
> have just what you need.

This is an unhelpful definition of "powerful". Since all C is translated
into machine code, and there are frequently things you can do in machine
code that you can't do in C, machine code is more powerful than C by
this definition. Is this an argument for using machine code rather than
C?

The power of a language comes from its readability, expressiveness, and
the amount of work it takes off your hands.

> 
> > generics,
> 
> use structs and callback functions and you have perfect generic types!

In my experience, you have perfectly unreadable code.

> 
> > tasks,
> 
> threads

Not part of C.

> 
> true enumeration types, true arrays,
> enumeration types in Ada are no different than they are in C.  Just because
> you have some fancy attributes (SUCC, PRED) doesn't mean that they are
> different or more powerful!  You can write functions that do exactly the
> same, even more, these functions have already been written numerous times
> and are available.

A C enumeration merely defines some named integers. An Ada enumeration
is a different animal altogether.

> With true arrays, do you mean out of bound checking, etc?  This can be done
> with _proper_ programming in C!

C does not have arrays; it only has different notations for address
arithmetic.

> 
> none of which are found in C.
> ^^^^^^^^^^^^^^^^^^^^^^^
> ahum.
> 
> > C just has integers, floating-point numbers, pointers, and functions, so
> > of course Ada takes
> > longer to learn.
> >
> > Ada makes creating and using abstractions easier than C (packages for
> > encapsulation and information hiding; private types for information
> > hiding).
> 
> Would you agree that C++ is just as good in that as Ada.  Don't forget that
> ANY C++ code can be easily translated into C?

So can any Ada code; Averstar sells an Ada compiler that generates C.
This has nothing to do with features of Ada that C lacks. This is not an
indictment of C; C and Ada have a different philosophies. It does
explain why Ada takes longer to learn than C.

> For that matter, everything else you mentioned (namespace control, (easy)
> generics, exceptions and exception handlers, typing) is easily achieved in
> C++ (and thus C).
> 
> As I have said already a few times, and as I said in my original post : I
> THINK IT'S A NICE FEATURE OF ADA THAT YOU CAN WRITE READABLE CODE, BUT THAT
> DOES NOT NECESSARILY MEAN THAT THE LANGUAGE IS MORE POWERFUL!  It might be
> easier to use once you've mastered it, but it also is harder to learn.
> 
> excuse me for being so impolite, but I had to get this off my chest.
> 
> alex

If the only definition of "powerful" is "able to implement anything"
than all languages are equally powerful, and there is no basis for
choosing one over the other. I think we all agree that there are
important differences between languages that lead people to choose one
over another; in many cases the most important difference is "I learned
X first" :) This seems like a useless definition of the power of a
language to me.
-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: bitwise comparators

[Keith Thompson]

Jeff Carter <jrcarter010@earthlink.net> writes:
[...]
> > With true arrays, do you mean out of bound checking, etc?  This can be done
> > with _proper_ programming in C!
> 
> C does not have arrays; it only has different notations for address
> arithmetic.

That's a slight exaggeration.  C does have array types and array
objects.  For example this:
    int a[10];
declares a as an array of 10 ints, very much like Ada's
    A: array(0 .. 9) of Integer;
It does not, contrary to popular misconception, declare a as a
pointer.

What often causes confusion is that, in most expression contexts, a
reference to the name of an array object "decays" to a pointer to the
array's first element.

C arrays are not first-class types, but they do exist.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: bitwise comparators

[Ole-Hjalmar Kristensen]

Keith Thompson <kst@cts.com> writes:

> Jeff Carter <jrcarter010@earthlink.net> writes:
> [...]
> > > With true arrays, do you mean out of bound checking, etc?  This can be done
> > > with _proper_ programming in C!
> > 
> > C does not have arrays; it only has different notations for address
> > arithmetic.
> 
> That's a slight exaggeration.  C does have array types and array
> objects.  For example this:
>     int a[10];
> declares a as an array of 10 ints, very much like Ada's
>     A: array(0 .. 9) of Integer;
> It does not, contrary to popular misconception, declare a as a
> pointer.
> 
> What often causes confusion is that, in most expression contexts, a
> reference to the name of an array object "decays" to a pointer to the
> array's first element.
> 
> C arrays are not first-class types, but they do exist.
> 
> -- 
> Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
> Welcome to the last year of the 20th century.

I would say you are both right. C guarantees that in your example, a
is a constant pointer. I also guarantees that a[i] == *(a+i).
A somewhat curious fact is that i[a] == *(i+a) == *(a+i), so it is
completely legal C to write for instance : 9[a] = 13;
The only use of this is probably if you're competing in the obfuscated
C code contest :-)


Ole-Hj. Kristensen

-- 
E pluribus Unix

Re: bitwise comparators

[Jeff Carter]

Keith Thompson wrote:
> 
> Jeff Carter <jrcarter010@earthlink.net> writes:
> [...]
> > C does not have arrays; it only has different notations for address
> > arithmetic.
> 
> That's a slight exaggeration.  C does have array types and array
> objects.  For example this:
>     int a[10];
> declares a as an array of 10 ints, very much like Ada's
>     A: array(0 .. 9) of Integer;
> It does not, contrary to popular misconception, declare a as a
> pointer.

That would explain why a[0] and *a are different notations for the same
thing, and a[2], *(a+2), and 2[a] are also different notations for the
same thing. a[2] is defined as a shortcut for *(a+2), which is why 2[a]
works. The "array" notation in C is a different notation for address
arithmetic. I stand by my statement.

Meanwhile, in Ada, A (0) and A (2) are legal, but A.all, 2 (A), and (A +
2).all give compiler errors.

> Welcome to the last year of the 20th century.

You've got that right.

-- 
Jeff Carter
"I fart in your general direction."
Monty Python & the Holy Grail

Re: bitwise comparators

[Keith Thompson]

Jeff Carter <jrcarter010@earthlink.net> writes:
> Keith Thompson wrote:
> > Jeff Carter <jrcarter010@earthlink.net> writes:
> > [...]
> > > C does not have arrays; it only has different notations for address
> > > arithmetic.
> > 
> > That's a slight exaggeration.  C does have array types and array
> > objects.  For example this:
> >     int a[10];
> > declares a as an array of 10 ints, very much like Ada's
> >     A: array(0 .. 9) of Integer;
> > It does not, contrary to popular misconception, declare a as a
> > pointer.
> 
> That would explain why a[0] and *a are different notations for the same
> thing, and a[2], *(a+2), and 2[a] are also different notations for the
> same thing. a[2] is defined as a shortcut for *(a+2), which is why 2[a]
> works. The "array" notation in C is a different notation for address
> arithmetic. I stand by my statement.

C does have arrays; it just defines some of the operations on arrays
in terms of lower-level operations, exposing some of the nuts and
bolts that Ada (wisely, IMHO) hides.

For example, "&a" yields the address of a, and is of type "pointer of
array of 10 ints", not "pointer to int".  Similarly, "sizeof a" yields
the size of the array, not the size of a pointer.  If a structure
member is an array, the full space for the array is allocated in each
object of the structure type, and the structure can be assigned and
passed by copy.

C arrays are *partly* built on the lower-level concept of pointers,
but not entirely.

Section 6 of the C FAQ, at <http://www.eskimo.com/~scs/C-faq/top.html>,
explains this better than I can.

> Meanwhile, in Ada, A (0) and A (2) are legal, but A.all, 2 (A), and (A +
> 2).all give compiler errors.

Which means that Ada arrays are closer to being first-class types than
C arrays are.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: bitwise comparators

[David Starner]

On Wed, 19 Jan 2000 18:48:11 GMT, Jeff Carter <jrcarter010@earthlink.net> wrote:
>Keith Thompson wrote:
>> That's a slight exaggeration.  C does have array types and array
>> objects.  For example this:
>>     int a[10];
>> declares a as an array of 10 ints, very much like Ada's
>>     A: array(0 .. 9) of Integer;
>> It does not, contrary to popular misconception, declare a as a
>> pointer.
>
>That would explain why a[0] and *a are different notations for the same
>thing, and a[2], *(a+2), and 2[a] are also different notations for the
>same thing. 

"int a[2];" is not the same as "int *(a+2);" which is not a legal 
declaration.
"extern int *a;" does not work if a is defined as "int a[2];". Just
because the same notation can be used in some circumstaces, and implicit
conversion happens, doesn't mean they are the same thing.

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: bitwise comparators

[Gisle S�lensminde]

In article <yecya9mpsv8.fsf@king.cts.com>, Keith Thompson wrote:
>Jeff Carter <jrcarter010@earthlink.net> writes:
>[...]
>> > With true arrays, do you mean out of bound checking, etc?  This can be done
>> > with _proper_ programming in C!
>> 
>> C does not have arrays; it only has different notations for address
>> arithmetic.
>
>That's a slight exaggeration.  C does have array types and array
>objects.  For example this:
>    int a[10];
>declares a as an array of 10 ints, very much like Ada's
>    A: array(0 .. 9) of Integer;
>It does not, contrary to popular misconception, declare a as a
>pointer.
>
>What often causes confusion is that, in most expression contexts, a
>reference to the name of an array object "decays" to a pointer to the
>array's first element.
>
>C arrays are not first-class types, but they do exist.


The semantics of C array is confusing for a lot of people, and 
they are frequently incorrectly used. C arrays are passed by 
reference to functions, but not if they are placed inside a struct.
I have frequently seen code like this one:

(Which not even gives warning on several compilers, like sunpro CC)

char* dig2hex(char digest[20]){
  int i;
  char hexstr[40];
  /* insert calculation here */

  return hexstr; /* returns a pointer to a local 
		    - may corrupt data later*/
}


This code returns a pointer to a local variable, and since these
data is placed on the stack, they will typically be overwritten
later. Instead you can place the array inside a struct, like this:


typedef struct hexstruct {
  char hexstr[40];
} hex;

hex dig2hex(char digest[20]){
  int i;
  hex tmphex;
  /* insert calculation here */

  return tmphex; /* return the struct including array by copy - ok*/
}

As long as the array is placed inside a struct you get by copy 
semantics, while an array on it's own behaves like a different
notation for a pointer.

A strange behavior here, is that the struct must be typedefed.
Otherwise it won't compile.


--
Gisle S�lensminde ( gisle@ii.uib.no )   

ln -s /dev/null ~/.netscape/cookies

Ada vs. C/C++ (was re: bitwise something-or-other)

[Mark Lundquist]

Alexander Van Hecke wrote:

>> Ada makes creating and using abstractions easier than C (packages for
>> encapsulation and information hiding; private types for information
>> hiding).
>
> Would you agree that C++ is just as good in that as Ada.

Well, I wouldn't agree!

I find C++ a lot more awkward and primitive.

> Don't forget that
> ANY C++ code can be easily translated into C?

I'm not sure what you mean.  If you mean that a translation program can do it,
so "it's as easy as invoking the translator", then your observation is true,
but irrelevant.  Right?  (Just think -- a compiler transforms an HLL into
machine code, just as cfront transforms C++ into C.  What would you think if
someone claimed this fact in support of an argument that coding an equivalent
program in machine code is no harder than writing the high-level language
program?)

If, on the other hand, you mean that given any C++ construct (e.g. a class),
it's just as easy to program the C equivalent, then I doubt you can really be
serious!  Have you ever actually looked at the C text produced by cfront?  Can
you really say you'd just as soon write that yourself?   For instance, C++ has
its VPTR/VTABLE crap, which hides your C callback stuff.  Don't you think
there's some benefit in not having to code that yourself?  The point isn't
that you *can't* do that in principle... no one is claiming that!  The point
is, who'd want to?  C++, despite its flaws, was invented for a reason.  And as
much as I'd rather use Ada than C++, I'd still rather use C++ than C.  This is
the whole purpose of higher-level languages, to take programs that are in
principle writable by someone with unlimited patience, unlimited time, and
perfect memory and record-keeping, and make them actually writeable by real
people!  The C level of abstraction is OK for little things, but it doesn't
scale up.  You can write big things in C -- with a lot of effort and pain.
C++ actually does give the programmer a higher view of programming than C, in
certain areas.

It's all about the level of abstraction you get to work in.

> For that matter, everything else you mentioned (namespace control, (easy)
> generics, exceptions and exception handlers, typing) is easily achieved in
> C++ (and thus C).

Your line of reasoning seems to be:

1) Ada and C++ are equivalent
2) C++ and C are equivalent, because you can translate C++ to C
3) Therefore, Ada and C are equivalent!  ("Ada feature X is 'easily achieved'
in C")

You seemed to take it for granted that anyone should concede (1), but those
who really know both Ada and C++ will be able to tell you all the ways in
which that is so wrong!  Ada is not C++ with better syntax.

As for (2), as I discussed above, the argument from translatability is
specious.  The translation in question is not transliteration, it's expressing
higher-level abstractions in terms of lower-level ones.  When you move up and
down the "abstraction level continuum", you don't get to use the
"translatability" argument, because you're trying to apply it with regard to
expressive power when it's only relevant to operational equivalence, which is
already assumed...  Am I makin' sense here?

> As I have said already a few times, and as I said in my original post : I
> THINK IT'S A NICE FEATURE OF ADA THAT YOU CAN WRITE READABLE CODE, BUT
> THAT
> DOES NOT NECESSARILY MEAN THAT THE LANGUAGE IS MORE POWERFUL!

Once again, nobody is saying that there are programs that you can write in Ada
that you can't write in some other language.  If this is what you're arguing
against, it's a straw-man argument.  The whole Turing-equivalence thing is
kind of something that Everybody Knows --  I think you can safely assume that
when someone claims that Ada is "more powerful" in some way, this is not what
they mean!  Yet that appears to be, from your "translation" argument, just
what you are arguing against...

The 'readability' thing always sounds like a superficial, syntax-level kind of
concern ("You say, 'tomato', I say...").  And certainly there's an aspect of
that, from the relatively inconsequential, like curly braces vs.
"begin...end", to stuff that makes more of a difference.  While
human-engineering at the syntax level is important, I don't think anyone is
going to say that getting it right results in huge gains in
productivity/reliability/whatever.  But the differences between Ada and
C/C++ run much deeper than this.

When an Ada advocate says things like "Ada is designed to be readable", they
are using the term "readable" in a way that doesn't really do justice to the
concept.  What they actually mean is that the source text lends itself to a
level of deep understanding of the programmer's intent.  For instance, the
"contract model" can result in a lot more information for the programmer who
is reading the declaration of a generic entity, when compared to a
C++ template declaration -- in the template "equivalent", the information
would have to be given in comments (and in that case, the compiler can't
guarantee its veracity), but is more likely going to be ignored by the writer
of the template.  In the C++ world, it's going to an extreme to document that
sort of thing.  For the "client" programmer to find out the hard way when they
try  to compile an instantiation of the template, is just considered business
as usual.  That's just one example, but the theme of making it easy for the
programmer to express design intent, not just operation, runs all the way
through the design of the language.

> It might
> be
> easier to use once you've mastered it, but it also is harder to learn.

OK, a couple of points...

1) I assume we're talking about C here, not C++.  I think C++ is a lot harder
to learn than Ada, because     while it's roughly the same in "size", it has a
lot of deep concepts (like "const correctness", linkage, etc.) that are not
only arcane, but are hightly cross-coupled, so that you kind of have to
understand all of it and keep your brain wrapped around it all in order to
really get any of it right.  For this reason, I don't think knowing C gives
one any real advantage when it comes to learning C++ vs. learning Ada.
Instead, what it gives you is a false sense that "I'm already halfway there",
which gives you the hope you need to keep trying to learn the screwy
language!  You're not really halfway there, but it helps to think you
are... :-)

2) While Ada is larger than C, you don't have to learn the whole language in
order to start using it., e.g. if you don't need tasking, you don't have to
learn Ada tasking, etc.

3) Since C is smaller, it's easier to master all the basic elements of the
language... but then so what?  What has it gotten you?  Now, in addition, you
also have to learn or invent ad hoc techniques, as in your example of structs
with callbacks.  And not only do you have to master the technique
intellectually, you then have to apply it correctly, and if you don't get it
right, the compiler can't tell you, because it has no clue what you are up
to.  You're going to have to debug it.

Debugging can be fun, but we usually have little control over the
circumstances that make it fun or un-fun.  And after you raise the level of
language abstraction so that you're detecting more bugs at compile-time, there
will still be plenty of honest run-time bugs left to go around, so you won't
miss the ones you don't have to debug anymore! :-)


> > Ada has
> > packages,
>
> C was ment to be used modular and for reuse : put your code in separate .c
> and .h files.
>
> > private types,
>
> C has that!
>
> > exceptions,
>
> you can program exceptions in C.  I never said that C has all these things,
> but you can program them, and there are masses of libraries available that
> have just what you need.
>
> > generics,
>
> use structs and callback functions and you have perfect generic types!
>
> > tasks,
>
> threads
>
> true enumeration types, true arrays,
> enumeration types in Ada are no different than they are in C.  Just because
> you have some fancy attributes (SUCC, PRED) doesn't mean that they are
> different or more powerful!  You can write functions that do exactly the
> same, even more, these functions have already been written numerous times
> and are available.
> With true arrays, do you mean out of bound checking, etc?  This can be done
> with _proper_ programming in C!

So, we have:

In Ada                                 In C
-----                                 ---

packages                              "header file / implementation file"
convention

private types                        ???

exceptions                            "you can program it",
setjmp()/longjmp(), whatever

generics                                structs & callbacks

tasks                                      threads


Yet, the Ada advocate claimed advantages for Ada because it has the things in
the first column.  What could be the explanation for this?  I see three
possibilities:

1) The Ada advocate is not aware of the things in the second column.  E.g., he
doesn't know that you can declare things in a shared header file, and then
supply the definitions of those things in a ".c" file.

2) The things in column 2 are equivalent to the things in column 1, or they
are just as good or better, e.g. threads give you everything that Ada tasks
do, and just as well, but the Ada advocate does not understand this.  For some
reason, he persists in his belief that the Ada version is better.  He just
doesn't get it.

3) The things in column 1 really are better than the things in column 2.


I think (1) can be safely dismissed.  You can probably assume, for example,
that Ada people know about #include.  Don't forget, a lot of Ada advocates are
C++ experts.  Believe me, those people understand #include.  Deeply.  In all
its glory.  Same with the example of tasking.  I don't think that when people
cite tasking as an advantage of Ada, they mean nothing more than "you can do
concurrent programming in Ada".

So it's gotta be either (2) or (3).

Let me take on the package thing, just as an example.

Let's say I have some C-style module, with the interface in "foo.h" and the
implementation in "foo.c".  OK, superficially, I have something analogous to
an Ada package spec and body.  But the thing is, "analogous" is as far as it
goes.  In important ways, they are not "equivalent"...

For instance... it's legal for foo.c to be incomplete.  It can even be empty.
How does foo.c "know" that it's supposed to be the "implementation" of foo.h?
It doesn't.  It can't.  Only the programmer knows.  C++ fixes this a little
bit, and in a not-very-satisfactory way, with its scopes (classes and
namespaces).  But then, if you are using C++ and you have a function
declaration in a .h file that is at the global scope, then there's another
problem, which is that thanks to overloading you can get the definition wrong
(doesn't match the prototype) and it's quite legal.  As far as C++ is
concerned, you didn't get it "wrong" (because only you know what "right"
is...), all you did was supply an additional, legal overloading at file scope
within the '.c' file.

For all these problems, you get to find out about it when you link the program
-- but only if there is an actual unresolved reference (think about the
implications of that for component development).  This is an irritation for
small, self-contained, one-person projects, but for large projects with
multiple teams, a product integration cycle, etc., it's more than an
irritation.

In C, everything is made to depend upon the linker.  This, along with textual
inclusion (independent compilation), is kind of the sine qua non of C/C++.  At
the linker level, which is primary in the C conception of modularity, the
fundamental unit is not the module, but the symbol.  The information loss
between what the compiler knows and what the linker can know is considerable.
(In combination with C++'s template design, this results in some truly
inscrutable link-time error messages!)

In Ada, the package spec is like a contract that the body has to fulfill, and
if it doesn't, it won't compile. How does the body of Foo know that it has
anything to do with the spec of Foo?  Simple, it says so right there: "package
body Foo is..."

That's not all...

When you put stuff in a .h file, you are making it available for other things
to #include.  And when they do that, they are dumping the stuff in your .h
file into their global scope, which is flat.  There's no way to say "The
Initialize() from foo.h" vs. "the Initialize() from bar.h" -- in fact, you
can't have both and include both.  The second one #included will result in a
redeclaration error.  So everyone has to use ad hoc naming conventions, like
"FooInitialize()".

So what's wrong with that, besides being hokey?  Well, does your concept of a
"module" really line up with the reality of a global scope that gets extended
when you #include the next thing?  Isn't the point of modularity supposed to
have something to do with encapsulation?  What place does "defensive
naming" have in any theory of modules?

Now, a C++ class defines a scope, so it gives you some namespace control.  But
a class is also a data type, so using one where all you want is namespace
control is awkward.  What was needed was a pure namespace that does not define
a data type.  This is why the C++ 'namespace' construct was invented.

But C++ namespaces are not that great.  For one thing, they are textually
disjoint.  Each file that declares namespace "foo" extends that namespace.
Namespaces partition the global namespace, but that's it.  They are not like
Ada packages.  There is no concept of separating interface and implementation,
yet enforcing the relationship at compile-time.  So while namespaces provide
one of the elements of a true module, they are not modules!  Also, neither
namespaces nor the .h/.c convention give you vsibility control (as in Ada's
private declarations).  Only classes give you something like this.

So C++ has three different mechanisms (header files, classes, and namespaces)
that overlap each other to some degree, and none of which gives you what you
should expect from a "module".  They only approximate it in different ways.

Not only that, but each #include of foo.h is subject to whatever #defines are
in effect at the point of the inclusion, which are not necessarily the same at
all the places where foo.h is #included.

Well, that's about all I have for now...

Respectfully,
Mark Lundquist

Re: Ada vs. C/C++ (was re: bitwise something-or-other)

[Mark Lundquist]

Once again, I am the first (maybe only) person to follow up on my _own_
posting... how pathetic, how typical... :-)

But some editorial corrections are in order...

Mark Lundquist (c'est moi) wrote:

> ...

> 1) I assume we're talking about C here, not C++.  I think C++ is a lot harder
> to learn than Ada, because     while it's roughly the same in "size", it has a
> lot of deep concepts (like "const correctness", linkage, etc.) that are not
> only arcane, but are hightly cross-coupled, so that you kind of have to
> understand all of it and keep your brain wrapped around it all in order to
> really get any of it right.

The following should have been in parentheses, because... well, it's
parenthetical!  It reads as if I thought Alex were arguing a particular point
(viz. C knowledge making it easier to learn C++) and I'm arguing back against
it.  But he wasn't arguing that, so don't get me wrong.  Some people have argued
this (in fact it's one of the "core values" of C++), but like I said... in this
context, it's parenthetical.

>  For this reason, I don't think knowing C gives
> one any real advantage when it comes to learning C++ vs. learning Ada.
> Instead, what it gives you is a false sense that "I'm already halfway there",
> which gives you the hope you need to keep trying to learn the screwy
> language!  You're not really halfway there, but it helps to think you
> are... :-)

OK, next...

> So, we have:
>
> In Ada                                 In C
> -----                                 ---
>
> packages                              "header file / implementation file"
> convention
>
> private types                        ???
>
> exceptions                            "you can program it",
> setjmp()/longjmp(), whatever
>
> generics                                structs & callbacks
>
> tasks                                      threads

My little table was obligingly reformatted by Netscape :-( so it came out all
screwy.Row 1 column 1 should read "packages", and row 1 column 2 should read
"'header file / implementation file' convention".  Row 3, column 2 should read
"'you can program it', setjmp()/longjmp(), whatever".
(Note, the row and column numbers start at 1... :-) sorry, very bad joke...)

-- Mark

Re: Ada vs. C/C++ (was re: bitwise something-or-other)

[Hyman Rosen]

Mark Lundquist <mark@rational.com> writes:
> For instance, C++ has its VPTR/VTABLE crap

You probably know this, but just for the record, the vptr/vtable technique
is part of an implementation to handle virtual method dispatching, and is
not defined within C++ itself. Ada dispatching is done in exactly the same
way. Indeed, I believe GNAT makes Ada tagged records compatible with
corresponding C++ classes so that pointers to such objects may be exchanged
between the two languages.

Re: bitwise comparators

[Ted Dennison]

In article <3882FC1C.2BA8C959@hotmail.com>,
  Alexander Van Hecke <alexke@hotmail.com> wrote:

> In C you'd have one while loop, and you'd put your condition in the
> while expression and that's it.  Nothing more to learn about it!


I'm a bit confused at this. Ada has a while loop construct too eg:

while x < y loop
end loop;

This is one of the situations where the two languages are essentially
similar. The main difference is that Ada doesn't require parens around
the conditional. An improvement as far as ease of learning goes, I'd
say.

I could go on a while about C vs. Ada loops. I like C's do..while loops.
Its kind of a shame Ada doesn't have that. But Ada essentially has an
"anywhere-tested" loop with the construct:
   loop
      ...
      exit when x=y;
      ...
   end loop;

You can of course simulate that in C with break, but that's really more
like doing a "if ... exit; endif;" in Ada, so I don't consider it the
same. And the for (;;) you use to make the infinite loop looks goofy.
It really comes off looking like a hack, where in Ada its quite natural.

C's continue statement would be helpful often in my Ada code, but it
does make the code tougher to follow.

The power of C's for statement is kind of neat. But I think this may be
a situation where power corrupts. I'm always too tempted to put the
entire contents of the loop in the for conditional (in the middle term,
separated by commas). Proper use of Ada's "for" statement is without
question easier for a beginner to pick up.

While I'm on that subject, I think the question mark operator is another
C feature I love a little too much which was wisely left out of Ada.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: bitwise comparators

[DuckE]

Alexander Van Hecke <alexke@hotmail.com> wrote in message
news:3882FC1C.2BA8C959@hotmail.com...
> > I'd also like to point out that the "while" construct you are using is
> > common for 'C' or Pascal, but in Ada you could use a "loop" construct
with
> > "exit when"
> >
>
> thank you all for your response!
> As many of you have pointed out, I could have used exit when ...
> But as you probably noticed, I have a C background and I'm not that
familiar
> with Ada.  I think it's a nice feature of Ada that you can write
'readable'
> code, but IMHO Ada takes a lot longer to learn, there are more constructs,
> keywords, etc...  In a word, the language is more complicated, yet not
> necessarily more powerfull (hope I don't get flamed for this :-)).   In C
you'd
> have one while loop, and you'd put your condition in the while expression
and
> that's it.  Nothing more to learn about it!
> What's your opinion on this?
>
> alex
>

I've done projects in both C and Ada, and when given a choice on a new
project I choose Ada.  Yes it takes a while to learn all of the nuances of
Ada, but the same is true of C.

There are numerous bugs I have run across in C programs that have been a
bear to track down, that are very visible in Ada.

Here's a few examples:

  for( i = 0 ; i < 10 ; i++ );
  {
    printf( "Value of i is %d\n", i );
  }

Gives the output:

  Value of i is 0

To "spot the bug" here's the equivalent Ada code:

for i in 0 .. 9 loop end loop
begin
  ada.text_io.put( "Value of i is " );
  ada.integer_text_io.put( i );
  ada.text_io.new_line;
end;

An experienced C programmer might see that extra semicolon instantly when
looking at the source code, but when digging for a needle in a haystack in a
large body of existing code, I personally can do without this kind of trap.

There are several other examples of simple C coding errors that can trip you
up, but you probably get my point.

SteveD

Re: bitwise comparators

[Matthew Heaney]

In article <3880D375.7E363123@hotmail.com> , Alexander Van Hecke 
<alexke@hotmail.com>  wrote:

> I want to do the following :
> OK_to_proceed : BOOLEAN := FALSE;
> data : Unsigned_8;
>
> while (not OK_to_proceed) loop
>     -- do stuff
>     OK_to_proceed := (data BITWISE AND 2#1#);
> end loop;
>
> so I want to exit the loop if bit one of data is set, but I don't know
> what the bitwise and is!

The bitwise and for modular types is "and".

Don't use the while form of loop; your version requires mental
gymnastics to figure out.  If you want to "exit the loop if bit one of
data is set," then say that directly:

loop
  -- do stuff
  exit when (data and 2#1#) > 0;
end loop;

You also have to be careful what you mean by "bit one".  Are you
referring to the bit that corresponds to the value of 2**0, or 2**1?
Your original example uses 2#1#, which I would probably describe as the
"bit zero."

--
Time and again the nation's courts have ruled that creationism, as a
religious dogma, cannot be taught in science classes. Now, creationists
are advancing a new tactic: eliminating the teaching of evolution and
other sciences that complement evolution, such as geology, paleontology,
and biological anthropology. By doing so, they are not only endangering
church-state separation but also seriously jeopardizing the science
education of future generations.

http://www.campusfreethought.org/sos/