Re: "Subtract C, add Ada"

Re: "Subtract C, add Ada"

[Erik Svensson]

>  3. uninitialised pointer access
>  4. pointer references to local variables in defunct procedures
>The syntax of Ada removes or reduces errors like 1. and 2. but does
>not really address 3. or 4. (admitedly, 4. is an unnatural practice in
>Ada and would be pretty rare anyway).

Since Ada inititalizes (Sp?) all access variables to Null 3, would seem
to be handled as well, or at least easily handled.

Re: uninitialzed variables

[Richard Kenner]

In article <3f3cq3$4tu@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
>T.E.D. says that all Ada compilers he knows detect uninitialized variables.
>Well not quite, since this problem is of course recursively undecidable. It
>is true that a compiler can detect some obvious cases of uninitialized
>variables, that's not in GNAT yet, but is on our list of nice things to add.

Actually, it is in GNAT since this is done by the GCC optimizer.
Specify the flag -Wuninitialized along with -O or -O2 and it will warn
about variables that appear to be uninitialized.  As Robert points
out, this must be approximate since the problem is undecidable.  In
practice, it tends to have more false positives than false negatives.

Re: "Subtract C, add Ada"

[Norman H. Cohen]

In article <3etund$hnr@miranda.gmrc.gecm.com>, bill@valiant (R.A.L Williams)
writes: 

|> My experience of writing software and running software projects in C
|> highlights four common low-level C errors: 
|>   1. = instead of == and vice versa
|>   2. spurious ; after for(...) or while(...)
|>   3. uninitialised pointer access
|>   4. pointer references to local variables in defunct procedures
|> The syntax of Ada removes or reduces errors like 1. and 2. but does
|> not really address 3. or 4. (admitedly, 4. is an unnatural practice in
|> Ada and would be pretty rare anyway).

No, Ada helps to eliminate all four kinds of errors.

#3: In Ada, all pointers are initialized by default to null.  An attempt
to dereference a null pointer IMMEDIATELY raises Constraint_Error, so
these errors are generally discovered during testing.  (The only way they
could fail to be discovered is if the testing failed to exercise the path
along which the dereference is reached without a prior assignment of a
nonnull value.) In C such an error could remain undiscovered even if the
tests exercise the relevant path.  The arbitrary contents of the
uninitialized pointer might happen not to generate an invalid memory
reference; or the error could occur sporadically and irreproducibly, but
manifest itself only indirectly, much later in the execution of the
program, because of some datum clobbered by assignment to the variable
"pointed to" by an uninitialized pointer.  Then the error might never be
properly attributed to the dereference of an uninitialized pointer.

#4: In Ada 83, access values point only to dynamically allocated
variables, not to declared variables, so the issue does not arise.
In Ada 95, access values can pointed to variables declared aliased, but a
pointer to a local variable of a subprogram can only belong to an access
type that is itself declared inside the subprogram, so the pointer cannot
outlive the variable to which it was pointing.

|> The really strong point about Ada, especially where large teams, or
|> inexperienced coders, are involved is that it strongly encourages
|> the separation of SPECIFICATION from IMPLEMENTATION, and provides
|> a language enforced formalisation of the mechanism. Never mind the
|> commonly expressed rationale behind this, ie. information hiding: 
|> forcing the interfaces between components to be *designed* before
|> attempting to write the implementation, and then encouraging (because
|> of the sheer hassle of not doing it) some sort of formal mechanism
|> if the interfaces have to be changed has got to be the main factor in
|> the success of a project.

I agree.  I also agree with you that it is not hard for programmers who
understand the Ada philosophy to use C in a disciplined way to simulate
Ada packages.  However, violations of the discipline are not easily
recognized or enforced.  (The discipline involves, among other things,
remembering to override the inexcusable C default that functions are
extern rather than static; and always #include'ing a header file with the
declarations of a file's external functions both in the file defining
those functions--to ensure consistency as the file is modified--and in
all files calling such functions.)

But don't underestimate the power of the stupid little errors--the ones
that occur and persist in C programs, but never occur or are eliminated
immediately in Ada programs--to slow a project down or even cause its
failure.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: "Subtract C, add Ada"

[David O'Brien]

R.A.L Williams (bill@valiant) wrote:
: My experience of writing software and running software projects in C
: highlights four common low-level C errors:
:   1. = instead of == and vice versa

I have to wonder.  What if C defined the logical equals operator to be
"=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
Modula-x, etc?  Would this error still exist???

Quickly thinking about it, I feel that I write a lot more assignment
statements than local statements, couldn't I be in the habit of typing
":=" and thus accidently type that when I meant logical comparison?
Since that would still be a perfectly valid, conforming C program,
the compiler is not required to give any warnings (just like current
practice).  Thus, I would still have the same logic error in my program.
Chances of happening???  Any bodies guess.  So is the problem really
one of symbol choice, or program semantics?


:   2. spurious ; after for(...) or while(...)

This is one area I *really* like about Ada.  However, I feel there
is a much more common programming error (occurs in Pascal too):
     for (...)
	first_action();
	second_action();

The indenting implies that "second_action()" should be part of the
the loop body.  But it isn't.  :-))   So many times I've seen this
in industry.  Every new programmer I work with I try to drill into
their head's "*always* use braces with your if, while, for statements,
even when you have only one thing in your loop body.  For one day a
maintainer will need to add that second thing, and indent like the
above -- forgetting to add the braces."  Many will not listen thinking
they know better.  Tisk, tisk, tisk.  Usually it doesn't take long for
them to get bitten and remember.  Same for Pascal.  I really don't
understand why most languages are designed the Pascal/C way rather
than the Ada way.  Especially since it removes the common ambiguity
of nested if statements.

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[Laurent Gasser]

In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
|> R.A.L Williams (bill@valiant) wrote:
|> : My experience of writing software and running software projects in C
|> : highlights four common low-level C errors:
|> :   1. = instead of == and vice versa
|> 
|> I have to wonder.  What if C defined the logical equals operator to be
|> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
|> Modula-x, etc?  Would this error still exist???

The problem is in the language definition, not in the choic of symbols.
C is one of the rare language I use to allow having an assignment after 
the if statement.  All other languages only allow for a boolean test.

I never saw a good reason for allowing this.

-- 
Laurent Gasser (gasser@dma.epfl.ch)
Computers do not solve problems, they execute solutions.

I know very few ideas worth dying for, none is worth killing.

Re: "Subtract C, add Ada"

[John DiCamillo]

gasser@masg1.epfl.ch (Laurent Gasser) writes:

>In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
>|> R.A.L Williams (bill@valiant) wrote:
>|> : My experience of writing software and running software projects in C
>|> : highlights four common low-level C errors:
>|> :   1. = instead of == and vice versa
>|> 
>|> I have to wonder.  What if C defined the logical equals operator to be
>|> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
>|> Modula-x, etc?  Would this error still exist???

>The problem is in the language definition, not in the choic of symbols.
>C is one of the rare language I use to allow having an assignment after 
>the if statement.  All other languages only allow for a boolean test.

>I never saw a good reason for allowing this.

Huh? It falls naturally out of two other C rules:

1) an assignment is an expression whose value is equal
   to that of the thing being assigned,
2) any expression that evaluates to integer 0 is false,
   all other expressions are true.

C would have required a special restriction to prevent
assignment in an if-test.  (Note that assignment in a
loop-test is a useful and common idiom in C.)

That said, if this error is anyone's biggest concern
about developing software in C, then that person has
not really tried to develop software in C.  All lan-
guages have warts, even Ada.

-- 
    ciao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: "Subtract C, add Ada"

[David O'Brien]

Laurent Gasser (gasser@masg1.epfl.ch) wrote:
: In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
: |> R.A.L Williams (bill@valiant) wrote:
: |> : My experience of writing software and running software projects in C
: |> : highlights four common low-level C errors:
: |> :   1. = instead of == and vice versa
: |> 
: |> I have to wonder.  What if C defined the logical equals operator to be
: |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
: |> Modula-x, etc?  Would this error still exist???

: The problem is in the language definition, not in the choice of symbols.
: C is one of the rare language I use to allow having an assignment after 
: the if statement.  All other languages only allow for a boolean test.

Yep, that's my point.  The argument of character choice really isn't what
is at the essence of the problem.  Rather it is the language definition.


: I never saw a good reason for allowing this.

Simply the paradigm of C that *every* statement has a value.  And C has
no special logical values.  So C has "values are values" akin to Ford's
offering of the Model-T, "any colour you want, as long as it's black".
I'm guessing Ritchie did this for the same reason as Henry Ford - to
simply things.  Which gave us the situation we have.

In most languages the grammar would be:

	conditional_statement ::=  if <logical_expression> then

Which in C becomes:

	conditional_statement ::=  if ( <expression> ) <statement>

and thus ``<expression>'' must include ``<lvalue> = <expression>''.

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[Keith Thompson]

In <3f4mbe$rud@cronkite.seas.gwu.edu> dobrien@seas.gwu.edu (David O'Brien) writes:
> I have to wonder.  What if C defined the logical equals operator to be
> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
> Modula-x, etc?  Would this error still exist???
> 
> Quickly thinking about it, I feel that I write a lot more assignment
> statements than local statements, couldn't I be in the habit of typing
> ":=" and thus accidently type that when I meant logical comparison?
> Since that would still be a perfectly valid, conforming C program,
> the compiler is not required to give any warnings (just like current
> practice).  Thus, I would still have the same logic error in my program.
> Chances of happening???  Any bodies guess.  So is the problem really
> one of symbol choice, or program semantics?

I suspect this error would be rarer if C used ":=" for assignment.
The symbol "=" is used for equality in some languages (Pascal, standard
mathethematical notation, etc.) and assignment in others (Fortran,
C, etc.).  The symbol ":=" is used only for assignment.  I don't think
I've ever accidentally typed ":=" for a comparison in Ada.

Digression:
    I once heard about a relatively obscure language that used ":" as
    a catenation operator.  It also had C-style assignment operators.
    So, naturally, the statement "x := y;" assigned to x the result of
    catenating x and y.
end Digression;

Of course, if C used ":=" for assignment and "=" for comparison, the
opposite error would be likely to occur; people would commonly type
    x = y;
which, instead of assigning the value of y to x, would compare them
and discard the result.  This could be caught by a compiler warning;
an assignment in an expression context sometimes makes sense, but a
comparison in a statement context never does.  It could even be forbidden,
but I suppose that would violate the spirit of C.

Hmm.  How about ":=" and ".EQ."?  8-)}

Please note that this article is not an anti-C flame; it's a theoretical
discussion about programming language syntax design.  Yeah, there's
the ticket.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
When you're a nail, every problem looks like a hammer.

Re: "Subtract C, add Ada"

[Matt Kennel]

R. William Beckwith (beckwb@ois.com) wrote:
: John DiCamillo (milod@netcom.com) wrote:

: : That said, if this error is anyone's biggest concern
: : about developing software in C, then that person has
: : not really tried to develop software in C.  All lan-
: : guages have warts, even Ada.

: Some languages' warts are really malignant tumors.  ;-)

So, all languages have warts, but only in bad ones do
they metastasize?  ;-)

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".

Re: "Subtract C, add Ada"

[Robert Dewar]

"Dennis Ritchie once said in an interview that there is *nothing* in the
 C language that keeps compiler writers from issuing stringent warnings
 about stuff that most Ada people take for granted."

Dennis may have said this, but it is misleading. Yes, there is stuff that
Ada people take for granted that C compilers could (and in some compilers
*do*) check for.

But there are lots of things that Ada people take for granted that cannot
be checked in C, there just isn't enough information. C has no separation
of scalar types, no ranges on scalar types, and the ubquitous use of
pointers, and their similarity to arrays means that sophisticated aliasing
analysis is required to even approximate the type checking that occurs
in the context of access types in Ada. There are many other examples.

Re: "Subtract C, add Ada"

[David Moore]

dewar@cs.nyu.edu (Robert Dewar) writes:

>For another example of UNIFY/CONFUSE, does Algol-68 confuse or unify the
>concepts of pointers and variables.

My vote would be for UNIFY. Algol-68 clarified many things that were
implicit in other languages. For example, Algol 68 made it clear that
in the expression:

	A:=A;

The type of A on the left has one more "ref" than the A on the right. I
have found that being cavalier about ref's is a good way to get in
a horrible mess when writing a compiler or debugger. Hence, I believe
anyone who intends to be a language implementor or lawyer should
be familiar with Algol 68.

Unfortunately, it also introduced W-Grammars which I find almost impossible 
to manipulate. They belong to level 3, or perhaps 4 in the complexity 
heirarchy of formalisms:

	Level 1 Formalism.

		You can push instances (eg simple sentences in the language)
                through the formalism in your head.

	Level 2 Formalism.

		You can push through instances on a piece of foolscap while
		sitting at your desk.

	Level 3 Formalism.

		You have to get up and clean off the whiteboard before starting.
		
	Level 4 Formalism.

		You and your colleagues have to go into a conference room and clean
		off the whiteboards. You first have to argue that the phrase 
		"Do not erase" has a scope no larger than the phrase itself.

Fortunately, there is also an "informal" report on Algol 68 which is very
readable.

Re: "Subtract C, add Ada"

[Norman H. Cohen]

Just yesterday I made a one-character typo in a C program (don't ask; it
puts food on the table) that preserved the legality of the program but
rather radically altered its behavior.  I meant to type

   for (i=0; i<10; i++)

but my finger slipped off the shift key when I was typing "<", so it came
out

   for (i=0; i,10; i++)

which tests for loop termination by evaluating i, discarding that value,
evaluating 10, and leaving the loop when 10 equals zero (i.e., never).

What a language!

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: "Subtract C, add Ada"

[R. William Beckwith]

John DiCamillo (milod@netcom.com) wrote:
: beckwb@ois.com (R. William Beckwith) writes:

: >John DiCamillo (milod@netcom.com) wrote:

: >: That said, if this error is anyone's biggest concern
: >: about developing software in C, then that person has
: >: not really tried to develop software in C.  All lan-
: >: guages have warts, even Ada.

: >Some languages' warts are really malignant tumors.  ;-)

: Did you have something useful to follow that up with?

No, but I'll make the attempt since you're interested.

: Do you disagree with either of the sentences you were
: responding to?  Do you feel that I am misrepresenting
: the relative quality of the two languages in question?

Not really and yes.  I agree everything has warts.
It has been my experience that while Ada's occasional
warts can be annoying, C's occasional warts can be deadly.

... Bill

Re: "Subtract C, add Ada"

[Samuel Mize]

In article <3f5s92$3id@info.epfl.ch>,
Laurent Gasser <gasser@masg1.epfl.ch> wrote:
>
>The problem is in the language definition, not in the choic of symbols.
>C is one of the rare language I use to allow having an assignment after 
>the if statement.  All other languages only allow for a boolean test.
>
>I never saw a good reason for allowing this.
>

It's a question of who optimizes your code.  In the 60s,
when C was developed, compilers *couldn't* optimize code,
so the programmer had to.  Many apparently-bizarre C
capabilities are there to support optimization level -1
(programmer does the optimizations).

Consider the common C idiom to copy a null-terminated
array, usually a string [syntax may not be quite right]:

     while (*a++=*b++);

Recall that C considers 0 false, a null character is integer
0, and an assignment returns what was assigned.  This loop
condition copies the character at address b to address a,
increments both, and exits when a null was copied.  There is
no statement inside the loop.

This is more efficient, with a non-optimizing compiler, than

  while (*a)
    { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/

because
* The operator ++ increments the value of while it's still
  in a register.  The second code reads a from memory to
  do the character assign, reads it again to increment it.

* ++ can use the assembler's increment instruction.  a=a+1
  could not.

* Using the assignment as the loop expression indirectly
  directs the compiler to keep the result of the assignment
  in a register for reuse in the expression, instead
  of writing it to memory, then reading it.

Thus, with a lot of man-hours, expertise and skull-sweat,
someone using a basic C compiler can come within an order
of magnitude of the efficiency of someone using a half-good
optimizing Ada compiler.  Often.

Of course, if you only *read* the code, and don't *run*
it, it looks like the C is more optimized, because you can
*see* the optimizations.

With Ada you write less-optimized-looking code, and trust
the compiler.  (But verify.)

>-- 
>Laurent Gasser (gasser@dma.epfl.ch)
>Computers do not solve problems, they execute solutions.
>
>I know very few ideas worth dying for, none is worth killing.

I dunno, I've killed quite a few ideas in my time :-)

Sam Mize - smize@starbase.neosoft.com

Re: "Subtract C, add Ada"

[David O'Brien]

In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote:
: It's a question of who optimizes your code.  In the 60s,
: when C was developed, compilers *couldn't* optimize code,
: so the programmer had to.  Many apparently-bizarre C
: capabilities are there to support optimization level -1
: (programmer does the optimizations).

C was designed in the 70's.  The earliest reference I could find to it
is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter
Century of Unix".  The language from which C developed, B, was created
in 1970.  And the only published document on the B language, "CSTR #8 -
The Programming Language B", is dated Jan 1973.  BCPL, which B came
from, is from 1969.

So, I think that "compilers *couldn't* optimize code" may be an over
generalization.  Is this _really_ the case for 1970's compiler
technology?

: Consider the common C idiom to copy a null-terminated
: array, usually a string [syntax may not be quite right]:

:      while (*a++=*b++);

I am curious about programming culture.  Notice that when someone writes
something in C they feel they have to remove all white space.  When they
write in Ada they put in plenty and use [very] long names for every
thing.  Why is that???  No wonder people say C is hard to read.


: This is more efficient, with a non-optimizing compiler, than

:   while (*a)
:     { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/

: because
: * The operator ++ increments the value of while it's still
:   in a register.  The second code reads a from memory to
:   do the character assign, reads it again to increment it.

You are making a *major* assumption about the CPU this is running on.
On many smaller uP's there isn't that many registers.

: * ++ can use the assembler's increment instruction.  a=a+1
:   could not.

Since adding 1 to variable is so common place, it is trivial to add this
type of optimization (even in your parser).

: * Using the assignment as the loop expression indirectly
:   directs the compiler to keep the result of the assignment
:   in a register for reuse in the expression, instead
:   of writing it to memory, then reading it.

Again, you really are thinking with a preconceived notion of your
hardware.

-- David O'Brien	(dobrien@sea.gwu.edu)

Re: "Subtract C, add Ada"

[Robert Dewar]

"compilers couldn't optimize code"

what is meant here is "C compilers didn't optimize code", and this was partly
a matter of philosophy, the idea that C compilers should be simple and do
what you say, and NOT rely on optimization.

Optimization technology was well developed even in the late 60's. Fortran-2
for the 7094 did a remarkably good job of optimizing loops. Fortran-H
was contemporary with early C compilers, and was very aggressive in optimizing
typical Fortran code.

Re: "Subtract C, add Ada"

[Norman H. Cohen]

In article <3frqpg$re5@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu
(David O'Brien) writes: 

|> In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote: 
|> : It's a question of who optimizes your code.  In the 60s,
|> : when C was developed, compilers *couldn't* optimize code,
|> : so the programmer had to.  Many apparently-bizarre C
|> : capabilities are there to support optimization level -1
|> : (programmer does the optimizations).
...
|> : Consider the common C idiom to copy a null-terminated
|> : array, usually a string [syntax may not be quite right]: 
|>
|> :      while (*a++=*b++);
|>
|> I am curious about programming culture.  Notice that when someone writes
|> something in C they feel they have to remove all white space.  When they
|> write in Ada they put in plenty and use [very] long names for every
|> thing.  Why is that???  No wonder people say C is hard to read.

It's because the primitive compilers of the 1970's were incapable of
optimizing away the whitespace. ;-)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: "Subtract C, add Ada"

[John Cosby - The Coz]

David O'Brien (dobrien@seas.gwu.edu) wrote:
: In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote:
: : It's a question of who optimizes your code.  In the 60s,
: : when C was developed, compilers *couldn't* optimize code,
: : so the programmer had to.  Many apparently-bizarre C
: : capabilities are there to support optimization level -1
: : (programmer does the optimizations).

: C was designed in the 70's.  The earliest reference I could find to it
: is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter
: Century of Unix".  The language from which C developed, B, was created
: in 1970.  And the only published document on the B language, "CSTR #8 -
: The Programming Language B", is dated Jan 1973.  BCPL, which B came
: from, is from 1969.

The July-August 1978 edition of "The Bell System Technical Journal" contains
an article by Ritchie, Johnson, Lesk, and Kernughan entitled "The C 
Programming Language."  In this article they state that B was written in 1970
by Ken Thompson "for the first UNIX system on the PDP-11."  They go on to
discuss how the introduction of types was a major departure from BCPL and B
and mention in passing that C was created "circa 1972."  An interesting 
article, which discusses many of the issues debated during the evolution 
of Ada into Ada95 from a much "earlier" point of view.  Fun to see how 
far we've come.

John

Re: "Subtract C, add Ada"

[Samuel Mize]

In article <3frqpg$re5@cronkite.seas.gwu.edu>,
David O'Brien <dobrien@seas.gwu.edu> wrote:
...
>C was designed in the 70's. ...
>So, I think that "compilers *couldn't* optimize code" may be an over
>generalization.

My apologies for a loose statement.

I meant to address the observed beliefs of people who feel
that they can write more-efficient code in C.  Generally,
they hand-write code-level optimizations; they can see it,
so they believe in it.  They don't expect the compiler to
optimize much.  Some of them don't *want* the compiler to
optimize; they're using side effects and "slick tricks" to
save three instructions per hundred.  Of course, a good
optimizer would do far better for them, but they can't see that
unless they meter their program, optimize it, and meter it
again.  Why bother with what when they *know* that it's more
efficient code...

Of course, the source code doesn't run.  The object code runs.

...
>You are making a *major* assumption ...
>Again, you really are thinking with ...

Your entire post is right, except for attributing these beliefs
to *me*.  I was unclear.  These are beliefs that C programmers
have stated to me, as to why C is "more efficient" than Ada.
Of course, if a programmer is manually optimizing, he/she must
have assumptions about, and a model of, the machine on which
the code will run.  Sometimes, these will be wrong.

Another argument for machine optimization, which Ada better
supports.

>-- David O'Brien	(dobrien@sea.gwu.edu)

Yours in agreement,
Sam Mize - smize@starbase.neosoft.com

Increment operator (+=)

[Jacob Sparre Andersen]

Robert Dewar (dewar@cs.nyu.edu) wrote the most recent article I have read 
in the thread about the operator "+=" in C.

In two still not mentioned languages (dialects) there are these solutions 
to the 'problem':

In COMAL (BASIC like) there are ":+" and ":-" incrementing and decrementing 
'assignments'.

    antal_sider:+1
    rest:-1

In Borland's Pascal dialect the system library contains these procedures:

    Inc(var SomeInteger : <integer type> ; Step : <integer type>) ;
    Dec(var SomeInteger : <integer type> ; Step : <integer type>) ;

I think the last solution is the right way to do it in Ada. But it's only 
really usefull, if any type with "+" and "-" operators can 'inherit' the 
procedures (I don't think that's how Ada 95 works).
The Borland way (tm :-) is just how we should code. No Ada 96 :-)

--

I like the idea about using local renames.

--

"add 1 to long-complex-name" - What a nice readable piece of code. What's 
wrong with this language? :-)

Regards,
                Jacob Sparre Andersen
--
A good movie? - What about three? - Kieslowskis 'White', 'Blue' and 'Red'!
--
URL's: "mailto:sparre@nbi.dk", "http://meyer.fys.ku.dk/~sparre", 
       "mailto:sparre+@pitt.edu" & "http://www.pitt.edu/~sparre".
--
"We need a plan to diverge from", Fesser

Re: Adding in COBOL...

[Robert Dewar]

David Weller says:  

Easy, Robert:

        add (1, to=> long_complex_name);

Gee, I thought I'd never see the day I could teach Robert something

Umm? I think you forgot something David, what is the type of the add
procedure. I guess it is a generic, so don't forget to instantiate it,
and oh yes, remember to pass the "+" operator to the generic while you
are at it (wouldn't want the dread reemergence doing us in), and also
remember to inline it (and hope that inlining generic instances works
fine and ....

Ada vs. C

[Martijn Bak]

>It all falls out of the design of the language. Constructs like "+="
>provide no benifit other than to save typing within a single
>statement. Take the statement:
>
>  Principle = Principle + (Interest * Time)
>
>The "+=" operator is MADE for this statement, but its ONLY benifit is
>to save me 11 characters in my source file. 

Nope, in general this is _not_ true! The statements
	expr1 += expr2;
and
	expr1 = expr1 + expr2;
are _not_ the same. In the former, expr1 is evaluated only once, in the
latter expr1 is evaluated twice. This is not only a matter of execution
speed. It is especially important if expr1 has side-effects.

There is also a conceptual benefit for the += (if expr1 is very complex).
Compare
	a[i->j(q,b)] = a[i->j(q,b)] + 2;
and
	a[i->j(q,b)] += 2;

In the latter case, neither the writer nor the reader of this code need
to check whether a[i->j(q,b)] and a[i->j(q,b)] realy are the same.

Yep, I _am_ a C programmer.

-- 
-- Martijn Bak -- AND Software -- Westersingel 108, 3015 LD  Rotterdam --
-- tel: +31-10-4367100 -- fax: +31-10-4367110 -- email: martijn@and.nl --

Ada vs. C

[The Quelisher]

I have found one thing that C has an advantage over Ada : executable
file sizes. Everything I have programmed in Ada is HUGE compared to a
program thta does the same thing but written in C.

Just my $.02
-- 
    *.........................................*
    .                |/                       .
    .                |\ENDAL                  .
    . WWW   => http://www.cs.fsu.edu/~vandyke .
    . EMail => kendal@freenet.scri.fsu.edu    .
    . Pager => (904) 297-6658                 .
    .                                         .
    *.........................................*

Re: Ada vs. C

[Daniel P Hudson]

The Quelisher <kendal@freenet.scri.fsu.edu> wrote:
>I have found one thing that C has an advantage over Ada : executable
>file sizes. Everything I have programmed in Ada is HUGE compared to a
>program thta does the same thing but written in C.

>Just my $.02

 Psst, over here. That's a feature of the COMPILER, not the language.
 Plus, any OO language will compile larger a structured langauge because
 of the overhead OO requires.

 If you don't understand this, let me clarify. Years ago, when Microsofts
 Quick_C 1.0 was still a major sought after item by those trying to learn
 C, I was told by a close-minded friend that I was wasting my time
 writting my programs in Quick_Basic. Besides being the most unintelligent
 statement I had ever heard, after all these were my programs for MY 
 computer and they appeared to be working just fine to me, it was
 a challenge which I accepted. I asked him why and he told me the 
 code was slow and too big. My friend had never even seen a Basic compiler
 so this was his first shock, his second was when QuickBasic 4.5 
 mainly matched QC 1.0 in the final output tests. The language had nothing
 to do with it, the compilers were from the same general time era and
 the company implemented the same technology in both. The library was
 the only that determined which was better, and QB didn't give you the 
 control over FP that QC did, so QC had one advantage. Now, in
 today, most language are equivalent in such tests because compiler
 technology is shared quite freely due to projects like GNU or the
 newsgroup comp.compilers and freely available docs on a variety
 of architectures. However, if you compile these two sources

 /* c */
 #include <stdioh.>

 int main(void)
 {
   printf("Hello, World!\n");
   return 0;
 }

   --------------------------------------------------------------------

 // cpp
 #include <iostream.h>

 int main(void)
 {
   cout << "Hello, World!" << endl;
   return 0;
 }

 I guarentee you that the C code will always come out smaller than the C++
 equivalent will, due to OO overhead. Ada uses OO, even thouhgh you can
 code in a proceedural fashion, the standard libs are designed to be
 used in OO programming and therefore carry the OO overhead. Is this
 a bad thing? Only if you don't feel that an OO approach is the best
 solution to your current task, but it does seem that the CIS community
 is moving toward OOP.

Re: Ada vs. C

[Robert Dewar]

The Quelisher says

"I have found one thing that C has an advantage over Ada : executable
file sizes. Everything I have programmed in Ada is HUGE compared to a
program thta does the same thing but written in C."


That's bogus, comparable programs in Ada and C will generate executables
of the same size, at least using a technology like GNAT. You have however
to be careful about that "comparable". Note for example that in GNAT,
by default the executable files contain debugging information which is
typically much more voluminous than the code itself -- so make sure 
you are comparing stripped file sizes. Second, in some version of GNAT,
the default is to link statically, and in others to link dynamically.
Be careful you are not comparing a statically linked Ada program to a
dynamically linked C program.

It's true that in the default configuration on some ports of GNAT, the
exe files will be bigger, due in particular to the inclusion by default
of debugging information. This choice of defaults is deliberate and
reflects the fact that disk prices have dropped dramatically, so the
gain from having the debugging information around seems worth the space
(after all a 300K file these days is occupying 5 cents worth of disk space).
Note also that it is ONLY a space issue, the debugging information is not
loaded if you are not debugging.

But anyway, if you don't want the debugging information, just make sure
it is stripped.

Re: Ada vs. C

[Jack W Scheible]

In article <3208F2BA.E34@freenet.scri.fsu.edu> kendal@freenet.scri.fsu.edu writes:
>I have found one thing that C has an advantage over Ada : executable
>file sizes. Everything I have programmed in Ada is HUGE compared to a
>program thta does the same thing but written in C.

Disk space is cheap, program maintenance is not.

-jack

Re: Ada vs. C

[Robert Dewar]

Daniel said

" I guarentee you that the C code will always come out smaller than the C++
 equivalent will, due to OO overhead. Ada uses OO, even thouhgh you can
 code in a proceedural fashion, the standard libs are designed to be
 used in OO programming and therefore carry the OO overhead. Is this
 a bad thing? Only if you don't feel that an OO approach is the best
 solution to your current task, but it does seem that the CIS community
 is moving toward OOP."

I have no idea what this means. The standard libraries consist, at least
in GNAT, of hundreds of separate units, some of which use some features
of OO (not many), most of which do not. There is no inherent OO overhead.
Your guarantee with respect to C and C++ is also completely odd. Indeed
since C++ is largely a subset of C, the typical C++ code that corresponds
to the C code is identical to the C code, and in any reasonable compilation
environment generates exactly the same bits as the C code.

Re: Ada vs. C

[The Quelisher]

Robert Dewar wrote:
> That's bogus, comparable programs in Ada and C will generate 
> executables of the same size, at least using a technology like GNAT. 

Ok, so let me explain where I am coming from then. Here is the source in
both languages that does the exact same very basic thing:
-----------------------------------------------------------------------
C :
	main()
	{
		printf("Hello world! \n");
	}

-----------------------------------------------------------------------
Ada :

	WITH Ada.Text_IO; USE Ada.Text_IO;
	PROCEDURE hello IS
	BEGIN
	  Put_line("Hello world!");
	END hello;
-----------------------------------------------------------------------

When I compiled each of the above here are the file sizes that resulted:
	C ----> 24,576
	Ada -->	253,952

I used gcc to compile the C code and gnatmake for the Ada code, both on
unix machines. Now that's what I meant by the difference in file sizes.
I understand though that there is a tradeoff between file size and
functionability of a program, but let's take PC's for example. Who wants
to run a 6 mb program written in Ada when a 2mb program written in C
does the same thing? I'm not trying to knock Ada or anything, rather
just making an observation. Again, just my $.02

-- 
    *.........................................*
    .                |/                       .
    .                |\ENDAL                  .
    . WWW   => http://www.cs.fsu.edu/~vandyke .
    . EMail => kendal@freenet.scri.fsu.edu    .
    . Pager => (904) 297-6658                 .
    .                                         .
    *.........................................*

Re: Ada vs. C

[Robert Dewar]

The Quelisher said

"When I compiled each of the above here are the file sizes that resulted:
        C ----> 24,576
        Ada --> 253,952"

So what? this does not prove, or even relate to your point, and it is 
certainly complete nonsense to take this observation and deduce from
it that a 6 megabyte Ada program will correspond to a 2 megabyte C program.

Why are the above figures not relevant.

First: the size of an executable file is not related to the size of the
executable program in any simple way. Two factors are of critical importance.
First, are they both stripped or not, I am willing to bet that the Ada
file was not stripped -- so why didn't you strip it to make the comparison.

Second, I would guess the Ada program is statically linked, and the C
program is dynamically linked, meaning that the space for Text_IO is
included in the Ada size you see, and the space for printf is not included
in the C file that you see.


Finally, and most importantly, these are quite different programs, one
uses the package printf, and the oher uses the package Text_IO. Yes, there
is some overlap in capability, but they are definitely not the same package,
and both contain functionality not in the other. 

If you want to persue this, first make sure you understand what stripping
is about, and also what dynamic vs static linking is about, so that these
factors do not make your observations meaningless, and then compare
programs that are comparable!

Re: Ada vs. C

[steved]

The Quelisher <kendal@freenet.scri.fsu.edu> writes:
>Robert Dewar wrote:
>> That's bogus, comparable programs in Ada and C will generate 
>> executables of the same size, at least using a technology like GNAT. 
>
>Ok, so let me explain where I am coming from then. Here is the source in
>both languages that does the exact same very basic thing:
>-----------------------------------------------------------------------
>C :
>	main()
>	{
>		printf("Hello world! \n");
>	}
>
>-----------------------------------------------------------------------
>Ada :
>
>	WITH Ada.Text_IO; USE Ada.Text_IO;
>	PROCEDURE hello IS
>	BEGIN
>	  Put_line("Hello world!");
>	END hello;
>-----------------------------------------------------------------------
>
>When I compiled each of the above here are the file sizes that resulted:
>	C ----> 24,576
>	Ada -->	253,952
>
I think you'll find that if you add another ten lines of code to your example,
the size of the Ada executable will NOT increase proportionally.

Yes, for small app's C will come out smaller.  But for real reasonably sized
app's I think you'll find the sizes to be comparable.

My Opinion,
Steve Doiel
steved@pacifier.com

Re: Ada vs. C

[Bob Kitzberger]

The Quelisher (kendal@freenet.scri.fsu.edu) wrote:
: Robert Dewar wrote:
: > That's bogus, comparable programs in Ada and C will generate 
: > executables of the same size, at least using a technology like GNAT. 

[Ada vs. C hello world example]

: When I compiled each of the above here are the file sizes that resulted:
: 	C ----> 24,576
: 	Ada -->	253,952

But these aren't real-world programs.  You'll probably discover that
much of the Ada overhead is fixed -- runtime requirements for tasking
(and you may be able to remove much of that if you don't use
tasking).

: I understand though that there is a tradeoff between file size and
: functionability of a program, but let's take PC's for example. Who wants
: to run a 6 mb program written in Ada when a 2mb program written in C
: does the same thing?

Of course no one wants to.    But basing observations on "hello
world" is silly.  I suspect that if you use the same underlying
back-end technology, the size of the Ada vs. C programs will
increase at roughly the same rate, once you ignore the
fixed-size runtime costs.

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: Ada vs. C

[Robert Dewar]

Here is some realistic data on comparing C and Ada. The programs I 
compared are:

In Ada

procedure f is
   procedure printf (s : string);
   pragma Import (C, printf, "printf");
begin
   printf ("Hello World!");
end f;


In C

#include <stdio.h>
main(int argc, char *argv[], char *envp[])
{
   printf("hello world\n");
}


The stripped executables compiled by gcc are of course identical in
size as one would expect, 24580 bytes in either case.

I used printf in both programs so that they are exactly comparable. Now
of course if you include an additional package in the Ada version, like
GNAT.IO, then you will find that the Ada program gets bigger, it goes
up to 32772 bytes.

The additional 8200 bytes represents not some mysterious Ada inefficiency
but simply the size of this package, since it is linked statically and
not dynamically.

If we use the more complex package Text_IO, then the size gets larger still,
up to 53252 bytes. Once again, the extra 28K bytes simply represents the
size of the Text_IO package. Not surprisingly it is larger than the
simple GNAT.IO package since it has far more capability (it also uses
some of the other Ada library facilities like finalization support).

I can of course (since gcc allows mixed language programming) make a C
program which uses Text_IO facilities, guess how big it is -- that's right
53252 bytes (what a surprise :-)

I suppose these figures may surprise some people, but to me it would
be surprising if comparable C and Ada programs were NOT the same size!

Re: Ada vs. C

[Dave Wood]

The Quelisher wrote:
> 
> Robert Dewar wrote:
> > That's bogus, comparable programs in Ada and C will generate
> > executables of the same size, at least using a technology like GNAT.
> 
> Ok, so let me explain where I am coming from then. Here is the source in
> both languages that does the exact same very basic thing:
> -----------------------------------------------------------------------
> C :
>         main()
>         {
>                 printf("Hello world! \n");
>         }
> 
> -----------------------------------------------------------------------
> Ada :
> 
>         WITH Ada.Text_IO; USE Ada.Text_IO;
>         PROCEDURE hello IS
>         BEGIN
>           Put_line("Hello world!");
>         END hello;
> -----------------------------------------------------------------------
> 
> When I compiled each of the above here are the file sizes that resulted:
>         C ----> 24,576
>         Ada --> 253,952
> 
> I used gcc to compile the C code and gnatmake for the Ada code, both on
> unix machines. Now that's what I meant by the difference in file sizes.
> I understand though that there is a tradeoff between file size and
> functionability of a program, but let's take PC's for example. Who wants
> to run a 6 mb program written in Ada when a 2mb program written in C
> does the same thing? I'm not trying to knock Ada or anything, rather
> just making an observation. Again, just my $.02
> 

I get the following "hello world" figures on the PC:

Visual C++ 4.2  --------------->  76.0 KB
ObjectAda for Windows v7.0 ---->  89.5 KB

This compares the current VC++ release against the pre-release ObjectAda
compiler, both with debug symbols turned off and no special optimizations.

Not much of a difference, really, especially considering that MS has
had uncounted gazillions of person-years to apply to MSVC compared to
the humble Ada vendor (ahem).

So, I'd have to agree with Robert:  if you're comparing apples and
apples, there's little fundamental reason that an Ada program must
be bigger than a C program.  I don't see where this is a language
issue, as opposed to an implementation issue.

By the way, you forgot to #include <stdio.h> in your C snippet.  :)

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- http://www.thomsoft.com

Re: Ada vs. C

[Jerry van Dijk]

The Quelisher (kendal@freenet.scri.fsu.edu) wrote:

: Robert Dewar wrote:
: > That's bogus, comparable programs in Ada and C will generate 
: > executables of the same size, at least using a technology like GNAT. 

: 		printf("Hello world! \n");

: 	  Put_line("Hello world!");

: When I compiled each of the above here are the file sizes that resulted:
: 	C ----> 24,576
: 	Ada -->	253,952

To me this looks like comparing a C program using shared libraries to a
statically linked Ada program...

Besides, what do you think you are comparing here ? With only one line
of executable code, the programs mainly consist of the program start-up
code and runtime library. And then I would expect the GNAT executable to
be somewhat larger then the C one, since the GNAT RTL contains more
functionality (like tasking).

If you really want to compare executable file sizes, you should use two 
equivalent programs, large enough to make size of the RTL insignificant
compared to the code size.

But, then, whats the point to it...

P.S. Under DOS a GNAT hello world is about 87K, a gcc one about 57K.
     If I were to use a 16-bit C compiler I would expect a 6K exe size.
     Using an embedded systems compiler would bring that down to about
     500 bytes. If that is still to big, handwritten assembler will
     get away with about 40 bytes.

Re: Ada vs. C

[Vladimir Vukicevic]

dewar@cs.nyu.edu (Robert Dewar) writes:
> 
> Here is some realistic data on comparing C and Ada. The programs I 
> compared are:
>
> [..]
> 
> The stripped executables compiled by gcc are of course identical in
> size as one would expect, 24580 bytes in either case.
> [..]
> I can of course (since gcc allows mixed language programming) make a C
> program which uses Text_IO facilities, guess how big it is -- that's right
> 53252 bytes (what a surprise :-)
> 
> I suppose these figures may surprise some people, but to me it would
> be surprising if comparable C and Ada programs were NOT the same size!

Come on, Robert, you can't really believe that C and Ada programs compile
into the exact same size, no matter how identical they are. They are
very close in size: (f being the ada code, and foo being the C code)

-rw-rw-r--   1 vladimir vladimir      896 Aug 12 15:37 f.o
-rw-rw-r--   1 vladimir vladimir      880 Aug 12 15:38 foo.o

However, when compiled into full apps, the ada code needs to have
gnatbind needs to do various initialization, and only then call
procedure f(). In C, this isn't necessary; as such, the resulting
executable files have the following sizes [stripped, all libraries
shared]:

-rwxrwxr-x   1 vladimir vladimir     6692 Aug 12 15:46 f*
-rwxrwxr-x   1 vladimir vladimir     2436 Aug 12 15:47 foo*

Why the large size discrepancy? Because f is being linked (albeit shared)
with libgnat, libc, libpthread, and libm. foo, on the other hand,
is just being linked shared with libc. f also has the overhead of b_f.c,
whereas foo does not.

This is all rather pointless, actually, since executable file size doesn't
have anything to do with memory requirements of the program or running time
or whatnot. For comparison purposes, here is an equivalent program
in java:

		public class F {
			public static void main (String args[])
			{
				System.out.println ("hello world");
			}
		}

The resulting runnable code size?

-rw-rw-r--   1 vladimir users         407 Aug 12 15:51 F.class

I guess this makes java twice as good as Ada and C :-)

		- Vladimir

--
Vladimir Vukicevic  <vladimir@arp.com>  [std disclaimer here]
 C makes it easy for you to shoot yourself in the foot.  C++ makes that
 harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup

Re: Ada vs. C

[busigin]

In <320D2677.499F@thomsoft.com>, Dave Wood <dpw@thomsoft.com> writes:
>The Quelisher wrote:
>> 
>> Robert Dewar wrote:
>> > That's bogus, comparable programs in Ada and C will generate
>> > executables of the same size, at least using a technology like GNAT.
>> 
>> Ok, so let me explain where I am coming from then. Here is the source in
>> both languages that does the exact same very basic thing:
>> -----------------------------------------------------------------------
>> C :
>>         main()
>>         {
>>                 printf("Hello world! \n");
>>         }
>> 
>> -----------------------------------------------------------------------
>> Ada :
>> 
>>         WITH Ada.Text_IO; USE Ada.Text_IO;
>>         PROCEDURE hello IS
>>         BEGIN
>>           Put_line("Hello world!");
>>         END hello;
>> -----------------------------------------------------------------------
>> 
>> When I compiled each of the above here are the file sizes that resulted:
>>         C ----> 24,576
>>         Ada --> 253,952
>> 
>> I used gcc to compile the C code and gnatmake for the Ada code, both on
>> unix machines. Now that's what I meant by the difference in file sizes.
>> I understand though that there is a tradeoff between file size and
>> functionability of a program, but let's take PC's for example. Who wants
>> to run a 6 mb program written in Ada when a 2mb program written in C
>> does the same thing? I'm not trying to knock Ada or anything, rather
>> just making an observation. Again, just my $.02
>> 
>
>I get the following "hello world" figures on the PC:
>
>Visual C++ 4.2  --------------->  76.0 KB
>ObjectAda for Windows v7.0 ---->  89.5 KB
>
>This compares the current VC++ release against the pre-release ObjectAda
>compiler, both with debug symbols turned off and no special optimizations.
>
>Not much of a difference, really, especially considering that MS has
>had uncounted gazillions of person-years to apply to MSVC compared to
>the humble Ada vendor (ahem).
>
>So, I'd have to agree with Robert:  if you're comparing apples and
>apples, there's little fundamental reason that an Ada program must
>be bigger than a C program.  I don't see where this is a language
>issue, as opposed to an implementation issue.
>
>By the way, you forgot to #include <stdio.h> in your C snippet.  :)
>
>-- Dave Wood
>-- Product Manager, ObjectAda for Windows
>-- http://www.thomsoft.com

Using GNAT under OS/2, the hello program compiles to
a 262,958 byte executable. When I strip the debug code,
the size goes down to 53,252 bytes. When I run the
LxLite utility program to compress the EXE file, the size
goes down to 31,364 bytes. This file size is certainly not
out of line with C/C++ compilers.

Anthony Busigin
NITEK Corporation

Re: Ada vs. C

[Robert Dewar]

Anthony said

"Using GNAT under OS/2, the hello program compiles to
a 262,958 byte executable. When I strip the debug code,
the size goes down to 53,252 bytes. When I run the
LxLite utility program to compress the EXE file, the size
goes down to 31,364 bytes. This file size is certainly not
out of line with C/C++ compilers.
"

And if you link dynamically instead of staticaly, you can of course
reduce the executable size much further.