C++ OO problems when trying to make AI

Quote:

Original post by algumacoisaqualquer Anyone knows what's going on??

You'll need to post the relevant code. Post the exact line number where it is crashing and the code around that point (i.e. when it crashes in the debugger post the code relevant to that section).

-me

Suggested reading:

How To Ask Questions The Smart Way by Eric Steven Raymond
Introduction to Debugging by Richard "Superpig" Fine.

Beyonds these links, with the little the information you've put forth so far, I'm unable to help you further.

Ok, so declarations are done as:


The actual code is quite long. Here's the complete version:


And here is the short version (hopefully only the important stuff, and none cut off):


Edit: Well the debugger gave me an "Program received signal SIGSEGV, Segmentation fault." Means it's trying to read memory from something that doesen't exist. I believe this is because there isn't a one_possibility.possibilities[0].board_value, as one_possibility.possibilities has zero values. However, the program is crashing at the line "for (int i = 0;i < one_possibility.possibilities.size();i++)" (this information is from my std::couts, not the debuger).

[Edited by - algumacoisaqualquer on January 11, 2007 5:55:30 PM]

one_possibility.possibilities.size() == 0, or "four" is being reached but not flushed, and the crash occurs later. Instead of using cout, use a debugger to find the actual line of the crash. See Superpig's article.

A decent implementation of the standard library, in debug mode, should've given you a descriptive error immediately upon using possibilties[0] if .size()==0. Upgrade to one that does and/or assert( .size() == 0 ); in the future to avoid similar mishap.

Quote:

Original post by MaulingMonkey one_possibility.possibilities.size() == 0, or "four" is being reached but not flushed, and the crash occurs later. Instead of using cout, use a debugger to find the actual line of the crash. See Superpig's article. A decent implementation of the standard library, in debug mode, should've given you a descriptive error immediately upon using possibilties[0] if .size()==0. Upgrade to one that does and/or assert( .size() == 0 ); in the future to avoid similar mishap.

It does looks like "one_possibility.possibilities.size() == 0", I made a check and it returned true. However, I don't understand what you mean by "Upgrade to one that does and/or assert( .size() == 0 );"

Anyway, I'll finish reading Superpig's article, truth is I never understood how the debuger worked (I'm using MingW in CodeBlocks).
Thanks!

Original post by algumacoisaqualquer

Quote:

Original post by MaulingMonkey one_possibility.possibilities.size() == 0, or "four" is being reached but not flushed, and the crash occurs later. Instead of using cout, use a debugger to find the actual line of the crash. See Superpig's article. A decent implementation of the standard library, in debug mode, should've given you a descriptive error immediately upon using possibilties[0] if .size()==0. Upgrade to one that does and/or assert( .size() == 0 ); in the future to avoid similar mishap.

It does looks like "one_possibility.possibilities.size() == 0", I made a check and it returned true. However, I don't understand what you mean by "Upgrade to one that does and/or assert( .size() == 0 );"

"Upgrade to one that does" indicates I think it'd be benifitial to upgrade either:
1) Your C++ toolset (Compiler, Linker, and Standard library, which usually come together, often along with an IDE). Visual Studio 2005, for example (the express version of which is available for free download).
2) The Standard Library's implementation, independantly. Not all implementations of the standard library will work on all compilers, but it may be worth investigating the alternatives. That said, #1 is typically easier.

"assert( .size() == 0 )" is refering to assertions as mentioned in Superpig's article:

Quote:

From GameDev.net -- Introduction to Debugging -- Miscellany (page 7): How do you put assertions into your code, and have them tested? The fastest approach is to use the assert() function in the C Runtime Library, which will give you a generic error dialogue reporting the thing you were asserting. However, you can often get a lot more information by writing your own assertion macro and handler; you can include state about your game, you can have the handler write a log message instead of throwing up a dialogue, you can provide the option to ignore the assertion and continue on anyway, etc.

Technically, assert() is a macro (in most/all implementations), but regardless, it can be found in the header file for C++.

I'm suggesting I would've used it like so:

void c_AI::GetBestMovement(int &start, int &end){    c_possibility one_possibility(map, 3);    assert(!one_possibility.empty());    /* possible rationale for why one_possibility should never be empty,     * or reference to what piece of code should be enforcing this     * guarantee.  A one line comment on the actual assert line will     * probably suffice, I've just used a multi line break due to the length     * of this explaintory text.     */    c_possibility *best_possibility;    best_possibility = &one_possibility.possibilities[0];    int g = one_possibility.possibilities.size();    for (int i = 0;i < one_possibility.possibilities.size();i++)    {    	if(one_possibility.possibilities.board_value > best_possibility->board_value)    	{best_possibility = &(one_possibility.possibilities);}    }    start = best_possibility->start;    end = best_possibility->end;}

Then, even if my implementation of the standard library did not make this check for me, the program would (in debug mode) halt and inform me of the assert() failure. Typically, this includes file and line number (for quick location of the problematic area of code in question), as well as check performed.

This allows me to skip the entire diagnosis of crash cause step, which was as follows:
1) one_possibiltity.possibilities.size() being on the stack (and not crashing) eliminates the likelyhood of one_possibiliity or it's submember .possibilities refering to invalid data. (In a release build, given that you do nothing with the result, optimization would eliminate .size()'s not crashing as a reliable indicator of anything, given that it doesn't need to actually be called until the loop).
2) Given the above, there are two main "forks" of code execution:

A) .size() != 0. I considered this first. Unless the internal pointer itself was unreferenceable (very unlikely given that the internal size variable was), we're left with:
A.1) Validly initializing the pointer
A.2) Using said pointer and valid indexes < .size() in the loop
A.3) Dereferencing a local, valid pointer (given 1 and 2) in ->start/->end to copy the values, which std::vector guarantees to work (in a well behaved program, i.e. barring memory corruption that has damaged std::vector's contents).
A.4) Returns to the executing function, which hasn't been provided.

Excepting A.4, that left the other fork of execution to possibly blame:

B) .size() == 0:
B.1) Invalidly initializing the pointer (With container[0], index < size == false (0 < 0 == false)). I note that a bounds checking implementation should catch this.
B.2) A loop which never executes.
B.3) First use of dereferenced value of best_position during assignment to ->start/->end, which in an unchecked implementation will most likely cause a segfault (*nix) or access violation (windows). Delayed result of problem at B.1.
B.4) Returns to the executing function, which hasn't been provided.

Quote:

Original post by MaulingMonkey Excepting A.4, that left the other fork of execution to possibly blame: B) .size() == 0: B.1) Invalidly initializing the pointer (With container[0], index < size == false (0 < 0 == false)). I note that a bounds checking implementation should catch this. B.2) A loop which never executes. B.3) First use of dereferenced value of best_position during assignment to ->start/->end, which in an unchecked implementation will most likely cause a segfault (*nix) or access violation (windows). Delayed result of problem at B.1. B.4) Returns to the executing function, which hasn't been provided.

Well, I have moved on to Visual-C++, and tried the assert thing. Indeed, the possibilities vector has 0 elements inside, so this is giving me the error. However, The reason why this is happening remains a mystery. I'm suging the debuger now, and while I'm still learning to use it, I'm allready cathing several things I had no idea that were happening.

The most weird one was cought on accident - basically my map class has the two players as elements, and they in turn have a piece vector each. They were suposed to have 12 pieces, but the wacth shows me that, sometimes, they will have 36 or 60 pieces each (and the board has only 36 squares on total). Basically, the crash (or one of the crashes) is happening at c_possibility::calculate_possibility(), when I try to access the (c_map map) element of c_possibility. What I don't understand, however, is why it isn't crashing at all at the first time I build up the possibility tree - it is actually working as expected (only the first time, tough).

So, basically, all this part is working fine - the problem is somewere else. I'll have to revise almost everything now, but if I figure out what's going on, or at least get any more concrete thing to ask, I'll come back.

Anyway, thank you very much for the helping, this is the first time I get to actually make a debuger work - and the assert thing was also very usefull.