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

In map iterator is there a difference between (*iter).second anditer->second?

P: n/a
I see that a lot of former in the code, and wonder if there is a
technical reason for that
Aug 19 '08 #1
Share this Question
Share on Google+
15 Replies


P: n/a

"puzzlecracker" <ir*********@gmail.comwrote in message
news:81**********************************@56g2000h sm.googlegroups.com...
>I see that a lot of former in the code, and wonder if there is a
technical reason for that
You're asking about language syntax, this is
not specific to map or iterators.

Given a pointer to a class or struct:

struct T
{
int member;
};

and a pointer to one of these structs:
T obj;
T *p(&obj);

The two expressions:

(*p).member

and

p->member

have exactly the same meaning.

The '->' form is 'shorthand' for the (*). form.

Why someone used the latter over the former I
don't know. Perhaps a 'style' issue, or possibly
that's what a code generator created.

-Mike


Aug 19 '08 #2

P: n/a
On Aug 19, 9:48*am, "Mike Wahler" <mkwah...@mkwahler.netwrote:
"puzzlecracker" <ironsel2...@gmail.comwrote in message

news:81**********************************@56g2000h sm.googlegroups.com...
I see that a lot of former in the code, and wonder if there is a
technical reason for that

You're asking about language syntax, this is
not specific to map or iterators.

Given a pointer to a class or struct:

struct T
{
* * int member;

};

and a pointer to one of these structs:
T obj;
T *p(&obj);

The two expressions:

(*p).member

and

p->member

have exactly the same meaning.

The '->' form is 'shorthand' for the (*). form.

Why someone used the latter over the former I
don't know. *Perhaps a 'style' issue, or possibly
that's what a code generator created.

-Mike
I believe Mayers mentioned something in regard to map or another
container the difference of two operators -- I don't recall it.

It's NOT the matter of style.
Aug 19 '08 #3

P: n/a
On 19 ago, 11:06, puzzlecracker <ironsel2...@gmail.comwrote:
On Aug 19, 9:48*am, "Mike Wahler" <mkwah...@mkwahler.netwrote:
"puzzlecracker" <ironsel2...@gmail.comwrote in message
news:81**********************************@56g2000h sm.googlegroups.com...
>I see that a lot of former in the code, and wonder if there is a
technical reason for that
You're asking about language syntax, this is
not specific to map or iterators.
Given a pointer to a class or struct:
struct T
{
* * int member;
};
and a pointer to one of these structs:
T obj;
T *p(&obj);
The two expressions:
(*p).member
and
p->member
have exactly the same meaning.
The '->' form is 'shorthand' for the (*). form.
Why someone used the latter over the former I
don't know. *Perhaps a 'style' issue, or possibly
that's what a code generator created.
-Mike

I believe Mayers mentioned something in regard to map or another
container the difference of two operators -- I don't recall it.

It's NOT the matter of style.
Hi.

There's no difference between the two of them. However, the following
note can be seen on the SGI documentation site for the STL:

"Defining operator-for iterators depends on a feature that is part
of the C++ language but that is not yet implemented by all C++
compilers. If your compiler does not yet support this feature, the
workaround is to use (*it).m instead of it->m."

This regards to some "old days". Today most compilers do provide such
a feature. Therefore, I agree with Mike that is probably a 'style'
issue.
--
Leandro T. C. Melo

Aug 19 '08 #4

P: n/a
"Mike Wahler" <mk******@mkwahler.netwrote in message
news:q7******************************@earthlink.co m...
You're asking about language syntax, this is
not specific to map or iterators.
Not quite.
Given a pointer to a class or struct:

struct T
{
int member;
};

and a pointer to one of these structs:
T obj;
T *p(&obj);

The two expressions:

(*p).member

and

p->member

have exactly the same meaning.
Yes, but the original question was about iterators, not pointers.

If you are defining an iterator, you are expected to define both operator->
and operator*. However, some pre-standard libraries did not do so
consistently. To cater to that inconsistently, early authors tended to
prefer (*p).mem to p->mem, because the former is more tolerant of library
sloppiness than the latter.

This kind of tension comes up all the time when one author uses software
written by another. It's one of those messy details that divides theory
from practice.
Aug 19 '08 #5

P: n/a

"Andrew Koenig" <ar*@acm.orgwrote in message
news:aJ*********************@bgtnsc05-news.ops.worldnet.att.net...
"Mike Wahler" <mk******@mkwahler.netwrote in message
news:q7******************************@earthlink.co m...
>You're asking about language syntax, this is
not specific to map or iterators.

Not quite.
>Given a pointer to a class or struct:

struct T
{
int member;
};

and a pointer to one of these structs:
T obj;
T *p(&obj);

The two expressions:

(*p).member

and

p->member

have exactly the same meaning.

Yes, but the original question was about iterators, not pointers.
Oops, you're right. Although iterators are supposed
to behave like pointers, they're not pointers.
>
If you are defining an iterator, you are expected to define both
operator-and operator*. However, some pre-standard libraries did not do
so consistently. To cater to that inconsistently, early authors tended to
prefer (*p).mem to p->mem, because the former is more tolerant of library
sloppiness than the latter.

This kind of tension comes up all the time when one author uses software
written by another. It's one of those messy details that divides theory
from practice.
Thanks for the correction and explanation.

And thanks for writing that great book (Accelerated C++).

-Mike
Aug 19 '08 #6

P: n/a
puzzlecracker <ir*********@gmail.comwrote:
I see that a lot of former in the code, and wonder if there is a
technical reason for that
There was this woman who always cut the end off of a ham before cooking
it.

"Why do you do that?" I asked.

"Because my mother always did."

When we asked her mother she said, "well that's the way my mother always
did it."

And when we asked *her* mother she said, "because the oven was too
small. I had to cut the end off of the ham so it would fit."

What you have discovered is much the same. Programmers don't have to use
(*iter).second anymore because the "oven is big enough now" but there is
ingrained habit that gets passed down from one to another without
complete understanding.

:-)
Aug 19 '08 #7

P: n/a
On Aug 19, 11:33*am, "Andrew Koenig" <a...@acm.orgwrote:
"Mike Wahler" <mkwah...@mkwahler.netwrote in message

news:q7******************************@earthlink.co m...
You're asking about language syntax, this is
not specific to map or iterators.

Not quite.
Given a pointer to a class or struct:
struct T
{
* *int member;
};
and a pointer to one of these structs:
T obj;
T *p(&obj);
The two expressions:
(*p).member
and
p->member
have exactly the same meaning.

Yes, but the original question was about iterators, not pointers.

If you are defining an iterator, you are expected to define both operator->
and operator*. *However, some pre-standard libraries did not do so
consistently. *To cater to that inconsistently, early authors tended to
prefer (*p).mem to p->mem, because the former is more tolerant of library
sloppiness than the latter.

This kind of tension comes up all the time when one author uses software
written by another. *It's one of those messy details that divides theory
from practice.
Sort of what Mayers said in regard to iterators and recommended on
using the older syntax.
Aug 19 '08 #8

P: n/a
Re: In map iterator is there a difference between (*iter).second and
iter->second?
"puzzlecracker" <ir*********@gmail.comwrote in message
news:81**********************************@56g2000h sm.googlegroups.com...
>I see that a lot of former in the code, and wonder if there is a
technical reason for that
Most people suggest the second form, iter->second, which I initially used.
But then I ran across this from some class I was developing:

#ifndef OBSERVABLE_H
#define OBSERVABLE_H

#include "Observer.h"
#include <set>

class Observable {
std::set<Observer*observers;
public:
virtual void addObserver(Observer& o) {
observers.insert(&o);
}
virtual void deleteObserver(Observer& o) {
observers.erase(&o);
}
virtual void deleteObservers() {
observers.clear();
}
virtual size_t countObservers() {
return observers.size();
}
virtual void notifyObservers(Argument* arg = NULL)
{
std::set<Observer*>::iterator it;
for(it = observers.begin(); it != observers.end(); it++)
(*it)->update(this, arg);
}
};

#endif

Look at the function virtual void notifyObservers(Argument* arg = NULL)
specifically at the line:
(*it)->update(this, arg);

When I first tried to code that I was trying to do:
it->->update(this, arg);
which, obviously, wouldn't compile. So I wound up with that format,
derefernce the iterator, then use the arrow operator. And I thought about
it, and dereferenceing the iterator would always work, where using the arrow
operator would usually work, but not always. So I determined that all code
working with iterators would be dereferecned instead of using the arrow
operator for consistancy. So a map would be
(*it).second
etc..

I know seeing (*it) in my code that I am dereferncing an iterator. In fact,
I reserve the variable it for a local iterator.

Other than that, there is no real difference, it comes down to personal
prefernce and whatever your workplace standards are. I figured on (*it)
because I could be consistant with it. Although it is said that consistancy
is the hobgoblin of little minds I still like being consistant if I can. If
that means I have a little mind, so be it.

Regards,

Little Minded Jim Langston

Aug 20 '08 #9

P: n/a
"Mike Wahler" <mk******@mkwahler.netwrites:
"puzzlecracker" <ir*********@gmail.comwrote in message
news:81**********************************@56g2000h sm.googlegroups.com...
>>I see that a lot of former in the code, and wonder if there is a
technical reason for that

You're asking about language syntax, this is
not specific to map or iterators.

Given a pointer to a class or struct:

struct T
{
int member;
};

and a pointer to one of these structs:
T obj;
T *p(&obj);

The two expressions:

(*p).member

and

p->member

have exactly the same meaning.

The '->' form is 'shorthand' for the (*). form.

Yes, but given a different class, they may be different:

#include <iostream>

class A {
public: int x;
};

class P {
public:
A a1;
A a2;

A& operator*(){ return(a1); }
A* operator->(){ return(&a2); }
};
using namespace std;

int main(void){
P p;
p.a1.x=1;
p.a2.x=2;
cout<<"p->x = "<<p->x<<" ; (*p).x = "<<(*p).x<<endl;
return(0);
}

/*
-*- mode: compilation; default-directory: "~/src/tests-c++/" -*-
Compilation started at Wed Aug 20 11:40:06

SRC="/home/pjb/src/tests-c++/memb.c++" ; EXE="memb" ; g++ -g3 -ggdb3 -o ${EXE} ${SRC} && ./${EXE} && echo status = $?
p->x = 2 ; (*p).x = 1
status = 0

Compilation finished at Wed Aug 20 11:40:07
*/

Why someone used the latter over the former I
don't know. Perhaps a 'style' issue, or possibly
that's what a code generator created.
Or perhaps they mean different things.
--
__Pascal Bourguignon__
Aug 20 '08 #10

P: n/a
pj*@informatimago.com (Pascal J. Bourguignon) wrote in
news:7c************@pbourguignon.anevia.com:
>
Yes, but given a different class, they may be different:

#include <iostream>

class A {
public: int x;
};

class P {
public:
A a1;
A a2;

A& operator*(){ return(a1); }
A* operator->(){ return(&a2); }
};
using namespace std;

int main(void){
P p;
p.a1.x=1;
p.a2.x=2;
cout<<"p->x = "<<p->x<<" ; (*p).x = "<<(*p).x<<endl;
return(0);
}
Sadly, this points out all the worst in operator overloading. operator
overloading is meant to allow user defined types to have the same semantics
as built-in types, not creative and unexpected usage such as this where the
reader of the code would be quite surprised to discover the difference. It
is much like defining operater + to add a1 + a1 wherease operator - adds a2
+ a2. Both legal, but definitely a bad idea from a maintenance POV. In
real life, code is maintened for years after the original author lost all
interest in it and it is best to code with those folks in mind.

joe
Aug 20 '08 #11

P: n/a
On 2008-08-19 09:28:59 -0400, puzzlecracker <ir*********@gmail.comsaid:
I see that a lot of former in the code, and wonder if there is a
technical reason for that
A few years ago some compilers had trouble with the second form.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Aug 21 '08 #12

P: n/a
Pete Becker wrote:
On 2008-08-19 09:28:59 -0400, puzzlecracker <ir*********@gmail.comsaid:
>I see that a lot of former in the code, and wonder if there is a
technical reason for that

A few years ago some compilers had trouble with the second form.
Out of curiosity, did you mean "libraries" (not defining operator->
appropriately) or really "compiler" in strict sense?

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.
Aug 21 '08 #13

P: n/a
On 2008-08-21 06:58:46 -0400, Gennaro Prota <gennaro/pr***@yahoo.comsaid:
Pete Becker wrote:
>On 2008-08-19 09:28:59 -0400, puzzlecracker <ir*********@gmail.comsaid:
>>I see that a lot of former in the code, and wonder if there is a
technical reason for that

A few years ago some compilers had trouble with the second form.

Out of curiosity, did you mean "libraries" (not defining operator->
appropriately) or really "compiler" in strict sense?
The former is a consequence of the latter.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Aug 21 '08 #14

P: n/a
Pete Becker wrote:
>>A few years ago some compilers had trouble with the second form.

Out of curiosity, did you mean "libraries" (not defining operator->
appropriately) or really "compiler" in strict sense?

The former is a consequence of the latter.
Gulp :-) In the sense that the compiler proper wasn't able to resolve
-and thus the library didn't overload it? If so, do you remember how
many years ago that was and with which compilers? (Just curious)

Thanks,
--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.
Aug 21 '08 #15

P: n/a
On 2008-08-21 10:09:52 -0400, Gennaro Prota <gennaro/pr***@yahoo.comsaid:
Pete Becker wrote:
>>>A few years ago some compilers had trouble with the second form.

Out of curiosity, did you mean "libraries" (not defining operator->
appropriately) or really "compiler" in strict sense?

The former is a consequence of the latter.

Gulp :-) In the sense that the compiler proper wasn't able to resolve
-and thus the library didn't overload it? If so, do you remember how
many years ago that was and with which compilers? (Just curious)
Quite some time ago.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Aug 21 '08 #16

This discussion thread is closed

Replies have been disabled for this discussion.