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...
I can always use mode delphi.
Juha Manninen
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
