Difficulty accessing a member of a class from a list

[JS Lemming]

An array? That's soo..... I dunno.... I've always had trouble with these dang lists in the past and I'm determined to finally get them working.

Not really you'd still be using an std::list just accessing it like an array.

Oh really? I didn't know you could do that. I might have to use that.

[andrew]

Not really you'd still be using an std::list just accessing it like an array.

Oh really? I didn't know you could do that. I might have to use that.

Please excuse my ignorance, but as far as I know you can't access a linked list like an array. There's no guarantee that the elements in a list will share neighboring addresses in memory.

Under the hood the STL list should be working basically like in this link:
http://www.codeproject.com/KB/cpp/linked_list.aspx

I apologize if I'm wrong, but I'm pretty sure you can't access an element of a linked list with the [] operator.

[M_D_K]

Not really you'd still be using an std::list just accessing it like an array.

Oh really? I didn't know you could do that. I might have to use that.

Please excuse my ignorance, but as far as I know you can't access a linked list like an array. There's no guarantee that the elements in a list will share neighboring addresses in memory.

Under the hood the STL list should be working basically like in this link:
http://www.codeproject.com/KB/cpp/linked_list.aspx

I apologize if I'm wrong, but I'm pretty sure you can't access an element of a linked list with the [] operator.

Oops.
Yeah std::list doesn't have a [ ] operator. So yeah my bad.

But theres always std::vector

[qpHalcy0n]

std::list is a pretty literal interpretation of a textbook doubly linked list structure. An iterator is just a container that acts like a pointer which ensures identical operation across all standard complex types: vector, list, map..etc.

So if we presume an iterator as a pointer which marches along the list, then it is valid from a range list::begin() to list.end(). A linked list's memory locality is not guaranteed to be contiguous like an array is because memory for individual elements is allocated off the heap. Typically, every attempt is made to ensure that large allocations are contiguously allocated, however appending and removing elements from either side of the list would spell out retarded overhead from realloc calls on potentially large data sets. So a typical implementation of the [] operator (which is: baseptr + offset * sizeof(datum) ) is not possible in this case. Therefore std::list will not have that operator defined.

(All pseudocode)
So then in this case, since you're dealing with data as follows:
std::list<data*> myList; // Linked list of ptrs

Then the iterator's type becomes: data**
Since list.begin() returns &list.first then we can see how the return value becomes data** since data** = &data*;

So de-referencing the iterator simply yields the object that it references, which is of type data*.

[Arce]

I did...

Code: Select all

   gameStage->(*i)->x = 44;

Yeah, there's no way that'll work. =P

You're trying to dereference a member as it's own entity!

If we have Object O with member M, can we do this?

O.m=<value>? Yes.

How about O=<value>? If you've overloaded it, sure.

Now, try m=<value>. No, m is a member...edit: Eh, bad example, m could be static...Though you'd still need scope operator...I tried. ;P

So when you do

Code: Select all

gameStage->(*i)->x = 44; 

you're trying to dereference the iterator as though it's an entirely separate entity--so try it like this

Code: Select all

*(gameStage->i)->x = 44;

When that class is constructed it makes a hector and puts it in the list...

Code: Select all
#include "stage.h"
#include "hector.h"

stage::stage()
{
hector *dude = new hector;
stageObjects.push_back(dude);
}

EDIT: ^^ btw, does anyone know of a nicer way of doing that so it's all on one line... and not needing of dude?

Have you tried this:

Code: Select all

stageObjects.push_back((new hector));

?

[JS Lemming]

Informative