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