Problem passing and accessing a vector

[The_Mezentine]

Okay, so this feels like a really rudimentary question, but its driving me nuts. The following code compiles and runs fine:

Code: [Select]


std::vector<SolidObject *> bricks(6);
for(int i = 0; i <bricks.size(); i++){
App.Draw(bricks[i]->Sprite);
}


but when I try to work with it inside a method I get errors:

Code: [Select]


void System::Draw(sf::RenderWindow &App, std::vector<SolidObject*> &Mobile()){
for(int i = 0; i < Mobile.size(); i++){
App.Draw(Mobile[i]->Sprite);
}


The errors I get are:

Code: [Select]

error C2228: left of '.size' must have class/struct/union
1>          type is 'std::vector<_Ty> &(__cdecl *)(void)'
1>          with
1>          [
1>              _Ty=SolidObject *
1>          ]

 error C2109: subscript requires array or pointer type

error C2227: left of '->Sprite' must point to class/struct/union/generic type


I feel like there's something really obvious here that as a novice programmer I'm just not seeing.
Oh, and I use a vector of pointers because SolidObject is a generic class from which I derive many different types that I want to store all together.

Any help is greatly appreciated.

[Laurent]

void System::Draw(sf::RenderWindow &App, std::vector<SolidObject*> &Mobile())

By the way, Mobile should be a const reference.

[The_Mezentine]

void System::Draw(sf::RenderWindow &App, std::vector<SolidObject*> &Mobile())

By the way, Mobile should be a const reference.

Will removing the parenthesis help? I'm pretty sure I tried that, but I'll give it a shot.
Also is "Mobile should be const" a hard rule, or a good programming guideline? Because I think there are times where I'll want to iterate through the entire vector and change the properties of every object inside it, including adding or deleting objects.

EDIT: Wow, I could have sworn I added and removes those parentheses like ten times last night and it never worked, but this time it did. Maybe I had other errors.

What you said about const got me thinking though. My current plan is to use vectors to handle the organization in any "game" I make. Is that a bad idea?

[Laurent]

"const" is just how you pass the variable to the function, it applies only inside the function. Each function can decide or not to use const.

The rule is: if the function modifies the variable, pass a reference; if it doesn't modify the variable (like your draw function), pass a const reference.

[The_Mezentine]

"const" is just how you pass the variable to the function, it applies only inside the function. Each function can decide or not to use const.

The rule is: if the function modifies the variable, pass a reference; if it doesn't modify the variable (like your draw function), pass a const reference.

Okay, yeah, that's what I thought. Thanks!

EDIT: Okay, I have no idea if this is related but I made that change, tried to recompile and I got a

Code: [Select]

0xC0000005: Access violation reading location 0x00000030. error. Visual C++ highlights this line:

Code: [Select]


const Matrix3& Drawable::GetMatrix() const
{
    // First recompute it if needed
   if (myNeedUpdate) //this line
    {
        myMatrix.SetFromTransformations(myCenter, myPosition, myRotation, myScale);
        myNeedUpdate = false;
    }

    return myMatrix;

in drawable.cpp

[Nexus]

The following code compiles and runs fine:

Code: [Select]

std::vector<SolidObject *> bricks(6);
for(int i = 0; i <bricks.size(); i++){
App.Draw(bricks[i]->Sprite);
}


I don't think so. You create a container full of null pointers; dereferencing them is undefined behavior (but will instantly abort the program on most environments). Your error message refers to an address very close to 0, which often indicates null pointers.

Just use a std::vector<SolidObject> and initialize the elements correctly. If you really need pointers (because of polymorphism), allocate memory for them. But generally, I would prefer different containers with static types, i.e. a std::vector<Brick> etc. This also saves you from case differentiations at runtime.

[The_Mezentine]

The following code compiles and runs fine:

Code: [Select]

std::vector<SolidObject *> bricks(6);
for(int i = 0; i <bricks.size(); i++){
App.Draw(bricks[i]->Sprite);
}


I don't think so. You create a container full of null pointers; dereferencing them is undefined behavior (but will instantly abort the program on most environments). Your error message refers to an address very close to 0, which often indicates null pointers.

Just use a std::vector<SolidObject> and initialize the elements correctly. If you really need pointers (because of polymorphism), allocate memory for them. But generally, I would prefer different containers with static types, i.e. a std::vector<Brick> etc. This also saves you from case differentiations at runtime.

Er, my bad, I omitted the code there where I loop through and fill the vector with new SolidObjects. The reason why I'm using pointers and polymorphism is so that I can (hopefully) efficiently handle collision detection between objects. That is to say if I have a moving object and I want to check if it collides with something else instead of using something like a QuadTree to break things down spatially I can just scan through a vector of all collidable objects for proximity as determined by the Sprite.position member.

Also I reworked things to work with an iterator, so my current code looks like:

Code: [Select]


void System::Draw(sf::RenderWindow &App, std::vector<SolidObject*> &Mobile, std::vector<SolidObject*> &Immobile){
for(std::vector<SolidObject*>::iterator it = Mobile.begin(); it != Mobile.end(); it++){
App.Draw((*it)->Sprite); //make note of how this works
      }
}


[Groogy]

Still what Nexus said stands, somewhere you are working with a NULL pointer like if it were a valid pointer. Unless you meant that you omitted implementing that.

Not much we can do from here. I could ask you to give us your callstack and perhaps the code of the functions in that chain.

[Nexus]

I think this boils down to the usual request: Show us a minimal and complete example that still reproduces the problem. Remove all the code that is irrelevant for the error.