Hi,

After our discussion about not being able to use Include() with a class property, I thought I would then use the C Style += operator. After all that boils down to: i += 2; >>>>> i := i + 2;

I tried it, and yes I did add the -Sc compiler parameter...

The error message....

Free Pascal Compiler version 2.3.1 [2008/07/16] for i386 Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for i386
Compiling guitestrunner_fpgui.pas
Compiling fpg_guitestrunner.pas
/home/graemeg/programming/fpgui.wc/examples/apps/fpcunit/fpg_guitestrunner.pas(207,15) Error: Variable identifier expected
/home/graemeg/programming/fpgui.wc/examples/apps/fpcunit/fpg_guitestrunner.pas(208,24) Error: Variable identifier expected
/home/graemeg/programming/fpgui.wc/examples/apps/fpcunit/fpg_guitestrunner.pas(636) Fatal: There were 2 errors compiling module, stopping

And the code....

-----------------------------------
type
  // introduced to test += operator
  TMyOb = class(TObject)
  private
    FValue: integer;
  public
    property Value: integer read FValue write FValue;
  end;
procedure TGUITestRunnerForm.EndTest(ATest: TTest);
var
  i: integer;   // both of these are simply
  o: TMyOb;  //  to test the += operator
begin
  i := 0;
  i += 2;                      // no problems
  o := TMyob.Create;
  o.Value := 0;
  o.Value += 2;              //  Fails here
  pbName1.Position += 1;       //  <<===  Fails here, o object wasn't used
-----------------------------------

So it seems I can't use the += operator with properties either!! :-( I'm using FPC 2.3.1 updated today.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

After our discussion about not being able to use Include() with a class property, I thought I would then use the C Style += operator. After all that boils down to: i += 2; >>>>> i := i + 2;

Suspect that it gets translated to inc(i,2); not i:=i+2; and then it makes
sense again, for the same reasons as before.

Boy of boy.... FPC 2.3.1 is becoming frustrating!!

So is there a performance difference between:
   inc(i,2)    vs    i := i + 2;

If not, then can the += operator rather use the latter? After all, just about every peace of documentation on += operator I could find, they mention that it's an shorthand form of x := x + y

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Following on my previous post...  If it translates to inc(i,2)  then
why is the error message different to the Include() issue?

Error: Variable identifier expected
vs
Error: Can't take the address of constant expressions

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

So it seems I can't use the += operator with properties either!! :-(

Indeed. I've checked the code and properties are explicitly not allowed for the C-style operators. The reason is that the x+=y is translated into "x:=x+y" at the parser level rather than at the lexical level. This means that in case x is a property, at the point that this transformation is performed the compiler already resolved it into the setter property (so it can no longer access the getter).

Jonas

Just if you want to know my humble opinion: your statement isn't fair. You know a property isn't a variable, so don't assume it will behave like that. If you want a property function as a variable, eg reading and writing a class member directly, do use a public variable instead. Fpc core is doing a really nice job, improving and extending the compiler in their spare time, helping all developers writing better source code. This one is a good sample. They don't deserve such comment.

My bad. I had one of those off developer days yesterday. ;-) And it seemed everything I tried under FPC 2.3.1 did not work as expected, where they did in 2.2.3 and prior.

eg: I inherited some code from another project that I now need to amend to compile with FPC 2.3.1. Yes it's not the best looking code, but it works and I'm pushed for time, so code clean-up needs to wait.

Simple one liners like the following:

   inc(FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots,
itm.CountSlots);
or
   FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots += itm.CountSlots;

now has to change to this ugly line...

   FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots :=
      FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots +
itm.CountSlots;

Maybe it's just me, but the first two lines are much easier to read and less prone to typing errors.

And yes, I really do appreciate what the FPC core team are doing. They have done a wonderful job so far, and the reason our company will continue using FPC in the future. Unfortunately I'm not a compiler developer, so I can only comment from an applications developer point of view.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Sorry if the following sounds stupid, but I'm a applications developer, not a compiler developer. I do not know or understand the internals of a compiler.

So is what you mentioned above by design, or an oversight?  In normal
code like "x := x+y"  you are allowed to use properties or variables.
So surely the += operator which translates to "x := x+y" should also
be allowed to use properties.

We spoke earlier in another thread about hidden exceptions (rules) which will just complicate things in the long run. Well to me, this looks like one of those exceptions which the FPC core would like to prevent.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Or:

tempRow := FDayList[itm.WeekDayNum].Rows[itm.Timeslot];
tempRow.AvailableSlots := tempRow.AvailableSlots + itm.CountSlots;

Assuming .Rows[X] results in a class instance.

Micha

Jonas Maebe wrote

Indeed. I've checked the code and properties are explicitly not allowed for the C-style operators. The reason is that the x+=y is translated into "x:=x+y" at the parser level rather than at the lexical level. This

So I guess the obvious question is: would it be risky to change that so it parses it at the lexical level? :-)

Micha

Op Thu, 17 Jul 2008, schreef Micha Nelissen:

Even shorter:

with itm do
   with FDayList[WeekDayNum].Rows[Timeslot] do
     AvailableSlots:=AvailableSlots+CountSlots;

Daniël

Or

with FDayList[itm.WeekDayNum].Rows[itm.Timeslot] do
   AvailableSlots:= AvailableSlots+itm.CountSlots;

Jonas

I'm fairly certain that the C-style operators were implemented long before most, if any, Delphi feature had been implemented (possibly even before Delphi had properties).

We spoke earlier in another thread about hidden exceptions (rules) which will just complicate things in the long run. Well to me, this looks like one of those exceptions which the FPC core would like to prevent.

Feel free to file a bug report.

Jonas

Even shorter:

with itm, FDayList[WeekDayNum].Rows[Timeslot] do
    AvailableSlots:=AvailableSlots+CountSlots;

But nested or combined with-statements can be dangerous in case there are multiple fields with the same name in the different records/ classes/objects.

Jonas

And that's what I changed it to, just after I posted my message. :-) Either way, it's still two lines of code compared to one. But, it will do.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

My question too.... Would somebody be so kind as to explain the difference to me? As I mentioned before, I'm not a compiler developer.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Jonas Maebe wrote

Or with FDayList[itm.WeekDayNum].Rows[itm.Timeslot] do AvailableSlots:= AvailableSlots+itm.CountSlots;

No that's one language construct I wish Object Pascal could do without! I personally hate the 'with' statement, and it's hard to debug.

At least FPC with mode objfpc had the common sense NOT to allow the following (which I believe is still allowed in Delphi). Also tooltip evaluation/debugging doesn't work with 'with' statements in Lazarus or Delphi.

type
  MyClass = class(TObject)
  ...
  public
    property MyName: String .....
  end;
procedure MyClass.Foobar;
var
  MyName: string;
begin
  with self do
  begin
     MyName := 'hello';  // Are we using e local var MyName or MyClass.MyName??
  end;
end;

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

BTW:
I know that's a horrible example, but I think you get my point regarding the MyName variable/field. :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Op Thu, 17 Jul 2008, schreef Graeme Geldenhuys:

It is simply a tradeoff between readability and understandability. A line a:=a+1 is much more clean than a few lines of pointer dereferences, array indexes and records subscripts. The downside is that it becomes harder to track where the variables come from. Huge "with" bodies can be confusing. The programmer decides, after all writing readable code is an art.

Daniël

2008/7/17 Jonas Maebe :

Even shorter: with itm, FDayList[WeekDayNum].Rows[Timeslot] do AvailableSlots:=AvailableSlots+CountSlots;

Arg.... [grinding my teeth]
Nested with statements are even worse than my previous complaint! ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

My question too.... Would somebody be so kind as to explain the difference to me? As I mentioned before, I'm not a compiler developer.

Very rudimentary:

source --lexer--> tokens --parser--> tree --code gen--> code

- source is the .pas file etc.
- tokens are things like '{', '}', identifiers, etc.
- tree is using the grammatical rules to form a tree with 'statement' nodes, 'if' nodes, 'for' nodes, etc.
- code is the destination language (assembly usually).

There are more steps in the compiler, but this is the basic idea.

Apparantly in the tokens, the property has already been parsed to its getter function. (Making some assumptions here, I don't know fpc that well).

Micha

This is if you like the risk of using "with" ;-)
This works until somebody changes the FDayList[WeekDayNum].Rows[Timeslot] to contain CountSlots property, and all your code is broken ;-) . If you want stable code, never use the "with" or else ... ;-)

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

If you want stable code, never use the "with" or else ... ;-)

I did learn this even in the early Delphi days ;)

Moreover AFAIK, even the newest Delphi does not show the value of variables that are qualified using a "with". So you even can't debug the broken code decently.

-Michael

There are a lot of fans of "with" ;-) . I have been burned however long time ago. Now when I get a new code from somebody, my first task is to remove any "with" from it ;-). As far as I am concerned "with" is a Pascal design bug. May the guy who invented "with" track "with" bugs for eternity ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I completely agree. We use a lot of (mostly commercial) Delphi 3rd party components. All of them bought with source code to be more safe. Lot's of them make heavy use of "with". Very annoying !

-Michael

You will hardly find any in our components ;-) . Not as long as I run the company, and do most of the work. I even plan to add preprocessor to catch missed "with" during the build process.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Or Add a Method to the target object. (as long as it is part of your code base, or can be modified by you)
and then do

FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlotsInc(itm.CountSlots);
In the class that defines
  property AvailableSlot;
you can add
  procedure AvailableSlotsInc(n : Integer);

Same for include, exclude, and all the others.

Best Regards
Martin

From my understanding ( the fpc team probably can to more exact):

* lexical level
This would be like a simple "Find and Replace" on the text. This would work with anything, as it doesn't know what it is translating. (It is very similar to a (non-buildin) C-preprocessor)

* parser level
The parser will likely translate the source into a structure of objects

  a := a + 1

becomes
ObjectAssignmenOp
LeftHandTerm = ObjVariable "a"

      RightHandTerm = ObjExpression ( ObjAddition: Op1 = Variable "a";

Op2= 1 )

If that happens to "+=" then "a+=1"
ObjectAssignmenOpIncr
LeftHandTerm = ObjVariable
RightHandTerm = ObjExpression

if the left hand term is a property, then because it is the left hand (which will be assigned to), the lefthand term becomes the property-setter. The ObjectAssignmenOpIncr then has no reference to the property-getter.

Graeme Geldenhuys wrote

So is what you mentioned above by design, or an oversight? In normal code like "x := x+y" you are allowed to use properties or variables. So surely the += operator which translates to "x := x+y" should also be allowed to use properties.

Except that, when using variables, the first and the second "x" are the same entity.

I think what you need is a new feature. If the statement before the += token is a property, instead of a variable, the compiler converts it into one getter and one setter, and after that use them to perform the calculation.

But nested or combined with-statements can be dangerous in case there are multiple fields with the same name in the different

Many, many years ago, I programmed in texas instruments' pascal for the
9995. Of course it wasn't object oriented (almost nothing was at the time), but it had a short-hand notation for with, like

with a=some.record, a2=some.other.record do
begin
  a.field=a2.field;
  a.other=a2.other
end;

Of course you could also use the standard notation, but this one avoids the ambiguities.

Bye