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
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
