FPC offers the +=, -=, etc., statements swiped from C. Is there any reason why ++ and -- are not similarly supported? I know that we have inc() and dec(), but I'd say that ++ and -- are easier to type.

Timothy Groves wrote

FPC offers the +=, -=, etc., statements swiped from C. Is there any reason why ++ and -- are not similarly supported? I know that we have inc() and dec(), but I'd say that ++ and -- are easier to type.

General side note with no intention to start discussion about superiority of one language to another: A lot of C constructs is easier to type than their Pascal equivalents but not necessarily even equally easy to read.

Now specifically to your question - I believe that one of the reasons may be the fact that Pascal does not support unary arithmetic operators in postfix notation. The fact that C allows using them with both prefix and postfix notation makes them even more difficult from my point of view because potentially allowing them only in one of the notations known from other languages would immediately trigger users to ask why only one of possible notations (common elsewhere) is supported and the other not.

Tomas

If you dig in the mailing list a while ago, there's a fact revealed there. The C style operator was actually a 3rd party contribution, not the initial feature design.

One of the reason people who prefer Pascal is because it's easier to read, not easier to type. A brainfuck code would be the easiest to type (single character per operation) but the hardest to read.

In our previous episode, leledumbo said:

If you dig in the mailing list a while ago, there's a fact revealed there. The C style operator was actually a 3rd party contribution, not the initial feature design.

And mostly accepted for easy conversion purposes, not to write new code.

Seconded.

I've got a vague recollection that some of the ++ and -- semantics are particularly unpleasant, and that one of the C inventors did his best to disown them. At least += etc. are fairly unambiguous: they're almost macro expansions and as such they don't mandate any extra overloadable operators etc.

The most important points with these operators is to remember that they are once "increase/decrease then return" (prefix) and once "return then increase/decrease" (postfix)

Regards,
Sven

Also +=, etc are not true operators in FPC like they are in e.g. C++, but they are internally translated to "a := a + b", etc. So potential sideeffects need to be remembered here.

Regards,
Sven

FWIW:

the += etc. assignment operators make sense IMO,
because for complex expressions involving array indices etc. that are to be incremented or decremented, it is no more necessary to write them twice.

Compared to that, the difference between ++ and += 1 (with ++ you have to put parantheses around the expression to be incremented !!)
seems unimportant.

And, if that's a matter for you: the newer PL/1 compilers support += etc., but don't support ++ and --,

Kind regards

Bernd

That's not entirely true. For example "a:=a+b" is allowed for
properties, while "a+=b" is not allowed for properties.

Mattias

Yes, that's right. I forgot to mention that restriction...

Regards,
Sven

In our previous episode, Mattias Gaertner said:

I think Sven meant that a is only evaluated once. (in case it is an expression). Not that it operates on all types.

(If +=, -= etc. would have been copied from Algol68 and not from C, it would have been written +:= -:=, which looks more pascal-like. And the acceptance for these constructs would be wider, I assume. Just an optical note to that theme).

Beside of the question, if ++,--,+=,etc. fit into Pascal or not, there stays the question: is it a plus?
I expected that
a[i] += 3
compiles better than
a[i] := a[i] + 3
I expected that the computation of a[i] is done only once, but the produced code is the same, the address of a[i] is computed twice. So the whole construct is only a typing saving.
Compilation done with FP 2.6.2, winxp, 32-bit)

Constructs like I++, ++I are nice shortcuts (and sometimes the code can be better readable), but have only a real value, if the produced code is a bit optimized.

standard:
    i := i + 1 ;
    a[i] := 3
with ++:
    a[++i] := 3 ;

Could save one (or two) assembler statements!

And now let's wait for people who want to see "a[++i++] := 2" in the
language!

Gerhard

Syntax and generated code are in principle unrelated. The reason you don't get the optimised version of the code, is probably because you used global variables. Make the array and i local, and you will see that in both cases the address of a[i] is calculated only once. Constructs involving global variables are harder to analyse for side-effects, so they are simply not optimised at all in many cases by FPC.

Constructs like I++, ++I are nice shortcuts (and sometimes the code can be better readable), but have only a real value, if the produced code is a bit optimized.

That was true in the eighties when C statements were pretty much directly mapped to assembler. Nowadays, they make code actually harder to optimise because they introduce side-effects in the middle of expressions.

Adding a particular syntax to a programming language in order to work around a (realistically solvable) weakness of the optimiser is an extremely bad approach to language design.

Jonas

Syntax and generated code are in principle unrelated. The reason you don't

get the optimised version of the code, is probably because you used global variables

I second that. People who uses C style short unreadable code approach usually state they get more optimized code, yet the compiler is actually able to produce the same with optimizations turned on. Well, todays compilers are not like early compilers where the output is a direct mapping of the input (i.e. the only optimization is at source level typed by your fingers analyzed by your brain), are they?

I tried it now with locals and globals, but with the same results.

The code:

program plusas ;
  type
    t = array [ 1..10 ] of longint ;
  var
    i : longint ;
    a : t ;
  function incg ( var i : longint ) : longint ;
//inc(i),return the incremented i
    begin
      inc ( i ) ;
      result := i ;
     end ;
  procedure l ;
    var
      i : longint ;
      a : t ;
    function incl ( var i : longint ) : longint ;
//inc(i),return the incremented i
      begin
        inc ( i ) ;
        result := i ;
       end ;
    begin
      i := 1 ;
      a[i] := a[i] + 3 ;
      a[i] += 3 ;
      a[incg ( i )] += 3 ;
      a[incl ( i )] += 3 ;
     end ;
  begin
    i := 1 ;
    a[i] := a[i] + 3 ;
    a[i] += 3 ;
    a[incg ( i )] += 3 ;
   end.

Very obviously the += is implemented as a kind of macro, if the index is a function, it is called twice with surprising result.

According to the FPC manual (I just looked it up), which says:

a += b Adds b to a, and stores the result in a.
Remark: These constructions are just for typing convenience, they don't generate different code.

this is the expected result, I must admit.

From my common sense thinking, i would have expected something like:

    a[incg ( i )] += 3 ;

translates to

    P := @ a[incg ( i )] ;
    P^ := P^ + 3 ;

I have no C compiler since I don't like C, but I would like to know how C compilers handle +=.

The GNU C manual says:
+= Adds the two operands together, and then assign the result of the addition to the left operand.

Could be understood ambiguous also.

I know the += from Algol68, where it is defined very exact:

op (hplusab, +:=)  =(ref  int a,  int b) ref  int :a := a + b;

or, in pascal-like terms

operator += ( var a : longint ; b : longint ) z : longint ; begin a := a + b
; z := a ; end ;

Exact definitions normally give less surprising results. So I think I will forget += etc.

Gerhard Scholz wrote

I tried it now with locals and globals, but with the same results.

Yes, currently there is only a difference if the left side is a call (e.g. a function that returns a record or something like that).

Technically it would be simple to change that as the corresponding code is already available for the above mentioned situation, but it would definitely change the semantics if the left side is e.g. an array with a function as index accessor (as the function is then only called once)...

The code generated on i386 for this example:

=== code begin ===

   i := 0;
   arr[i] := arr[i] + 1;
   arr[i] += 1;
   arr[MyInc(i)] += 1;

=== code end ===

will look like this without optimizations:

=== code begin ===

# Temps allocated between ebp-28 and ebp-24
# [15] begin
pushl %ebp
movl %esp,%ebp
leal -28(%esp),%esp
# Var arr located at ebp-20
# Var i located at ebp-24
# [16] i := 0;
movl $0,-24(%ebp)
# [17] arr[i] := arr[i] + 1;
movl -24(%ebp),%eax
movl -20(%ebp,%eax,4),%edx
addl $1,%edx
movl -24(%ebp),%eax
movl %edx,-20(%ebp,%eax,4)
# [18] arr[i] += 1;
movl -24(%ebp),%eax
leal -20(%ebp,%eax,4),%eax
movl %eax,-28(%ebp)
movl -28(%ebp),%eax
movl (%eax),%edx
addl $1,%edx
movl -28(%ebp),%eax
movl %edx,(%eax)
# [19] arr[MyInc(i)] += 1;
leal -24(%ebp),%eax
call P$OPTEST_$$_MYINC$LONGINT$$LONGINT
leal -20(%ebp,%eax,4),%eax
movl %eax,-28(%ebp)
movl -28(%ebp),%eax
movl (%eax),%eax
addl $1,%eax
movl -28(%ebp),%edx
movl %eax,(%edx)

=== code end ===

and like this with O2:

=== code begin ===

# Temps allocated between esp+24 and esp+28
# [15] begin
addl $-28,%esp
# Var arr located at esp+0
# Var i located at esp+20
# [16] i := 0;
movl $0,%edx
movl %edx,20(%esp)
# [17] arr[i] := arr[i] + 1;
addl $1,(%esp,%edx,4)
# [18] arr[i] += 1;
movl 20(%esp),%eax
leal (%esp,%eax,4),%eax
movl %eax,24(%esp)
movl (%eax),%edx
addl $1,%edx
movl 24(%esp),%eax
movl %edx,(%eax)
# [19] arr[MyInc(i)] += 1;
leal 20(%esp),%eax
call P$OPTEST_$$_MYINC$LONGINT$$LONGINT
leal (%esp,%eax,4),%eax
movl %eax,24(%esp)
movl (%eax),%eax
addl $1,%eax
movl 24(%esp),%edx
movl %eax,(%edx)

=== code end ===

What bugs me a bit is that temporary variable at 24(%esp), but that might be a result of FPC's current temp var system...

Regards,
Sven

leledumbo wrote

People who uses C style short unreadable code approach usually state they get more optimized code, yet the compiler is actually able to produce the same with optimizations turned on.

No, I simply prefer to use += and -= because it is easier to read the code (for me at least). But with the added restrictions applied in recent FPC releases (eg: those shortcuts don't work with properties any more) I am slowly forced to move back to the verbose a := a + b syntax. :-/

Regards,
Graeme.

I believe it would be much better if FPC would do this (that is, evaluate the left side on assignments like a += b only once), because the other program languages like C and PL/1 that provide the same syntax do it the same way. So people who use other languages too will be less surprised.

Semantically, it's not the same, but

a += b

can be replaced by

inc ( a, b ) ;

It's readable, it looks like normal standard Pascal; and it's clear that the address of a is
calculated only once.

If a,b are not ordinals, inc could be overloaded.

Greetings

Gerhard