471,086 Members | 1,202 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,086 software developers and data experts.

iterator error

windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?

Apr 6 '07 #1
22 1439
乐乐大天师 wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined. You need to either look at the code
in the debugger to see what's going on or ask in the newsgroup
dedicated to your implementation (microsoft.public.vc.* family
of newsgroups come to mind).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 6 '07 #2
乐乐大天师 wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
That all depends on what the type of a std::map<int, int>::iterator is
and whether it cam be initialised by or compared to an int. If it lacks
a public constructor, the assignment is illegal and if it lacks an
operator==(int), the comparison is illegal.

--
Ian Collins.
Apr 6 '07 #3
Ian Collins wrote:
乐乐大天师 wrote:
>windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
That all depends on what the type of a std::map<int, int>::iterator is
and whether it cam be initialised by or compared to an int. If it
lacks a public constructor, the assignment is illegal and if it lacks
an operator==(int), the comparison is illegal.
It's actually operator!=(int) we're discussing here... Unless you think
they are related somehow...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 6 '07 #4
Victor Bazarov wrote:
Ian Collins wrote:
>>
That all depends on what the type of a std::map<int, int>::iterator is
and whether it cam be initialised by or compared to an int. If it
lacks a public constructor, the assignment is illegal and if it lacks
an operator==(int), the comparison is illegal.


It's actually operator!=(int) we're discussing here... Unless you think
they are related somehow...
Typo.

--
Ian Collins.
Apr 6 '07 #5
"乐乐大天师" <ch*********@gmail.comwrote in message
news:11*********************@b75g2000hsg.googlegro ups.com...
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
Read the other's comments. You are trying to compare an iterator and an
integer. On some (most?) implementations it = 0 would probably be invalid
also. The correct usage is to initialize them with .begin() or .rbegin() or
some iterator value. For example:

int main()
{
std::map<int, intMyMap;
std::map<int, int>::iterator it = MyMap.begin();
// code
}

persontally, I normally use iterators mostly in for loops to iterate through
a container (vector or map) or to get a pointer to a newly inserted member.
Such as:

typedef std::map<int, intIntMap;
IntMap MyMap;
// fill MyMap
for ( IntMap::iterator it = MyMap.begin(); it != MyMap.end(); ++it )
std::cout << it->first << "-" << it->second << "\n";
Apr 6 '07 #6
乐乐大天师 wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
Repeat after me. Iterators are NOT POINTERS. Again. Iterators are NOT
POINTERS.

There is no such thing as a "0" or NULL iterator. Any valid iterator
must refer to a container.

Apr 6 '07 #7
On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
乐乐大天师 wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;
int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.
It's not even implementation-defined, it's undefined.

Most good implementations will not compile either of the above
lines.
You need to either look at the code
in the debugger to see what's going on or ask in the newsgroup
dedicated to your implementation (microsoft.public.vc.* family
of newsgroups come to mind).
Actually, he needs to change his code. It might help if he
explained what he is trying to accomplish.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orient閑 objet/
Beratung in objektorientierter Datenverarbeitung
9 place S閙ard, 78210 St.-Cyr-l'蒫ole, France, +33 (0)1 30 23 00 34

Apr 6 '07 #8
James Kanze wrote:
On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>乐乐大天师 wrote:
>>windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;
int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
>The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.

It's not even implementation-defined, it's undefined.
Strictly speaking without an implementation it wouldn't even exist and
therefore would not compile
>
Most good implementations will not compile either of the above
lines.
>You need to either look at the code
in the debugger to see what's going on or ask in the newsgroup
dedicated to your implementation (microsoft.public.vc.* family
of newsgroups come to mind).

Actually, he needs to change his code. It might help if he
explained what he is trying to accomplish.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orient閑 objet/
Beratung in objektorientierter Datenverarbeitung
9 place S閙ard, 78210 St.-Cyr-l'蒫ole, France, +33 (0)1 30 23 00 34
I agree the code is somewhat dodgy and probably not portable

JB
Apr 6 '07 #9
red floyd wrote:
乐乐大天师 wrote:
>windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
Repeat after me. Iterators are NOT POINTERS. Again. Iterators are NOT
POINTERS.

There is no such thing as a "0" or NULL iterator. Any valid iterator
must refer to a container.
So what does the default constructor for an iterator refer to? Just
curious as a valid container may not yet exist

JB
Apr 6 '07 #10
James Kanze wrote:
On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>乐乐大天师 wrote:
>>windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;
>>int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
>The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.

It's not even implementation-defined, it's undefined.
Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 6 '07 #11
bnonaj wrote:
James Kanze wrote:
>On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>>乐乐大天师 wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------

#include <iostream>
#include <map>
using namespace std;
int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------

why it can be assign "0", but can't compare with "0"?
>>The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.

It's not even implementation-defined, it's undefined.
Strictly speaking without an implementation it wouldn't even exist and
therefore would not compile
Well, perhaps. But the issue underlying this subthread is the
application of the technical terms "undefined" and "implementation
defined" as defined by the C++ standard. "Undefined behavior" means that
the standard does not impose any requirements. "Implementation defined"
means that the standard requires the implementation to document its
behavior.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #12
Victor Bazarov wrote:
Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?
If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.
Apr 6 '07 #13
red floyd wrote:
>
Any valid iterator
must refer to a container.
Any valid iterator must refer to a sequence. Containers are one way of
producing sequences, but not the only way.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #14
bnonaj wrote:
So what does the default constructor for an iterator refer to?
The default constructor creates a singular iterator. The only
legitimate thing you can do with one is to assign a non-singular
iterator to it.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #15
Ron Natalie wrote:
Victor Bazarov wrote:
>Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?
If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.
You don't have to shout to get your point across, by the way.

And, what exactly *is* your point?
Apr 6 '07 #16
Pete Becker wrote:
red floyd wrote:
>Any valid iterator
must refer to a container.

Any valid iterator must refer to a sequence. Containers are one way of
producing sequences, but not the only way.
The standard defines it as something that peforms interations
over a container, stream, or streambuffer.

I suspect you are forgetting that the term SEQUENCE already has a
defined meaning in C++ as the subset of containers that include
vector, list, queue, dequeue, and stack.

In practice, an iterator is just a type that obeys the iterator
rules. It's quite possible to have a valid iterator that iterates
over just about anything including associative containers, plain
old arrays, and bizarre user defined types (we have our own
database iterators that are quite legal C++ iterators in their
own right).
Apr 6 '07 #17
Victor Bazarov wrote:
Ron Natalie wrote:
>Victor Bazarov wrote:
>>Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?
If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.

You don't have to shout to get your point across, by the way.
Wasn't shouting. Just trying to highlight the defined terms.
Netnews typopgraphy leaves a little to be desired.
And, what exactly *is* your point?
My point is answering your point. You seem to be saying
that it's not undefined behavior to compare something with
zero because of the possiblity that some implementation
may have defined behavior for that which in undefined.
Well that's fine for that implementation, but if isn't
defined by the standard or required to be implementation
defined, then in general it's still undefined behavior.

Apr 6 '07 #18
Ron Natalie wrote:
[..] You seem to be saying
that it's not undefined behavior to compare something with
zero because of the possiblity that some implementation
may have defined behavior for that which in undefined.
Yes. Exactly. The type for the 'std::map::iterator' is
implementation-defined. That means the implementation has to
document that type (and all its traits along with it). The
ability for an object of that type to be compared to 0 _is_
going to be described in the same *required* documentation.
Well that's fine for that implementation, but if isn't
defined by the standard or required to be implementation
defined, then in general it's still undefined behavior.
No, I think it's implementation-defined by *extension* of
the requirement that the type itself is implementation-defined.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 6 '07 #19
Ron Natalie wrote:
Pete Becker wrote:
>red floyd wrote:
>>Any valid iterator
must refer to a container.
Any valid iterator must refer to a sequence. Containers are one way of
producing sequences, but not the only way.
The standard defines it as something that peforms interations
over a container, stream, or streambuffer.
I couldn't find that definition. In fact, iterators are defined
operationally,
by the operations that they support.
I suspect you are forgetting that the term SEQUENCE already has a
defined meaning in C++ as the subset of containers that include
vector, list, queue, dequeue, and stack.
That's an unfortunate term, which should be "sequence container",
just as we have "associative container" and "unordered container." And
it's clear from the way I used it that I wasn't referring to a sequence
container, but to a sequence in its more ordinary sense.
>
In practice, an iterator is just a type that obeys the iterator
rules. It's quite possible to have a valid iterator that iterates
over just about anything including associative containers, plain
old arrays, and bizarre user defined types (we have our own
database iterators that are quite legal C++ iterators in their
own right).
Exactly.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #20
Pete Becker wrote:
Ron Natalie wrote:
>Pete Becker wrote:
>>red floyd wrote:
Any valid iterator
must refer to a container.

Any valid iterator must refer to a sequence. Containers are one way of
producing sequences, but not the only way.
The standard defines it as something that peforms interations
over a container, stream, or streambuffer.

I couldn't find that definition. In fact, iterators are defined
operationally,
by the operations that they support.
>I suspect you are forgetting that the term SEQUENCE already has a
defined meaning in C++ as the subset of containers that include
vector, list, queue, dequeue, and stack.

That's an unfortunate term, which should be "sequence container",
just as we have "associative container" and "unordered container." And
it's clear from the way I used it that I wasn't referring to a sequence
container, but to a sequence in its more ordinary sense.
>In practice, an iterator is just a type that obeys the iterator
rules. It's quite possible to have a valid iterator that iterates
over just about anything including associative containers, plain
old arrays, and bizarre user defined types (we have our own
database iterators that are quite legal C++ iterators in their
own right).

Exactly.
I should add, too, that many of the algorithms in the standard are
described as operating on sequences, but aren't restricted to sequence
containers.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #21
On Apr 6, 2:43 pm, Ron Natalie <r...@spamcop.netwrote:
Victor Bazarov wrote:
Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?
If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.
It can also be unspecified.

In this case, the standard pretty much says that anything you do
with the standard library that is not conform with the specified
requirements is undefined behavior.

--
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orient閑 objet/
Beratung in objektorientierter Datenverarbeitung
9 place S閙ard, 78210 St.-Cyr-l'蒫ole, France, +33 (0)1 30 23 00 34
Apr 6 '07 #22
On Apr 6, 1:59 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
James Kanze wrote:
On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
乐乐大天师 wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;
>int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.
It's not even implementation-defined, it's undefined.
Is it explicitly undefined (as in dereferencing a null pointer)?
Yes. The standard says that just about anything you do with the
library that isn't conform results in undefined behavior. There
are practically no requirements that e.g. a diagnostic be
emitted.

In practice, there's a lot of undefined behavior that will
either work, or result in a diagnostic, even if the standard
says it's undefined. The line `cout<<"ok!";' in the above
program, for example, is undefined behavior, since the code
fails to include the necessary header (<ostream>). But I can't
conceive of an implementation in which it either worked, or
failed to compile.
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined.
The type is implementation defined; most typically, it will be a
nested class or a typedef. The operations which it must support
are defined, however. And any attempt to do anything else with
it is undefined behavior.
Is it not conceivable that the type
might actually define comparison with 0?
The implementation might define it. That's one legal way of
handling undefined behavior. In the case of `cout<<"ok!"', for
example, both the g++ and the Dinkumware library define it; g++,
at least, has explicitly added code in <iostreamto make it
defined. And on my system, dereferencing a null pointer is
defined---the system guarantees an immediate core dump. But the
standard still says it is undefined, and I've used systems where
it could do some very strange things.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orient閑 objet/
Beratung in objektorientierter Datenverarbeitung
9 place S閙ard, 78210 St.-Cyr-l'蒫ole, France, +33 (0)1 30 23 00 34

Apr 6 '07 #23

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

38 posts views Thread by Grant Edwards | last post: by
3 posts views Thread by John Smith | last post: by
1 post views Thread by flopbucket | last post: by
5 posts views Thread by Bill Oliver | last post: by
1 post views Thread by atomik.fungus | last post: by
6 posts views Thread by antani | last post: by
5 posts views Thread by maverik | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.