A Question about std::list

[JustSomeGuy]

When you iterate through a list of objects in a list.

list<object> mylist;
list<object>::const_iterator iter;
object ob;

for (iter=mylist.begin(); iter != mylist.end(); ++iter)
{
ob = *iter;
ob.value = 10;
}

So here I am iterating through the list
but is the statement ob = *iter making a copy of an element in my list?
or am I getting a refrence to an element in mylist?
It seems inefficient to me to make a copy of an element in the list, when
all I really want is a pointer to the object or a refrence to it so that
I can modify it...

I assume that iter->value is not going to work...

Comments?

 

[Kai-Uwe Bux]

When you iterate through a list of objects in a list.

list<object> mylist;
list<object>::const_iterator iter;
object ob;

for (iter=mylist.begin(); iter != mylist.end(); ++iter)
{
ob = *iter;

You get a copy;

ob.value = 10;

You modify the copy. Now, you probably want to insert:

*iter = ob;

}

So here I am iterating through the list
but is the statement ob = *iter making a copy of an element in my list?
or am I getting a refrence to an element in mylist?

It seems inefficient to me to make a copy of an element in the list, when
all I really want is a pointer to the object or a refrence to it so that
I can modify it...

Yep, that would be inefficient.

I assume that iter->value is not going to work...

You did not actually try, did you?


Best

Kai-Uwe

 

[John Harrison]

When you iterate through a list of objects in a list.

list<object> mylist;
list<object>::const_iterator iter;
object ob;

for (iter=mylist.begin(); iter != mylist.end(); ++iter)
{
ob = *iter;
ob.value = 10;
}

So here I am iterating through the list
but is the statement ob = *iter making a copy of an element in my list?
or am I getting a refrence to an element in mylist?
It seems inefficient to me to make a copy of an element in the list, when
all I really want is a pointer to the object or a refrence to it so that
I can modify it...

I assume that iter->value is not going to work...

Comments?

Curious, if you want to modify the list why did you use a const_iterator? If
you want a pointer or reference to an element in the list, why didn't you
just declare one?

list<object>::iterator iter;
object& ref;
object* ptr;

for (iter=mylist.begin(); iter != mylist.end(); ++iter)
{
ref = *iter;
ptr = &*iter;
ref.value = 10;
ptr->value = 10;

But as Kai-Uwe said simply 'iter->value = 10' works provided you use an
iterator not a const iterator.

john

 

[David Harmon]

On Fri, 18 Jun 2004 06:53:44 +0100 in comp.lang.c++, "John Harrison"

object& ref;

References must be initialized to refer to an object.

ref = *iter;

References may not be reseated after initialization.
Assignment assigns to the underlying object.

for (iter=mylist.begin(); iter != mylist.end(); ++iter)
{
object &ref(*iter);
ref.value = 10;
}

 

[John Harrison]

On Fri, 18 Jun 2004 06:53:44 +0100 in comp.lang.c++, "John Harrison"


References must be initialized to refer to an object.


References may not be reseated after initialization.
Assignment assigns to the underlying object.

for (iter=mylist.begin(); iter != mylist.end(); ++iter)
{
object &ref(*iter);
ref.value = 10;
}

Yes, my mistake.

john

 

[JustSomeGuy]

Yes, my mistake.

john

Is there any speed difference between the refrence vs the pointer?

 

[JustSomeGuy]

Curious, if you want to modify the list why did you use a const_iterator? If
you want a pointer or reference to an element in the list, why didn't you
just declare one?

At the risk of sounding like a novice... uhmmm... I didn't know there was
any other type of iterator but a const_iterator... doh!

 

[JustSomeGuy]

Curious, if you want to modify the list why did you use a const_iterator? If
you want a pointer or reference to an element in the list, why didn't you
just declare one?

this doesn't want to compile....

class image : public std::list<element>
{
element getElement(key k) const
{
image::iterator iter;
for (iter=begin(); iter != end(); ++iter)
{
element &elem(*iter);
if (key == k)
{
return(elem);
}
}
throw("Not found");
}


I think the reason this isn't working is due to the const declaration of the
method.
So what am I to do?

 

[David Harmon]

On Fri, 18 Jun 2004 11:26:12 -0600 in comp.lang.c++, JustSomeGuy

Is there any speed difference between the refrence vs the pointer?

Probably none. Only actual measurement can tell for sure.

 

[John Harrison]

this doesn't want to compile....

class image : public std::list<element>
{
element getElement(key k) const
{
image::iterator iter;
for (iter=begin(); iter != end(); ++iter)
{
element &elem(*iter);
if (key == k)
{
return(elem);
}
}
throw("Not found");
}


I think the reason this isn't working is due to the const declaration of the
method.
So what am I to do?

const iterators and const references

class image : public std::list<element>
{
element getElement(key k) const
{
image::const_iterator iter;
for (iter=begin(); iter != end(); ++iter)
{
const element &elem(*iter);
if (key == k)
{
return(elem);
}
}
throw("Not found");
}

That's the thing about const, it's contagious. Start using it one place and
it ends up everywhere.

john

 

[Ronald Landheer-Cieslak]

[snip OPs post..]

That's the thing about const, it's contagious. Start using it one place and
it ends up everywhere.

which is also the nice thing about const, IMHO..

rlc

 

[John]

On Fri, 18 Jun 2004 06:53:44 +0100 in comp.lang.c++, "John Harrison"


References must be initialized to refer to an object.

Could you please explain why?

References may not be reseated after initialization.
Assignment assigns to the underlying object.

What does it mean?

Thanks a lot.

John

 

[John Harrison]

David Harmon <[email protected]> wrote in message

Could you please explain why?

Because that's what the language is. An uninitialised reference would be
completely useless (see below).

What does it mean?

int a = 1;
int b = 2;
int& r = a; // r initialised to refer to a
r = 3; // now a equals 3
r = b; // what does this do?

There are two ways of interpreting 'r = b', you could say that it makes r
refer to b, or you could say that is assigns the value of b to a (because r
refers to a). The latter is correct, that is what people mean when they say
references cannot be reseated.

john

 

[John]

Because that's what the language is. An uninitialised reference would be
completely useless (see below).


int a = 1;
int b = 2;
int& r = a; // r initialised to refer to a
r = 3; // now a equals 3
r = b; // what does this do?

There are two ways of interpreting 'r = b', you could say that it makes r
refer to b, or you could say that is assigns the value of b to a (because r
refers to a). The latter is correct, that is what people mean when they say
references cannot be reseated.

john

Thanks a lot.
Can I do this?

int a = 1;
int b = 2;
int& r = a; // r initialised to refer to a
r = 3; // now a equals 3
r = &b; // Is this correct?

John

 

[Richard Herring]

Thanks a lot.
Can I do this?

int a = 1;
int b = 2;
int& r = a; // r initialised to refer to a

From now on, r "is" a, and this association can't be changed.

r = 3; // now a equals 3
r = &b; // Is this correct?

No. Anything beginning "r =" is an assignment to what r references,
regardless of what is on the right of the = sign. It *never* changes the
association between r and a.

So you're attempting to store the address of b in what r references,
which is a. Since a isn't a pointer-to-int, you can't.

 

[Old Wolf]

const iterators and const references

class image : public std::list<element>
{
element getElement(key k) const

'key' must be a typename, if this is to compile...

{
image::const_iterator iter;
for (iter=begin(); iter != end(); ++iter)
{
const element &elem(*iter);
if (key == k)

.... so this won't

{
return(elem);
}
}
throw("Not found");
}

That's the thing about const, it's contagious. Start using it one place and
it ends up everywhere.

Or was this meant to be pseudocode?

 

[JustSomeGuy]

'key' must be a typename, if this is to compile...


... so this won't


Or was this meant to be pseudocode?

Yes it was code written directly into the news poster not cut and past from
a compiler.
There is an error here where key was meant to be iter->key or iter.key

 

[John]

From now on, r "is" a, and this association can't be changed.


No. Anything beginning "r =" is an assignment to what r references,
regardless of what is on the right of the = sign. It *never* changes the
association between r and a.

So you're attempting to store the address of b in what r references,
which is a. Since a isn't a pointer-to-int, you can't.

Thanks. How about call-by-reference?
Below is an example:

void function1(){

std::vector <int*> v1;
.....
for (int i = 0; i < 10; i++){
function2(v1); //function2 is called to bring value back to v1.
//process v1.
.....
}
}

void function2(std::vector <int*> &v2){
//Assign value to v2.
.....
}

Is there any problem with above code?

Thanks a lot.

John.

 

[John]

From now on, r "is" a, and this association can't be changed.


No. Anything beginning "r =" is an assignment to what r references,
regardless of what is on the right of the = sign. It *never* changes the
association between r and a.

So you're attempting to store the address of b in what r references,
which is a. Since a isn't a pointer-to-int, you can't.

Thanks. How about call-by-reference?
Below is an example:

void function1(){

std::vector <int*> v1;
.....
for (int i = 0; i < 10; i++){
function2(v1); //function2 is called to bring value back to v1.
//process v1.
.....
}
}

void function2(std::vector <int*> &v2){
v2.clear(); //Erase old value stored in v1. Is this correct?
//Assign value to v2.
.....
}

Is there any problem with above code?

Thanks a lot.

John.

( I add one line to function2 of my OP. So I post it again.)

 

[John Harrison]

Thanks. How about call-by-reference?
Below is an example:

void function1(){

std::vector <int*> v1;
.....
for (int i = 0; i < 10; i++){
function2(v1); //function2 is called to bring value back to v1.
//process v1.
.....
}
}

void function2(std::vector <int*> &v2){
v2.clear(); //Erase old value stored in v1. Is this correct?
//Assign value to v2.
.....
}

Is there any problem with above code?

It's fine, why shouldn't it be? Do you think it contradicts something that
Richard or myself have already said? If so what? The rule about not being
able to reseat a reference when it has been initialised still applies.
Confused.

john