Before I get ahead of myself and post this as a bug, I thought I would ask here first.
Consider line 8 in the code fragment below: The code uses +=, whereas the commented assignment on line nine uses :=
When I run the code as is (with +=) and the boolean variable, EmptyStr on line seven is true, the debugger exits the method as if the code on lines eight and ten does not exist. But when I comment that line and uncomment line nine, then the code functions properly.
Am I simply misusing +=? I mean CurrentString is a variable passed to method where this code is implemented and MIF_EmtyCharStyleMarker is a constant declared in another unit.
.Ll28:
# [46] If EmptyStr then
cmpb $0,-20(%ebp)
je .Lj58
.Ll29:
# [49] else
pushl $0
movl 8(%ebp),%eax
movl (%eax),%edx
movl 8(%ebp),%eax
movl TC_$P$PROJECT1_$$_MIF_EMPTYCHARSTYLEMARKER,%ecx
call fpc_ansistr_concat
jmp .Lj32
.Ll28:
# [46] If EmptyStr then
cmpb $0,-20(%ebp)
je .Lj58
.Ll29:
# [48] CurrentString := CurrentString + MIF_EmptyCharStyleMarker
pushl $0
movl 8(%ebp),%eax
movl (%eax),%edx
movl 8(%ebp),%eax
movl TC_$P$PROJECT1_$$_MIF_EMPTYCHARSTYLEMARKER,%ecx
call fpc_ansistr_concat
jmp .Lj32
Does that mean that the directive {$COPERATORS ON} no longer makes a difference? My example suggests it is not just the debugger.Depends on mode: in objfpc mode it is on by default. In mode delphi it is off by default. So {$COPERATORS ON} is basically just required if you want to use it in other modes than {$mode objfpc}
Then my example above should be considered a bug. I never use c-style operators. This is the first issue I run into taking the TS problem.Does that mean that the directive {$COPERATORS ON} no longer makes a difference? My example suggests it is not just the debugger.Depends on mode: in objfpc mode it is on by default. In mode delphi it is off by default. So {$COPERATORS ON} is basically just required if you want to use it in other modes than {$mode objfpc}
I don't see the bug?See my first comment with screenshot. It doesn't compile here.
The C style operators need to be fully evaluated first. It is C style, and certainly not complete (e.g. use =+ etc are not implemented)Which is why I suggested to stick to FP syntax. ;)
In this case, the two should be identical. Can you make a super simple example that still reproduce this issue so that we can confirm?
@ It looks like it has to do with the combination of object referencing.Object properties are referenced / dereferenced during execution, if I'm not mistaken. So the problem is referencing as opposed to variable address.
No. It has to do with properties. Operator += needs variable. Setters and getters have no address.
It seems that CurrentString from the original post is a property.
In this case, the two should be identical. Can you make a super simple example that still reproduce this issue so that we can confirm?
13 if boolVar then
(gdb) n
15 else
(gdb)
17 end.
(gdb)
13 if boolVar then
(gdb) n
14 SomeVar := SomeVar + 1
(gdb)
17 end.
(gdb)
@engkin, there seem to be two issues here (at least).
1. The debugger does not fully support C-style operators.
Yes, thanks for correcting me there. Suffice it to say, better not use C-style operators.@engkin, there seem to be two issues here (at least).
1. The debugger does not fully support C-style operators.
The debugger knows what FPC saved in the debug information. IAW, FPC generates wrong debug information for C operators. Specifically, wrong line number.
Yes, thanks for correcting me there. Suffice it to say, better not use C-style operators.@engkin, there seem to be two issues here (at least).
1. The debugger does not fully support C-style operators.
The debugger knows what FPC saved in the debug information. IAW, FPC generates wrong debug information for C operators. Specifically, wrong line number.