STL map weird behavior

[Clint Weisbrod]

All,

I'm creating an STL map object like this:

map<double, stringmyMap;

I add a few items to the map using the [] operator.

If I iterate over the map like:

map<double, string>::iterat or it, itLast;
for (it = myMap.begin(); it != myMap.end(); ++it)
{
itLast = it;
}

Then itLast should reference the last item in the map, (the item with
largest key). This works fine. My problem is if I do the following:

map<double, string>::iterat or itLast2 = myMap.end();
--itLast2;

Then itLast2 does not reference the same item in the map. In fact, it
always ends up referencing the first item (with smallest key)!

Now I thought that using a double type key would be a problem, but
after researching this a bit, using double types (although probably
not a good idea) should work the way I expect.

Has anyone come across a similar problem?

Thanks everyone.

Clint Weisbrod.

[Andrew Koenig]

Re: STL map weird behavior

"Clint Weisbrod" <clintweisbrod@ cogeco.cawrote in message
news:36ae5985-d6ab-40fb-99d7-3f489a4d778b@c3 0g2000hsa.googl egroups.com...

If I iterate over the map like:
>
map<double, string>::iterat or it, itLast;
for (it = myMap.begin(); it != myMap.end(); ++it)
{
itLast = it;
}
>
Then itLast should reference the last item in the map, (the item with
largest key).

Unless the map is empty, in which case the effect is undefined.

My problem is if I do the following:
>
map<double, string>::iterat or itLast2 = myMap.end();
--itLast2;
>
Then itLast2 does not reference the same item in the map

Again, if the map is empty, the effect is undefined.

In fact, it
always ends up referencing the first item (with smallest key)!

I'm skeptical. How about showing us a complete program that misbehaves as
you describe?

[Clint Weisbrod]

Re: STL map weird behavior

I'm skeptical. How about showing us a complete program that misbehaves as

you describe?

I'd be skeptical, too. Unfortunately, the code where this is happening
is quite large. Of course, I've written a small stand-alone program
and the STL behaves the way I expect. So one would think my large
application is at fault somehow. Just not able to see anything
obviously wrong.

BTW, this is happening on Mac OS X Leopard using Xcode 3.0. Wish I had
a 10.4 (Tiger) machine to try. Microsoft's VC++ 2005 compiler gives me
the results I expect.

Thanks for the response.

Clint.

[Ron Natalie]

Re: STL map weird behavior

Clint Weisbrod wrote:

>I'm skeptical. How about showing us a complete program that misbehaves as
>you describe?

>
I'd be skeptical, too. Unfortunately, the code where this is happening
is quite large. Of course, I've written a small stand-alone program
and the STL behaves the way I expect. So one would think my large
application is at fault somehow. Just not able to see anything
obviously wrong.

Check the copy constructors and assignment operators of your classes.

[Jim Langston]

Re: STL map weird behavior

"Clint Weisbrod" <clintweisbrod@ cogeco.cawrote in message
news:d2829b22-c47d-4fda-b306-3d19f645cf46@w3 4g2000hsg.googl egroups.com...

>I'm skeptical. How about showing us a complete program that misbehaves
>as
>you describe?

>
I'd be skeptical, too. Unfortunately, the code where this is happening
is quite large. Of course, I've written a small stand-alone program
and the STL behaves the way I expect. So one would think my large
application is at fault somehow. Just not able to see anything
obviously wrong.

At the place you are observing this strange value for end()--, try also
looking at begin() and see if they are the same value. I would suspect that
if you are observing this behavior then begin() will be showing the largest
value. Perhaps your map's sort index is wrong or something. You might also
want to try to dump the value of the keys at the point this is happening and
see if you find anything weird.

BTW, this is happening on Mac OS X Leopard using Xcode 3.0. Wish I had
a 10.4 (Tiger) machine to try. Microsoft's VC++ 2005 compiler gives me
the results I expect.
>
Thanks for the response.
>
Clint.