[fpc-pascal] private integer is an illegal counter variable

[Mattias Gaertner]

On Sat, 28 Nov 2009 00:43:39 +0200
Juha Manninen <juha.manninen at phnet.fi> wrote:

> On perjantai, 27. marraskuuta 2009 23:52:30 Frank Peelo wrote:
> > > The reason is that a for-loop tries to make a number of reasonable
> > > guarantees that the counter variable cannot be modified during the loop.
> > > E.g., direct assignments to a counter variable are forbidden inside the
> > > loop (except in TP-mode). If you use a private field, then any method of
> > > that class called in the body of the loop can easily (accidentally)
> > > change the value of the counter variable, completely messing up the loop.
> > 
> > In any case, why would one want a loop counter to have any more than the
> > minimum possible scope? Why would one want it to be a class data member
> > at all? Surely it would be far better/neater/more elegant, if it is used
> > by methods, to pass it as a parameter?
> 
> Right, it is better define it locally. I did this experiment by accident when 
> copying code around.
> This is actually a good deviation from Delphi's rules. No problem here.
> 
> There are some other deviations which look weird for me, like treating 
> "string" as a dynamic ansistring sometimes but as an old shortstring 
> sometimes. That is in the default {$mode objfpc}.
> Fortunately there is {$mode delphi} which behaves more logically.
> I understand it is important to support also the old shortstring but it should 
> be defined explicitly and "string" should always mean just one thing.
> 
> Well, I guess this has been discussed before...

Yes, a lot.
And there are many reasons why there are so many string types nowadays.
Simply use {mode objfpc}{$h+} like lazarus suggests.


> I can always use mode delphi.

Then you will loose some fpc features.


Mattias