Access violation when reading a string.

Hey guys ! I just started a little project on the A* algorithm and got an access violation. I can't see what's wrong with my code =/

Here's the code:

Code:

std::string Map[] = {  
				 "cccccccccccccccc"
				 "cooooooooooooooc",
				 "cooooooocooooooc",
				 "cooooooocooooooc",
				 "coooosoocooooooc",
				 "cooooooocooooooc",
				 "cooooooooooceooc",
				 "cooooooooooooooc",
				 "cccccccccccccccc" };

struct Move
{
	Move() : f(0), g(0), h(0), x(0), y(0), parent(0) { };
	bool operator < (const Move& m) { return (f < m.f); }
	bool operator == (const Move& m) { return (x == m.x) && (y == m.y); }

	int f, g, h, x, y;
	Move* parent;
};

std::vector<Move> Open, Closed;

void FindPoint(Move* m, char c)
{
	for(int i = 1; i < Map[0].size() - 1; i++)
	{
		for(int j = 1; j < (9 - 1); j++)
		{
			if(Map[i][j] == c)
			{
				m->x = i;
				m->y = j;
				break;
			}
		}
	}
}

Where:

c = 's', i = 12, j = 1

This piece of code basically searches for the 's' character and changes the struct if it is found. Does anyone have an idea why this access violation happens ?

Thanks.

And what is Move* m?

Your loops are somewhat puzzling too.
What is that meant to mean?

Code:

	for(int j = 1; j < (9 - 1); j++)

By the way, std::string has a find method to look for a character.

I assume you're actually allocating space for 'm'?

You should define a copy constructor/assignment operator for your struct if you want to use it in a standard container.

Other than that, I don't see anything here that (by itself) would cause an access violation

Ahah, that "9 - 1" thing was like a note to myself. The map is 9 character high but the last line is inaccessible so instead of writing 8 I wrote 9 - 1 to make it obvious though I think I'd be better off just commenting it.

m is a pointer to an empty object passed to the function. Nothing flashy here. I'll try to use the find function, I didn't think about it.

Code:

int main()
{
	Move start;
	FindPoint(&start, 's');

	// ...
}

I added the copy constructor and assignment operator but the violation still won't go away =/ Meanwhile, I tried using std::find() but it returns an iterator to the element found and not an index to it. I'm not aware if substracting iterators is allowed though. It could lead to a trick like this:

Code:

std::string::iterator it = std::find(Map[i].begin(), Map[i].end(), c);
int index = it - Map[i].begin();

I take back what I said, you shouldn't really need to explicitly define an assignment operator or copy constructor here, sorry.

But I see the problem:

Code:

std::string Map[] = {  
				 "cccccccccccccccc"
				 "cooooooooooooooc",
//...

You're missing a comma

Ah ah, thanks for that ! I get the same violation access error though. Same values for c, i and j as well =/

JaWiB, I don't think those commas belong there.

I think it should be;

Code:

 string blah="this and that"
                    "and this too"
                    "and then this";

Above, looks like the OP's commas are trapped between quotes -

Originally Posted by JaWiB

You're missing a comma

Don't you just love preprocessor string concatenation?

I got the correct answer on another forum. I got i and j backwards. It had to be Map[j][i].

Still on the same project, I get another access violation (definitely not my day =P). I was just trying to remember something. I think I've read somewhere that pointing to an object into an STL container is 'evil' because those objects aren't guaranteed not to be moved therefore pointing to an object in an STL container could lead do 'crazy pointers' as I've heard them being called. Are there high chances that this could be my problem ? I don't really want to post code for that because it's a bit long and really messy but if I have to, I'll probably do so tomorrow in the evening.

Thanks to all.

Originally Posted by Desolation

Still on the same project, I get another access violation (definitely not my day =P). I was just trying to remember something. I think I've read somewhere that pointing to an object into an STL container is 'evil' because those objects aren't guaranteed not to be moved therefore pointing to an object in an STL container could lead do 'crazy pointers' as I've heard them being called. Are there high chances that this could be my problem ? I don't really want to post code for that because it's a bit long and really messy but if I have to, I'll probably do so tomorrow in the evening.

Thanks to all.

You can point to an item within a container as long as you don't modify the contents of the container during the lifetime of that pointer. If you insert, delete, or change an element of the container, all pointers pointing to objects within the container become invalid.

That would explain the problem. Do you know of an alternative ?

It depends on the container. You should be able to use pointers if you are using a list (unless of course you erase the object pointed to). For a vector, saving the index is one option, but sometimes indexes change. For a map, you should be able to find your object by the key regardless.

Another option is to store pointers in the container. This adds complexity because something has to manage the lifetime of the objects. For example, if the container you are talking about is vector<Move>, you could change it to boost::ptr_vector<Move> or vector<std::tr1::shared_ptr<Move> >. You could also use vector<Move*>, but manage the memory yourself. This is most easily done if the Move objects only exist inside the container. You would need to wrap the inserting and erasing of the objects so that you can new and delete them. You also would want to wrap the destruction of the vector (or clear()'ing of it) so you can properly delete its contents.

Doing that will allow you to continue to store pointers because the pointers will not change if the data in the container changes.

You know, I'd really love to install boost::ptr_vector<> thing but I'm not nerd enough. I can't understand a damn thing of command compilers and it seems wayyy too complicated and long to do.

http://www.boost.org/more/getting_started.html

Here's what I'm talking about.