List of arrays

[ppetrov]

I just want to make a list of complex elements (arrays).
What is wrong in the following code?

#include <iostream>
#include <list>
using namespace std;

const int MAX_CUBES=4, MAX_FACES=6;

typedef unsigned char Cube[MAX_FACES]; // stores colors of cube faces: 'R', 'G', 'B' or 'Y' 
typedef Cube Tower[MAX_CUBES] ; // tower(column) of cubes

list <Tower> solution; 
Tower t;

int main()
{       
    for(int i=0; i<MAX_CUBES; i++)
        for(int j=0; j<MAX_FACES; j++)
            t[i][j] = 'R';
    
    
    solution.push_back(t); //What is wrong here?
    
    system("pause");
    return 0;
}

[Athar]

Arrays aren't objects. Use vector instead.
Edit: if the number of cubes is constant for all towers, you can also use std::tr1::array/boost::array.

[ppetrov]

Number of cubes is not constant for all towers (in some cases).

I also simply LIKE arrays and would like to make code as fast as possible; anything from STL is actually not very desirable here.

Now, my problem is that it is very hard to calculate how many solutions this problem may have. That is why I am inclined to use "list of arrays" (instead of "array of arrays"): I simply have no idea how large an "array of arrays" must be in order to contain all possible solutions.

Any ideas?

[Athar]

You're implying that something from the STL is slow by default, which is nonsense.
std::tr1::array is a wrapper for arrays with fixed sizes and has zero overhead.
However, since they're objects, you can store them in a list.

[bluecoder]

HI ,

Is this deceleration right . I mean to say can we typedef the array like this ?

typedef unsigned char Cube[MAX_FACES]; 
typedef Cube Tower[MAX_CUBES] ; 

Thanks in advance

[n4nature]

I think that a list of double pointers should work.

list<**Tower>

list<**char>

[Athar]

I think that a list of double pointers should work.

No, it won't. That would require a dynamic memory allocation, because otherwise you'd keep adding pointers pointing to the same array.
And if you use dynamic memory allocation, you could have used a vector in the first place - because that's the only "disadvantage" it has over an array. And even that is not a real disadvantage, unless you keep creating and deleting several million cubes and towers per second.

In this case, a vector of tr1::arrays is best - the number of faces of a cube will always be 6, so no dynamic allocation is needed.

[bluecoder]

Hi ,
I don't understand , please help me understand , is it right to declare as .

typedef Cube Tower[MAX_CUBES] ;

Please help me understand this .

[Athar]

bluecoder wrote:

Hi ,
I don't understand , please help me understand , is it right to declare as .

typedef Cube Tower[MAX_CUBES] ;

Please help me understand this .

Yes, that is allowed. Still, Cube and Tower remain arrays.

[bluecoder]

Thank you Athar

[kempofighter]

The OP still may be missing the point. There is nothing wrong with the typdef for a c-array. the problem is that those entities are simply blocks of memory. There is no copy constructor or assignment operator. The C++ standard requires that any type used to construct a sequence container be copy constructable and assignable. There is another solution which is to wrap the array within a struct and then add struct instances to the std::list. Now I can't say whether those typedefs will work for a multi-dimensional array. That I cannot comment on as it looks to be confusing. Why not just typedef a 2d array to begin with and wrap it within the struct?

const unsigned int MAX_CUBES(20), MAX_FACES(10);
typedef unsigned char Tower[MAX_CUBES][MAX_FACES];
struct TowerArrayType
{
   Tower tower;
};

std::list<TowerArrayType> theTowerList;

[kempofighter]

I also simply LIKE arrays and would like to make code as fast as possible; anything from STL is actually not very desirable here.

std::list is from STL yet you are using that.

Number of cubes is not constant for all towers (in some cases).

You either need to use something that is dynamic such as deque or vector or you can change the design significantly by having a list of objects where each object is a tower. Define the tower as a class. Design a reasonable interface and organize its building blocks however you wish. Shouldn't the tower be defined in terms of the building blocks, number of blocks, size of each block, and so forth? A tower could have many properties. Logically I would create a tower class and have a 1D list of tower objects. The tower objects can have c-arrays as member functions that will be copied when the object is copied. You can't specify an array type directly for use with an STL sequence container regardless of how fancy the typedef is.