On Sat, 28 Nov 2009 00:43:39 +0200
Juha Manninen <juha.manni...@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
