Brain Fart.....

[markyrocks]

I think im having a brain fart bc i can't figure out how to do what im doing. I have a huge multilayered class that im building and i've never extensively worked with them. I have structs that have the name of numbers nested inside of other structs inside of a class....so like

class.struct1.struct2.numberOfstructs.otherstuff

and so on. i need the array to be of type struct2. I made an array of type struct 2 and set it like

  
struct2 ary[6]{struct2.one,struct2.two,struct2.three, etc;}

im basically trying to get to where i can loop through these numbered structs
so i can do something like the following

for(i;iexpression;something)

class.struct1.struct2.ary[i].otherstuff=data 

//however the aray is initialized outside of struct2 so im left with

class.struct1.struct2.ary[i].one || two || three.otherstuff=data.....

so in other words this array i made is basically pointless. This is way deeper than i've ever been in objects and im probably missing somthing simple bc my head is spinning anyways.

Thanks guys let it rip.

[highwayman]

So just to be clear. The actual classes/structs themselves are defined like

class x{
  public:
  struct struct1{
    struct struct2 {
      int one, two, three; // what type are these actually? It might be helpful to know.
    };
  };
};

Right?
Or no, because, I’m pretty sure you can’t declare that array like how you wrote it, it would be something more like this:
x::struct1::struct2 array[6];
If the classes and struct were defined that way, so could you give some more info to clear that up?

[markyrocks]

the array is defined inside of the class just outside of a struct that has other nested structs with one two three as the struct name. The array's position is in the proper scope for me to declare if the way i did so i don't think thats the issue. It looks like this

class x{
           struct A{
                       struct B{
                                    struct one{
                                             };
                                    struct two{
                                             };
                                    struct three{
                                             };
                                  };
                         B b;
                         B ary[3]{b.one, b.two, b.three}
};

};

Im not sure what i was trying to do is possible without using some round about method or somthing like the boost library. I've resorted to just using getters and setters. I guess this is a round about method of sorts but it seems to be the standard of dealing with this many layers of data.

The point of this program, bc i been playing with a rubix cube alot lately, I figured it would be a good challenge to make a virtual rubix cube and then write functions to rotate it in different ways. Then possibly one day have it figure out what needs to happen to solve the cube. Then possibly put in the ablility to put in information about the users cube and then have the program tell you what to do to solve it. I realize this is a monster of an undertaking but its just for fun. Its cold outside i don't have nothing else to do. I've only been working on it for a few hours and i'm up around 6 or 700 lines of code and i havn't even scratched the surface.

o and the number names are for a specific piece of the cube. theres 3 types of pieces on the cube so the cube looks like cube.piecetype.piece.pos.x y or z. I have infomation in there about what color is on which side, the orientation, etc etc.

[TheIdeasMan]

The point of this program

It would have nice if that was in your first post :+)

I've only been working on it for a few hours and i'm up around 6 or 700 lines of code and i havn't even scratched the surface.

With that and the data structure you have, it probably means your design is wrong :+(

I would have a struct which describes a small cube. They will only be an edge or a corner or a centre, the centre will be const once assigned to. I would keep the orientation of the whole cube constant as well, if blue is on the top face, and white on the front, they will stay there. The contents of the struct will describe it's type, colours and orientation. Because the rubix cube is so small in computing terms, one could just have a 3d array of the small cubes. Then there will be logic to implement the turning of the faces.

Good Luck !!

[againtry]

I think im having a brain fart bc

Only a fart. I think it's more than that.

Scrap your nested struct's and think along TIM's lines. You've only got 6*9 faces and their legal operations (whatever they might be is the challenge) to worry about.

[markyrocks]

The struct that describes a small cube is the numbered structs. Each number represents a piece of the greater structure type. Yes I could have wrote one piece and just duplicated it and then set it to a
position. The point of the additional structs is for organization and not having to make 26 variables to represent each piece

. The faces of the pieces All need oriented based on the relative position to the cube. I'm having a good time.

I challenge some to write a program 500 lines or less that represents a cube and operations to move the sides around.

I don't like the idea of the center pieces being at set positions and everything else moving around them.

It's an idea but it's not going to save alot of effort I don't think. Up down left right will always be the same but the position of the cubes and the orientation of the faces will change. But there is no way this is as simple as saving to and array and just changing the element position. Each piece is unique and like unique mid edge piece is blue right green left and at position 2,1,0 then front is equal to green and right is blue. Then if that piece gets rotated right 90 degrees the the position changes to 1,0,0 front still green bottom is blue right is set to nothing. This data will then be sorted through to populate an array that will be used to display the data.

[jonnin]

I don't like the idea of the center pieces being at set positions and everything else moving around them.

this is how the classic Rubik's cube is made, its because of how it is designed and built. Unlike the flat square puzzles that let you slide any face around.

are you trying to make a rubik's cube? If so there is a lot more to it than just fixed centers... the corners are 3 faces that are fixed to each other, and the middle between corners are 2 faces that are fixed to each other, and only certain moves are possible. If its not, then you can let the middle move too. Define what this is, then make the structs you need to describe it... is it 9*6 completely free faces or is it a mix of 3 types of pieces (corner, centers (single face) and between corners (2 faces) ) or whatever else..?

[highwayman]

I challenge some to write a program 500 lines or less that represents a cube and operations to move the sides around.

hm.. How much does readability count lol.

[markyrocks]

are you trying to make a rubik's cube? If so there is a lot more to it than just fixed centers... the corners 

are 3 faces that are fixed to each other, and the middle between corners are 2 faces that are fixed to 

each other, and only certain moves are possible. If its not, then you can let the middle move too. Define
 
what this is, then make the structs you need to describe it... is it 9*6 completely free faces or is it a mix

 of 3 types of pieces (corner, centers (single face) and between corners (2 faces) ) or whatever else..? 

Yes I'm making a rubrix cube

This is my point exactly. Like the 3 sided corner pieces are all attached to each other in a fixed orientation. I just think it's too much data to deal with to just have one small cube struct and have a variable = to the type whether it a single side 2 side etc. Youd have to constantly be accessing the type and then be doing different things to different pieces based on that variable.

I have it setup so the rubrix cube is the class that contains 3 strucs for the piece type. Inside the piece type is structs that represent the numbered piece like piece one piece two piece 3. The numbered piece structs have variables that represent a side that will be set to the color of the piece based on its orientation after the piece is actually placed in the cube. I.e. given a position based on other factors. Inside of these numbered piece structs are a position struct that keeps track of where the piece is.

I just think it's easier to deal with the data to have it setup this way bc you can write functions based on the piece type and call them on the pieces within the type rather than having to access a variable that describes the type then have a very large function figure out what to do with the piece based on that type or having 1 function basically get the type and direct the object to to other functions based on the type.

I think it's way more complicated than what I had originally anticipated. But I think I have it under control.

Then when I want to display data I can just query the whole cube get the position colors of the sides and save that to arrays that represent a side and the cout the data

Edit. I just dont really seen the point of keeping the center pieces fixed and having everything move around it. It may save having to write a few functions but I think I'd rather do that than have the other 2 piece types behave differently. I guess I have to look at the cube algorithms and see if there is a need to spin the center. If the cube algorithms exclude moving the middle then I'll kinda have to bc this will only be able to be solved via algorithms anyways. Probably be impossible to manually enter the moves and be able to accomplish much via the display method.

[jonnin]

you don't need to spin the center. It can't move and its a solid color. Spinning it is not helpful, and the only reason to do so would be as part of an animation in any graphical side of the program, but internally, you don't need to touch them. You can in fact eliminate them from the solving algorithm or whatever entirely and just have them as graphical bits only.

if you want a full blown OOP design you only need 1 piece if you abstract faces. eg a corner has 3 faces, in a container, and a enum or something that tells you its a corner, but the same struct can handle that for all types. Due to the nature of this specific problem, the type (eg corner) and # of faces (eg 3) can be related to represent both pieces of info via an enum.

[markyrocks]

After thinking about this for awhile I am thinking that maybe I am going at this the wrong way.

It does seem alot simpler to have one cube struct make variables equal to those instances and then putting them in a 3d array. Move them around based off the element. The colors would still need to be oriented but that could easily be calculated from the position as the array was being queried for output data.

That is a very good point about the type and number of faces basically being represented by the same variable. Definitely simplifies things

I didn't put any planning into this I just kinda sat down and started writing

[jonnin]

there are 9 planes, too. that may help as well.
that is, when you rotate, you have a set of pieces that move as one. its either top plane, center plain vertical, or bottom plane slicing it one way, or left, center horizontal, right slicing the other way. And finally, front, center, and back for the third way to slice it. So you need 9 rotations, and only 2 distinct (its either a top/left/right/bottom/front/back) or its a center plane.

[TheIdeasMan]

@jonnin

In the book that I had, there is no such thing as rotating any of the centre planes, all the moves are expressed as moving these planes: right, left; upper, down, front, back. So only 6 rotating planes.

markyrocks wrote:

I didn't put any planning into this I just kinda sat down and started writing

Perhaps now you realise the value of doing some design first with a pencil and paper :+) I guess most of your 700 LOC is probably wasted effort.

It would be worth it if you show us the first parts of your new code. Just so we can see you are getting the basics right for example: like no implementation code in header files ; and good naming of variables and functions.

I thought about this problem a bit more: rather than a 3d array, I would have 6 separate 3 by 3 array to represent each face. Those arrays store the colours only, which are enums. If you then are careful & consistent about which corners are represented by the [0][0] and [2][2] parts of the array, it will be easier to manage the rotation of a face. If one was looking at the upper face, the [0][0] could be the lower left corner, while [2][2] would be the upper right. Then consider the left face, the [0][2] is the same corner as the [0][0] of the upper face, the [0][0] of the left face is the same as the lower left of the front face. Then to rotate the front face by 90 degrees clockwise, it just means moving [0][0], [0][1], [0][2] to the array representing the upper face, the same for the other 3 small cubes on each relevant face. Finally rotate the colours on the front face by 90 deg clockwise.

I hope all this is not too confusing, but doing it that way avoids having to worry about orientation of corner and edge cubes. My idea may be similar to your original idea, but your code had too much nesting of the data structure IMO.

You could do the following to start with, in a header file:

enum colours {blue, white, red, yellow, orange, green};

constexpr int CubeDim {3};

using Face = std::array<std::array<colours,CubeDim>, CubeDim>;

class rubix {
private:
    Face Front;    // F in the notation
    Face Back;    // B in the notation
    Face Right;   // R in the notation
    Face Left;      // L in the notation
    Face Upper;  // U in the notation
    Face Down;   // D in the notation
public:
    rubix();
    // Put declarations for the rotate functions here
    // or put them in an interface class which this class  inherits
};

In rubix.cpp

rubix::rubix() {
    // Initialise each face with a colour to represent a solved cube
}

With the idea of rotating the entire cube, that was necessary in the book that I had. If one uses the idea of storing the faces, it would be reasonably easy to do.


Once you have the implementation, you could try making some patterns, starting out with a solved cube. For example: an X pattern on each side.

Hope all goes well !! :+)

[TheIdeasMan]

Another thought:

If one implements the rotate cube function, there would only be a need for one rotate function. I guess that would be easier to program, but much less efficient: there is a lot of copying to rotate the cube . Every move would involve 2 cube rotations.

I thought about having one rotate function via sending a Face as an argument, but that would involve 6 different scenarios, I am not sure whether it's easier to have 6 separate functions, because maybe they all could be similar.