This is a little bit off topic but I hop you'll forgive me.

A few days ago some expressed the opinion (in a post I can't find, but
it was probably in one of Razii's threads) that Java's iterators were
better than C++ iterators, or at least that the Java iterator concept
was better (or something to that effect). I would be interested to hear
about why whoever wrote it feels that way.

--
Erik Wikström

On Apr 3, 2:12pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> This is a little bit off topic but I hop you'll forgive me.
>
> A few days ago some expressed the opinion (in a post I can't find, but
> it was probably in one of Razii's threads) that Java's iterators were
> better than C++ iterators,

You mean this?

http://tinylink.com/?iaOmlBsgBy

On Thu, 03 Apr 2008 19:12:27 GMT, Erik Wikström
<Erik-wikstrom@telia.com> wrote:

>A few days ago some expressed the opinion (in a post I can't find, but
>it was probably in one of Razii's threads) that Java's iterators were
>better than C++ iterators, or at least that the Java iterator concept
>was better (or something to that effect). I would be interested to hear
>about why whoever wrote it feels that way.

For fun, I sent the blog page

(http://razi2.blogspot.com/2008/04/wh...than-java.html )

to the author of
http://bruscy.multicon.pl/pages/prze..._than_cpp.html

his email response was:

-- quote--
see explanation to hash.cpp and hash2.cpp on my webpage.
If you use standard library as defined in 1998, you can't make the C++
faster. You either have to use original SGI STL map or unordered_map
from C++ 0x . (Or any hashmap from less standard sources like Boost).
With any of these solutions, C++ beats Java hands down.

There are other performance problems in the code, like this line:
std::string input( buffer.str() );
which needlessly copies the whole 40MB for the second time, but the
performance impact of that is insignificant in comparison to the
impact of using tree based map.
-- end quote ---

I am not sure what that really means but I am still waiting for C++
version that is faster and would compile on GCC.

Onn Thu, 03 Apr 2008 19:12:27 GMT, Erik Wikström..
<Erik-wikstrom@telia.com> wrote:

>A few days ago some expressed the opinion (in a post I can't find, but
>it was probably in one of Razii's threads) that Java's iterators were
>better than C++ iterators, or at least that the Java iterator concept
>was better (or something to that effect). I would be interested to hear
>about why whoever wrote it feels that way.

For fun, I sent the blog page

(http://razi2.blogspot.com/2008/04/wh...than-java.html )

to the author of
http://bruscy.multicon.pl/pages/prze..._than_cpp.html

his email response was:

-- quote--
see explanation to hash.cpp and hash2.cpp on my webpage.
If you use standard library as defined in 1998, you can't make the C++
faster. You either have to use original SGI STL map or unordered_map
from C++ 0x . (Or any hashmap from less standard sources like Boost).
With any of these solutions, C++ beats Java hands down.

There are other performance problems in the code, like this line:
std::string input( buffer.str() );
which needlessly copies the whole 40MB for the second time, but the
performance impact of that is insignificant in comparison to the
impact of using tree based map.
-- end quote ---

I am not sure what that really means but I am still waiting for C++
version that is faster and would compile on GCC..

On 3 avr, 21:12, Erik Wikström <Erik-wikst...@telia.com> wrote:
> This is a little bit off topic but I hop you'll forgive me.

> A few days ago some expressed the opinion (in a post I can't
> find, but it was probably in one of Razii's threads) that
> Java's iterators were better than C++ iterators, or at least
> that the Java iterator concept was better (or something to
> that effect). I would be interested to hear about why whoever
> wrote it feels that way.

That was me, and the reason is simply: you don't need two of
them. Try chaining functions which use iterators, for example.
Or writing a filtering iterator.

Not that Java's iterators are perfect, either. The merge access
and incrementing---as did the USL iterators. By the time Java
was being developed, we'd already established that this wasn't a
good idea, so it's hard to understand why they did it.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 2008-04-03 22:04, Razii wrote:
> On Thu, 03 Apr 2008 19:12:27 GMT, Erik Wikström
> <Erik-wikstrom@telia.com> wrote:
>
>>A few days ago some expressed the opinion (in a post I can't find, but
>>it was probably in one of Razii's threads) that Java's iterators were
>>better than C++ iterators, or at least that the Java iterator concept
>>was better (or something to that effect). I would be interested to hear
>>about why whoever wrote it feels that way.
>
> For fun, I sent the blog page
>
> (http://razi2.blogspot.com/2008/04/wh...than-java.html )
>
> to the author of
> http://bruscy.multicon.pl/pages/prze..._than_cpp.html
>
> his email response was:
>
> -- quote--
> see explanation to hash.cpp and hash2.cpp on my webpage.
> If you use standard library as defined in 1998, you can't make the C++
> faster. You either have to use original SGI STL map or unordered_map
> from C++ 0x . (Or any hashmap from less standard sources like Boost).
> With any of these solutions, C++ beats Java hands down.
>
> There are other performance problems in the code, like this line:
> std::string input( buffer.str() );
> which needlessly copies the whole 40MB for the second time, but the
> performance impact of that is insignificant in comparison to the
> impact of using tree based map.
> -- end quote ---
>
> I am not sure what that really means but I am still waiting for C++
> version that is faster and would compile on GCC.

Relevance?

--
Erik Wikström

On Thu, 03 Apr 2008 21:03:29 GMT, Erik Wikström
<Erik-wikstrom@telia.com> wrote:

>Relevance?

You have Iterators only when you have containers, like map or vector

On 2008-04-03 21:38, lbonafide@yahoo.com wrote:
> On Apr 3, 2:12 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>> This is a little bit off topic but I hop you'll forgive me.
>>
>> A few days ago some expressed the opinion (in a post I can't find, but
>> it was probably in one of Razii's threads) that Java's iterators were
>> better than C++ iterators,
>
> You mean this?
>
> http://tinylink.com/?iaOmlBsgBy

Yes, thanks.

James, can you explain what you meant by "... for most everyday jobs
like this, in fact, the Java collections library (and especially the
concept of iterators in Java) is far superior to the STL."?

While it was some time ago since I last used Java (before generics) I've
always liked the way the STL iterators, it is a quite simple concept but
still very powerful. To my knowledge there is not easy way to perform
operations on a subset of a container using Java's iterators.

--
Erik Wikström

On Thu, 3 Apr 2008 14:02:01 -0700 (PDT), James Kanze
<james.kanze@gmail.com> wrote:

>Not that Java's iterators are perfect, either. The merge access
>and incrementing---as did the USL iterators. By the time Java
>was being developed, we'd already established that this wasn't a
>good idea, so it's hard to understand why they did it.


I am not sure what you mean but with with 1.5, the syntax changed from

for(Iterator lineup = list.iterator() ; lineup.hasNext() ; ) {
Object thatThing = lineup.next();
myMonster.eat(thatThing);
}

to

for(Object thatThing : list) {
myMonster.eat(thatThing);
}

On 2008-04-03 23:12, Razii wrote:
> On Thu, 03 Apr 2008 21:03:29 GMT, Erik Wikström
> <Erik-wikstrom@telia.com> wrote:
>
>>Relevance?
>
> You have Iterators only when you have containers, like map or vector
>

And?
Read my post again and tell me how your response is relevant.

--
Erik Wikström

Erik Wikström writes:

> This is a little bit off topic but I hop you'll forgive me.
>
> A few days ago some expressed the opinion (in a post I can't find, but
> it was probably in one of Razii's threads) that Java's iterators were
> better than C++ iterators, or at least that the Java iterator concept
> was better (or something to that effect). I would be interested to hear
> about why whoever wrote it feels that way.

This is stupid. This is like saying that apples are better than oranges.
Some people like apples more than oranges, other people like oranges more
than apples. There is no quantifiable way to compare apples and oranges on
some nebulous, global, "better" scale.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBH9W9Cx9p3GYHlUOIRAhtEAJ9yGLYN5dp2V0CVA+MROt k8z1qeyACfUWSQ
a7tzSoCXRqP+oDhGBMsOIKM=
=uBLO
-----END PGP SIGNATURE-----

Sam <sam@email-scan.com> wrote in
news:cone.1207267138.348818.29934.500@commodore.em ail-scan.com:

> Erik Wikström writes:
>
>> This is a little bit off topic but I hop you'll forgive me.
>>
>> A few days ago some expressed the opinion (in a post I can't find,
>> but it was probably in one of Razii's threads) that Java's iterators
>> were better than C++ iterators, or at least that the Java iterator
>> concept was better (or something to that effect). I would be
>> interested to hear about why whoever wrote it feels that way.
>
> This is stupid. This is like saying that apples are better than
> oranges. Some people like apples more than oranges, other people like
> oranges more than apples. There is no quantifiable way to compare
> apples and oranges on some nebulous,

Right, there is no quantifiable way to compare the taste of apples and
oranges, nor is there a way to convince someone that one is better than
another. With programming constructs or paradigms, however, there are
often tradeoffs in choosing one over another, and reasons for choosing
one over another can be concrete.

On Apr 3, 11:13 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> On 2008-04-03 21:38, lbonaf...@yahoo.com wrote:

[...]
> James, can you explain what you meant by "... for most everyday jobs
> like this, in fact, the Java collections library (and especially the
> concept of iterators in Java) is far superior to the STL."?

> While it was some time ago since I last used Java (before generics) I've
> always liked the way the STL iterators, it is a quite simple concept but
> still very powerful. To my knowledge there is not easy way to perform
> operations on a subset of a container using Java's iterators.

It's easier with Java's iterators than with those of C++. Try
it sometime: call std::transform with some function which should
only be applied to every third element. In Java, you simply
create a filtering iterator (using an anonymous class, if you
wish). In C++, you use boost::filtering_iterator, of course,
it's still more awkward (since you need to create two of them),
and from a purely STL point of view, you should take a look at
the hoops boost::filtering_iterator has to jump through.

Of course, the real problem comes when you want to call a
function to operate on a subset determined by another function.
In Java, that would simply be f( g( collection ), operation ),
where g( collection ) returns a filtering iterator, and f takes
an iterator (any iterator of the correct type), and the
functional operation object. In C++, g must return a pair of
iterators, and you need to store them somewhere, and then call
f() in a separate statement.

Projection and filtering iterators, and function chaining, are
some of the most fundamental concepts, which I used to use
everywhere, in pre-STL days.

The iterator pattern in the GoF was established and standard
practice as early as 1990. Neither Java nor the STL have the
excuse of not knowing the flaws in their iterator idiom by the
time they were developing them. In the case of Java, they
adopted existing practice (e.g. the USL library) known to be
somewhat flawed (next and accessing the element should be two
separate operations); in the case of the STL, the authors
decided to ignore all existing practice, and invented something
far less usable.

(There are few special cases where the two iterator model is
useful. It works well for tokenizing an input stream, for
example. The problem with this is that every time I've wanted
to tokenize an input stream, I've either had input
iterators---which don't allow establishing a sub-range using a
previously saved iterator---or a random access container, in
which case, I could just as easily use indexes, rather than
iterators. In fact, my ParserSource class is modeled more on
C++'s other iterators, streambuf, than it is on STL iterators.
But it really could be just a GoF iterator as well.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Apr 3, 11:12 pm, Razii <DONTwhatever...@hotmail.com> wrote:
> On Thu, 03 Apr 2008 21:03:29 GMT, Erik Wikström

> <Erik-wikst...@telia.com> wrote:
> >Relevance?

> You have Iterators only when you have containers, like map or
> vector

Since when? C++ has istream_iterator in the standard, and Boost
has a lot of iterators which don't depend on an underlying
container. And you can easily do the same thing in Java---much
more easily, in fact. (The fact that they are so easy to
implement may account for why no one felt it necessary to
provide them as standard, or as part of a widely used library.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Apr 3, 11:22 pm, Razii <DONTwhatever...@hotmail.com> wrote:
> On Thu, 3 Apr 2008 14:02:01 -0700 (PDT), James Kanze
>
> <james.ka...@gmail.com> wrote:
> >Not that Java's iterators are perfect, either. The merge
> >access and incrementing---as did the USL iterators. By the
> >time Java was being developed, we'd already established that
> >this wasn't a good idea, so it's hard to understand why they
> >did it.

> I am not sure what you mean but with with 1.5, the syntax
> changed from

> for(Iterator lineup = list.iterator() ; lineup.hasNext() ; ) {
> Object thatThing = lineup.next();

And that's the problem. You should be able to access the object
without advancing the iterator. Most logically, advancing the
iterator should be the third part of the if.

The standard "pattern" is:

for ( Iterator iter( someInitializationArguments ) ;
! iter.isDone() ;
iter.next() ) {
doSomethingWith( iter.element() ) ;
}

In a well written iterator, doSomethingWith should encompass
deleting the element from the container, if the iterator is
based on a container. (IIRC, Java supports this; C++ definitely
doesn't.)

> myMonster.eat(thatThing);
> }

> to

> for(Object thatThing : list) {
> myMonster.eat(thatThing);
> }

Interesting. But isn't it just a cosmetic fix? Suppose that my
doSomethingWith, above, was actually to remove the element from
the underlying container, g.e.:

for ( Iterator i = list.iterator() ; list.hasNext() ; ) {
Object o = iter.next() ;
if ( condition( o ) ) {
iter.remove() ;
}
}

Try writing a filtering iterator in Java which supports that,
and you'll see why merging advance and access is a bad idea.
(Of course, from a design point of view, it's very ugly.
Separation of concerns should be an important guiding
principle.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Apr 4, 1:58 am, Sam <s...@email-scan.com> wrote:
> Erik Wikström writes:
> > This is a little bit off topic but I hop you'll forgive me.

> > A few days ago some expressed the opinion (in a post I can't find, but
> > it was probably in one of Razii's threads) that Java's iterators were
> > better than C++ iterators, or at least that the Java iterator concept
> > was better (or something to that effect). I would be interested to hear
> > about why whoever wrote it feels that way.

> This is stupid. This is like saying that apples are better
> than oranges.

No. You're not comparing things in an absolute. If you call
something an "iterator", it is because it fulfills a specific
purpose. Implicit in the statement is that "Java iterators are
better iterators than C++ iterators". Sort of like "oranges are
a better source of vitamin C than apples".

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Fri, 4 Apr 2008 01:24:49 -0700 (PDT), James Kanze
<james.kanze@gmail.com> wrote:

>And that's the problem. You should be able to access the object
>without advancing the iterator. Most logically, advancing the
>iterator should be the third part of the if.
>
>The standard "pattern" is:
>
> for ( Iterator iter( someInitializationArguments ) ;
> ! iter.isDone() ;
> iter.next() ) {
> doSomethingWith( iter.element() ) ;
> }

If the problem is that "You should be able to access the object
without advancing the iterator", where am I calling next in this
syntax.

int[] nums = { 1, 2, 3, 4, 5, 6 };

for(int n : nums) {
System.out.println(n);
}

Or

List list = getList();

for (Object element : list) {
out.println(element);

// Do something else with this element
}

James Kanze writes:

> On Apr 4, 1:58 am, Sam <s...@email-scan.com> wrote:
>> Erik Wikström writes:
>> > This is a little bit off topic but I hop you'll forgive me.
>
>> > A few days ago some expressed the opinion (in a post I can't find, but
>> > it was probably in one of Razii's threads) that Java's iterators were
>> > better than C++ iterators, or at least that the Java iterator concept
>> > was better (or something to that effect). I would be interested to hear
>> > about why whoever wrote it feels that way.
>
>> This is stupid. This is like saying that apples are better
>> than oranges.
>
> No. You're not comparing things in an absolute. If you call
> something an "iterator", it is because it fulfills a specific
> purpose. Implicit in the statement is that "Java iterators are
> better iterators than C++ iterators". Sort of like "oranges are
> a better source of vitamin C than apples".

Except that there is no common denominator between Java and C++ iterators
that can be used as a measuring stick. A better analogy would be saying that
because both apples and oranges are fruits, one of them is a better fruit
than the other.

Totally meaningless.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBH9grux9p3GYHlUOIRAhdYAJwJFcr4T+XpMi2KC04WCg B7eBac8ACeMCJp
UOKlxvGBcpAnthKfOvxTLwo=
=2qcA
-----END PGP SIGNATURE-----

Hi

Razii wrote:

> If the problem is that "You should be able to access the object
> without advancing the iterator", where am I calling next in this
> syntax.

Easy...

> int[] nums = { 1, 2, 3, 4, 5, 6 };
>
> for(int n : nums) {
^^^^^^^^^^^^

Here...

> System.out.println(n);
> }
>
> Or
>
> List list = getList();
>
> for (Object element : list) {
^^^^^^^^^^^^^^^^^^^^^
.... and here.

> out.println(element);
>
> // Do something else with this element
> }

Markus

Sam <sam@email-scan.com> wrote in
news:cone.1207306990.975400.1548.500@commodore.ema il-scan.com:

> James Kanze writes:

>> No. You're not comparing things in an absolute. If you call
>> something an "iterator", it is because it fulfills a specific
>> purpose. Implicit in the statement is that "Java iterators are
>> better iterators than C++ iterators". Sort of like "oranges are
>> a better source of vitamin C than apples".
>
> Except that there is no common denominator between Java and C++
> iterators that can be used as a measuring stick. A better analogy
> would be saying that because both apples and oranges are fruits, one
> of them is a better fruit than the other.
>
> Totally meaningless.

Both Java and C++ implement iterators over containters, and I think Java
containers are better implemented because...

The because part is what Erik was asking James about.

On Thu, 03 Apr 2008 16:12:59 -0500, Razii wrote:

> On Thu, 03 Apr 2008 21:03:29 GMT, Erik Wikström
> <Erik-wikstrom@telia.com> wrote:
>
>>Relevance?
>
> You have Iterators only when you have containers, like map or vector

No, you don't. I even use custom iterators for a lot more than
simple containers.

--
OU

Lloyd Bonafide writes:

> Sam <sam@email-scan.com> wrote in
> news:cone.1207306990.975400.1548.500@commodore.ema il-scan.com:
>
>> James Kanze writes:
>
>>> No. You're not comparing things in an absolute. If you call
>>> something an "iterator", it is because it fulfills a specific
>>> purpose. Implicit in the statement is that "Java iterators are
>>> better iterators than C++ iterators". Sort of like "oranges are
>>> a better source of vitamin C than apples".
>>
>> Except that there is no common denominator between Java and C++
>> iterators that can be used as a measuring stick. A better analogy
>> would be saying that because both apples and oranges are fruits, one
>> of them is a better fruit than the other.
>>
>> Totally meaningless.
>
> Both Java and C++ implement iterators over containters, and I think Java
> containers are better implemented because...

Before you can make that argument, you need to define what "better" means.
And, what "better" might mean to you, in this context, may not necessarily
mean the same thing to someone else, who uses a different definition of
"better".

For example, I happen to believe that C++'s iterators are "better", and I
happen to believe that they're better for the same reason it's argued that
Java's java.lang.Iterator is "better". The argument -- that you carry around
one object in Java, versus two objects in C++ (the beginning and the ending
iterator) -- and that because of this Java is better, is full of crap.

Only if your pristine fingers are too tired to type a few extra keywords,
and only your brain lacks the capacity to keep track of two things at the
same time, only then I would perhaps concede that Java Iterator
implementation is better. In terms of speed, performance, and efficiency,
C++ spanks the monkey out of Java's iterators for most use cases.

What the Java fan club fails to comprehend is that each iteration, in Java,
involves two virtual function calls: hasNext() and next(), while equivalent
C++ code is likely to involve more than a pair of CPU instructions:
increment and comparison, since the C++ generated code is likely to inline
and keep both iterators in registers (most C++ STL iterators usually get
optimized into nothing more than glorified pointers). In the worst case, a
C++ iterator would be a basic, no-frills object, which would incur only a
slightly bigger overhead than a direct pointer.

Meanwhile, since all Java methods are virtual, unless explicitly specified
otherwise; and I'm rather skeptical that even modern Java VMs will be able
to optimize away the required virtual function calls, one for each method:
hasNext(), and next(), on each iteration.

What you actually have, in terms of Java iterators, is something that in C++
would be equivalent to:

class Iterator {

public:
virtual Iterator *next()=0;
virtual bool hasNext()=0;
};

I'm ignoring an obvious issue here with memory allocation. When you factor
in the fact that, with most Java iterators, their next() method has to
allocate another instance of an Iterator object, and that Java's famous VM
has to keep track of references to each instance of every Iterator object
that gets instantiated, and garbage-collect it, from where I'm standing,
anyone who claims that Java implements iteration better than C++, from a
practical standpoint, are out of their freaking skulls.

So, really, for the same reasons that it's argued that Java's iterator
implementation is "better", I am going to argue that when you actually
examine what has to happen, you have no choice but to reach a completely
opposite conclusion, if you want to be intellectually honest about it. I
just can't accept that modern Java VMs, with all their JIT wizardly, can
optimize all this bloat away; especially since Java iterators are defined
mostly as interface objects, and all containers subclass the iterator
interface, and implement whatever next() and hasNext() means to them. That's
what they must do, there's just no way around it, and I see slim-to-none
chance that at runtime you can avoid two virtual function calls for each
loop iteration, and having to deal with instantiating a brand new iterator
object on each loop iteration, and having to deal with garbage-collecting
the entire mess, when you're done.

Yeah, that's MUCH "better" than just keeping two words in a pair of
registers, then incrementing the first one and comparing it against the
second one, on each loop iteration.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBH9qZpx9p3GYHlUOIRAqzWAJ9YKPtPBYdM9ijclEIbmf t0FHWxagCfVlSq
FSnYx9TJRuU/MUvvAzxyxAo=
=8WEa
-----END PGP SIGNATURE-----

Sam <sam@email-scan.com> wrote in
news:cone.1207346793.375814.4939.500@commodore.ema il-scan.com:

> Lloyd Bonafide writes:
>
>> Sam <sam@email-scan.com> wrote in
>> news:cone.1207306990.975400.1548.500@commodore.ema il-scan.com:
>>
>>> James Kanze writes:
>>
>>>> No. You're not comparing things in an absolute. If you call
>>>> something an "iterator", it is because it fulfills a specific
>>>> purpose. Implicit in the statement is that "Java iterators are
>>>> better iterators than C++ iterators". Sort of like "oranges are
>>>> a better source of vitamin C than apples".
>>>
>>> Except that there is no common denominator between Java and C++
>>> iterators that can be used as a measuring stick. A better analogy
>>> would be saying that because both apples and oranges are fruits, one
>>> of them is a better fruit than the other.
>>>
>>> Totally meaningless.
>>
>> Both Java and C++ implement iterators over containters, and I think
>> Java containers are better implemented because...
>
> Before you can make that argument, you need to define what "better"
> means. And, what "better" might mean to you, in this context, may not
> necessarily mean the same thing to someone else, who uses a different
> definition of "better".

Maybe it will you to preface each post, in your mind, with "in my
opinion". James' opinion is that Java's iterator implementation is
superior to C++, and Erik wants to know why he thinks that. No need to
get your shorts in a wad.

<remainder of cowboy programmer bullshit elided>

Lloyd Bonafide writes:

> Sam <sam@email-scan.com> wrote in
> news:cone.1207346793.375814.4939.500@commodore.ema il-scan.com:
>
>> Lloyd Bonafide writes:
>>
>>> Sam <sam@email-scan.com> wrote in
>>> news:cone.1207306990.975400.1548.500@commodore.ema il-scan.com:
>>>
>>>> James Kanze writes:
>>>
>>>>> No. You're not comparing things in an absolute. If you call
>>>>> something an "iterator", it is because it fulfills a specific
>>>>> purpose. Implicit in the statement is that "Java iterators are
>>>>> better iterators than C++ iterators". Sort of like "oranges are
>>>>> a better source of vitamin C than apples".
>>>>
>>>> Except that there is no common denominator between Java and C++
>>>> iterators that can be used as a measuring stick. A better analogy
>>>> would be saying that because both apples and oranges are fruits, one
>>>> of them is a better fruit than the other.
>>>>
>>>> Totally meaningless.
>>>
>>> Both Java and C++ implement iterators over containters, and I think
>>> Java containers are better implemented because...
>>
>> Before you can make that argument, you need to define what "better"
>> means. And, what "better" might mean to you, in this context, may not
>> necessarily mean the same thing to someone else, who uses a different
>> definition of "better".
>
> Maybe it will you to preface each post, in your mind, with "in my
> opinion". James' opinion is that Java's iterator implementation is
> superior to C++, and Erik wants to know why he thinks that. No need to
> get your shorts in a wad.
>
> <remainder of cowboy programmer bullshit elided>

I note that you falied to elucidate a counterargument to the lengthy, and
detailed, technical discussion of the relative merits of Java and C++
iterators.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD4DBQBH9rRnx9p3GYHlUOIRAgWUAJYy9l2hhGOeIGD3y1QAQN aXzp0QAKCAesSG
oyRevqiQTdn7OjneaUKRBw==
=Dz7x
-----END PGP SIGNATURE-----

> What the Java fan club fails to comprehend is that each iteration, in Java,
> involves two virtual function calls: hasNext() and next(), while equivalent
> C++ code is likely to involve more than a pair of CPU instructions:
> increment and comparison, since the C++ generated code is likely to inline

What makes you think that "hasNext" and "next", if implemented in C++,
would not be expressed by "a pair of CPU instructions" - compare and
increment?

> and keep both iterators in registers (most C++ STL iterators usually get
> optimized into nothing more than glorified pointers).

As could be Java style iterators implemented in C++. Just consider

template <class T>
struct Iter {
T::iterator ptr;
T::iterator end;

bool hasNext() const { return ptr != end; }
void next() { ptr++; }
};

Your arguments are completely moot.

> Meanwhile, since all Java methods are virtual, unless explicitly specified
> otherwise; and I'm rather skeptical that even modern Java VMs will be able
> to optimize away the required virtual function calls, one for each method:
> hasNext(), and next(), on each iteration.

What that has to do with iterator concept?

Mirek