STL map question

[brian]

Hello all,

First of all I am aware of the fact that my question is STL related.
However the comp.std.c++ group is moderated and I have no idea how long
it will take to be answered there. So, please, hold your fire.

And now the question:

Is there any special reason (performance, etc.) for using "(*i).second"
instead of "i->second"?

The example follows:

typedef std::map<...> table;

extern table t;
table::iterator i;
for (i=t.begin(); i!=t.end(); i++)
{
param = (*i).second;
...
}

Thanks.

 

[Ivan Vecerina]

First of all I am aware of the fact that my question is STL related.
However the comp.std.c++ group is moderated and I have no idea how long
it will take to be answered there. So, please, hold your fire.

All C++ questions are welcome here, no fire to be expected.

Is there any special reason (performance, etc.) for using "(*i).second"
instead of "i->second"?

No, most certainly not.
6-7 years ago, some were saying that (*i). may be more portable
that i-> , because of the inconsistency of some library
implementations - but this is history.
I see no rationale today for preferring (*i). over i->


hth-Ivan

 

[Jeff Flinn]

Hello all,

First of all I am aware of the fact that my question is STL related.
However the comp.std.c++ group is moderated and I have no idea how
long it will take to be answered there. So, please, hold your fire.

And now the question:

Is there any special reason (performance, etc.) for using
"(*i).second" instead of "i->second"?

No, just personal preference.

The example follows:

typedef std::map<...> table;

extern table t;
table::iterator i;
for (i=t.begin(); i!=t.end(); i++)

But there is a performance hit here using post increment. Use ++i instead
whenever possible.

Jeff Flinn

 

[Chris Croughton]

All C++ questions are welcome here, no fire to be expected.

No, most certainly not.
6-7 years ago, some were saying that (*i). may be more portable
that i-> , because of the inconsistency of some library
implementations - but this is history.
I see no rationale today for preferring (*i). over i->

Ah, thanks, I too remembered hearing about it but not why, I've used the
-> form in all of my C++ code for many years with no problems.

Chris C

 

[Ingo Nolden]

But there is a performance hit here using post increment. Use ++i instead
whenever possible.

I use pre increment when I want to make clear that post increment is not
what I need. And I don't think that the compiler will make any
diffderence in Release mode if I don't use the result.

Ingo

 

[brian]

Is there any special reason (performance, etc.) for using
"(*i).second"

No, most certainly not.
6-7 years ago, some were saying that (*i). may be more portable
that i-> , because of the inconsistency of some library
implementations - but this is history.
I see no rationale today for preferring (*i). over i->

Thank you.

 

[brian]

Is there any special reason (performance, etc.) for using

No, just personal preference.

Thank you.

But there is a performance hit here using post increment. Use ++i instead
whenever possible.

Isn't this a history?

 

[Ivan Vecerina]

Isn't this a history?

No, this remains an issue by design: the post-increment operator
has to create and return a new instance of the iterator.
It is typically implemented in terms of the pre-increment:
{ MyIteratorType result(*this); ++this; return result; }

For some types of iterators, the cost of creating this new
instance (result) can be canceled after inlining, but this
is often not the case.

 

[Ivan Vecerina]

{ MyIteratorType result(*this); ++this; return result; }

Of course this was actually: ++(*this)

 

[brian]

Well, and what about basic types like "int"?

int i;

Is there any difference (performance) between:

i++;

and

++i;

Thanks.

 

[Jeff Flinn]

Well, and what about basic types like "int"?

int i;

Is there any difference (performance) between:

i++;

and

++i;

Most compilers will optimize the temporary away for simple built-in types.
But why not be explicit in your coding? If you're not using the previous
value, don't refer to it in the first place.

Jeff Flinn

 

[brian]

Most compilers will optimize the temporary away for simple built-in
types.

But why not be explicit in your coding? If you're not using the previous
value, don't refer to it in the first place.

So, in other words it is still preferred using ++i instead of i++.
Example:
for (int i=0; i<10; ++i)
{
}
Correct?

 

[Jeff Flinn]

So, in other words it is still preferred using ++i instead of i++.
Example:
for (int i=0; i<10; ++i)
{
}
Correct?

Correct.

Jeff Flinn

 

[brian]

Most compilers will optimize the temporary away for simple built-in

Correct.

Thank you very much.