By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,190 Members | 811 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,190 IT Pros & Developers. It's quick & easy.

STL map question

P: n/a
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.

Jul 23 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
"brian" <br***********@yahoo.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
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
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Jul 23 '05 #2

P: n/a
brian wrote:
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
Jul 23 '05 #3

P: n/a
On Fri, 18 Feb 2005 13:18:24 +0100, Ivan Vecerina
<NO**********************************@vecerina.com > wrote:
"brian" <br***********@yahoo.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
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->


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
Jul 23 '05 #4

P: n/a
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
Jul 23 '05 #5

P: n/a
>> 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->

Thank you.

Jul 23 '05 #6

P: n/a
>> Is there any special reason (performance, etc.) for using
"(*i).second" instead of "i->second"? No, just personal preference.

Thank you.
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. Isn't this a history?

Jeff Flinn


Jul 23 '05 #7

P: n/a
"brian" <br***********@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
for (i=t.begin(); i!=t.end(); i++)


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

instead
whenever possible.

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.
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

Jul 23 '05 #8

P: n/a
"Ivan Vecerina" <NO**********************************@vecerina.com > wrote in
message news:cv**********@news.hispeed.ch...
{ MyIteratorType result(*this); ++this; return result; }

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

Jul 23 '05 #9

P: n/a
Well, and what about basic types like "int"?

int i;

Is there any difference (performance) between:

i++;

and

++i;

Thanks.

Jul 23 '05 #10

P: n/a
brian wrote:
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
Jul 23 '05 #11

P: n/a
> 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?

Jul 23 '05 #12

P: n/a
brian wrote:
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?


Correct.

Jeff Flinn
Jul 23 '05 #13

P: n/a
>>> 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?


Correct.

Thank you very much.

Jul 23 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.