Jarrett Billingsley wrote:
On Sat, Dec 27, 2008 at 2:31 AM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
For iterators, increment is quite different from
addition of an arbitrary number, so what D managed to do was effectively
to
cripple iterators. The standard library will use ranges with named
functions
so it avoids the issue, but if someone wants to define STL-style
iterators
they won't be able to.
I suppose most people who _aren't_ coming from C++ (*cough* like me
*cough*) won't be terribly unhappy about this situation.
I'm not sure how that computes. The particular notion has little to do with
C++ and is rather fundamental, so not grokking it should motivate one to
look into it (as opposed to being glad for not knowing).
I got the impression from your argument that you thought that without
an appropriate method of overloading the increment operator, it's not
possible to duplicate the _syntax_ of STL-style iterators. My
response is - who cares? I don't think of iterators as "pointers that
can be incremented," and I doubt anyone who doesn't have a C++
background thinks of them that way either. It seems that the
semantics of STL iterators can be implemented with methods just as
well.
If that's not what you were arguing - that is, if you're arguing that
C++'s operator overloading is somehow more expressive and allows you
to implement something that can't be implemented with method calls -
then I will put my foot in my mouth ;)
Well I overstated my point, sorry. The nice thing about overloading ++
is that you can use the same algorithms with built-in types and
user-defined types. You are, however, right that defining various
functions such as increment and decrement for built-ins and also
user-defined types would obviate the need for syntactically consistent
operators.
Andrei
