[fpc-pascal] "is"

[Thomas Schatzl]

Hello,

 >>
 >>Probably this also gives some additional opportunities for code
 >>optimizations.
 >
 > Well, I bet people would cry if the iterator works randomly and not
 > element by element :)

Don't know why you're so focused at this point, but certainly, yes,
they would =) but as I already mentioned, there's nothing against
defining a "natural" iteration order for certain types which of
course must be preserved during optimization. And this was just an
idea.
Maybe I'm misunderstanding you too, I'm not proposing optimizations
which change iteration order (where it hurts, e.g. for arrays).
In that specific cases more things like e.g. automatically
knowing that any internal indices can never be referenced by the
program.
If this answer is not sufficient, I'd like to ask you to explain what
you meant in other words; probably my English is too bad to understand
you here, sorry.

 >>But in the end you're right, it's only an abbreviation for already
 >>existing functionality; I'd consider it useful though.
 >
 > I don't like those iterators anyways, they are too unspecific. What
 > happens if you delete element where the iterator points to? What
 > happens, if you delete an element while iterating?

 From what I read about STL problems (some forums, some tutorials), the
STL iterator doesn't care about element deletion and element removal at
all, their value must be considered unusuable after a structural
modification of the container (and partially from what I see from simple
element modification :).
And there's also no indication of some notification returned if the
iterator is accessed after a structural modification.
So the STL doesn't give a good example in this matter too.

For the unspecificness: well, we're currently discussing the options,
don't we? My suggestion was to simply use the "compatible" way of
Delphi/.NET as far as I remember it (which is specified and easily 
accessable via the web). But in the end I think it's manageable to get
at least the same behaviour as the STL - by simply not caring about
that at all... :-)

Please correct me if I'm wrong, if possible with some definite 
reference, couldn't find one.

 > Have a look at the STL, it has imo a much better iterator design.

You're right, STL iterators are more powerful, but this is not because
of their representation or their safety, but due to their other
functionality not needed in this case. All those functions (even this
comparison stuff) could be implemented using iterator interfaces
(similar to STLs iterator types) and operators as well imo.
Or similar to STL there's the possibility of using an iterator object.
The IIterator _interface_ as used was just a proposal, which was given
because Delphi/.NET has a similar one.
The other drawback I can see is mostly due to FPC not having generics
- certainly taking this into account this proposal is _really_
inferior, but better than nothing atm. And as soon as FPC supports
generics, they can be used to remove unneeded dynamic type checks too.

Maybe somebody else has more insight in the STL or knows other iterator
implementations for more ideas.

Either way, the original point was foreach after all, which is just a
shorthand for a special type of traversal, using a special type of
iterator (STL lingo: forward-iterator). It doesn't *need* a complete
STL to do that.
It's definitely not the ultimate concept solving every problem either ;)

 > Another problem is probably that people would underestimate the
 > overhead of the foreach statement.

I don't see any overhead for basic types, since it's more or less an
advanced macro for a "for i := low(array) to high(array) do ...".
And in OO element access usually means calling some read method or some
similar (forward-)iterator (in STL-lingo) method anyway... (even STL
iterator methods result in method calls in the end)
This is in my experience the case for at least anything else than a
simple list backed up by an array (Borland's TList) where you can
directly access the element via indices; and if you actually care about
OO programming, e.g. doing information hiding.
It's not slower than doing it manually either, or am I wrong?

 > I guess you remember the list/resourcestring overhead trouble.

If I may ask, what was the problem with tlist/resourcestring issue
again? As far as I can remember, the real problem was something about
FPC creating too much/inefficient exception support code, and/or the
exception code generated by FPC optimizes for the (uncommon) exception
case which slows down the app in the (common) non-exception case too
(which is not needed).
I don't see the connection here right now.

You, as programmer, have the responsibility to choose the appropriate
data structure for your task - definitely nothing new. This won't
change that easily =)

Regards,
   Thomas