tags:

views:

267

answers:

6

Hello, I am making "game of life" implementation that, when cell has:

  • two live neighbours I make object of class CCellB
  • two live neighbours I make object of class CCellA
  • when has >3 or <2 I make object of class CCellX (dead)

Class CCell is base of CCellA, CCellB, CCellX arr is previous state of game, temp will be new arr at the end. My problem is: That works fine, until I change new CCell(); to new CCellB();:

CCell ***temp = allocateArray();

for(int i = 0; i < n; i++)
{
    for(int j = 0; j < m; j++)
    {
        nAmount = arr[i][j]->countAliveNeighbor();

        if(nAmount == 3)
        {      
            temp[i][j] = new CCellA();
            temp[i][j]->alive = 1;

        }else if(nAmount == 2)
        {                     
            temp[i][j] = new CCell(); // HERE, WHEN I CHANGE IT TO CCELLB IT DON'T WORKS
            temp[i][j]->alive = arr[i][j]->alive;

        }else if((nAmount >= 4)||(nAmount < 2))
        {                     
            temp[i][j] = new CCellX();
        }   
    }
}

Then it seems don't work properly... Seems like neighbours are not count properly, Cell with 4,5 neighbours still alive alive var is member of base class - CCell, all is public, please help!

+1  A: 

Replace your CCell ***temp with std::vector<boost::shared_ptr<CCell>> or std::vector<std::tr1::shared_ptr<CCell>> (for VS2008 or VS2010) and I think you will find your mistakes.

Alexey Malistov
I can use only std lib sa vector<CCell*> maybe will be good too ?
Green
`std::vector<CCell*>` is better than `CCell ***`. But `std::vector<shared_ptr<CCell>>` is better than `std::vector<CCell*>`. You may use `boost::shared_ptr` or `std::tr1::shared_ptr`. If you have no `shared_ptr` download boost library and copy `shared_ptr.hpp` from it.
Alexey Malistov
+2  A: 
andand
It is homework, that was requirements ...
Green
@Green: For future reference, you should tag homework as such.
andand
A: 
Eduardo León
I thought the same thing when I initially looked at the code. It turns out, through an admitedly convoluted process, that he is not doing an inplace update. temp holds the update, arr contains the current state. He's only making changes to temp, and checking arr for determining the values in temp. Presumably he later deletes arr (and all of its elements, which takes care of the memory leak) and then does something like arr = temp;
andand
exacly @andand.
Green
A: 

Why would you create a new object for every Cell in Conway's Game of Life? It wil lconsume massive amounts of memory and time, even if you carefully delete every object after each iteration.

Better search about better algorithms for it, like Hashlife.

Martín Fixman
It is homework that was requirements ...
Green
A: 

I'll skip over the design issues (the use of new here does seem like it would cause a lot of avoidable churn )

Is your countAliveNeighbor function unique for CCell vs CCellA, B, etc? If so it should be virtual. If it isn't, when you assign a CCellB object to a CCell pointer, the code will execute CCell.countAliveNeighbor insted of your intended CCellB function.

Digikata
It is virtual declared in CCell
Green
A: 
andand