   c++ oop interdependent objects
  Hello,Im working on a poker game and am trying to do it oop to improve my style.I have a struct strhand, that manages all the data of the situation like potsize cards etc with the help of a few subobjects. Everythings working fine so far.Now I have a struct strki, the bot, which I also manage as a subobject of strhand. Its function is to give out a computeraction when requested by strhand.But to make a decision, strki needs the data from strhand.So the problem is: child needs data from parent I could encapsulate the data they share in an own object, but that would give a lot of ugly prefixes. So I am trying to solve this with a pointer or yet better a reference(eventhough the initizialization could be a little bit of a headache, since you cant initialize an unreferenced reference), but keep running into "struct has not yet been defined" errors.So how do I code this?Thank You   
Quote:Original post by schattenmaennleinbut that would give a lot of ugly prefixes.Prefixes?In OO, types are used instead of prefixes.   ;  I probably used the word prefix incorrectly. What I meant is that I would have to write: handdata.potsizein change of justpotsize everytime I want to use a variable the two objects share. Which would result in a lot of unnecessary typing.Thinking about the problem again I think I left a part unclear:That child needs data from parent is not a problem, but that child also is a subobject of parent.Maybe this is a design problem.Strhand needs to request an action from Strki, like "bet" "fold" or "call", and Strki needs data from Strhand like "potsize" "blindlevel".   ;  First, let's get the terminology straight. If strhand contains a strki object, we call it composition or a "has-a" relationship. strhand has-a strki, but that doesn't make strki a child of strhand (parent-child relationships exist only in the context of inheritance). To be honest, your issue seems to be caused by a conflict of interest on your part. On one hand, you want to write pretty, clean OO code. On the other, you don't want to type too much. These goals tend to conflict.To me, it seems strange for the hand to own the bot; I would've done it the other way around. After all, the player has a hand - the hand doesn't "have" the player. If you could refactor your code so that strki has an instance of strhand, you should be able to access the data you need.EDIT: as far as your actual question goes, a forward declaration is probably what you need. Something like this:struct strki; // or...struct strhand;EDIT2:"potsize" and "blindlevel" don't sound like they are conceptually related to the hand. Perhaps you could have a "game" class as well?   ;  (ive deleted this post to avoid unnecessary confusion, the next one should clear things up)[Edited by - schattenmaennlein on May 30, 2010 5:45:32 PM];  Okay, Ive written a test application to make the problem really clear. code/ #include "stdafx.h"#include <iostream>using namespace std;struct strki;struct strhand;struct strki {strhand* hand; void assignhand(strhand* x){ hand = x; cout << hand;  //this works and gives out the address cout << *hand->mode; //and here comes the error}};struct strhand{int mode; strki ki;};int main(int argc, char* argv[]){strhand hand;    hand.ki.assignhand(&hand);return 0;}/codeF:\inter\inter.cpp(23) : error C2027: use of undefined type 'strhand'F:\inter\inter.cpp(10) : see declaration of 'strhand'F:\inter\inter.cpp(23) : error C2227: left of '->mode' must point to class/struct/unionError executing cl.exe.I am able to retrieve the address of hand. But I cant access its members. What am I doing wrong?   ;  Move the function definition to after the struct definitions. Ex:struct strki;struct strhand;struct strki  {  strhand* hand;  void assignhand(strhand* x);};struct strhand {  int mode;   strki ki;};void strki::assignhand(strhand* x) {  hand = x;  cout << hand;  //this works and gives out the address  cout << hand->mode; //and here comes the error};  Thank you very much, works now and I understand why.Thanks everyone for the help.   ;Gamasutra's design columnist and noted consultant Ernest Adams returns with his perennial reader-favorite column, devoted entirely to exploring the design foibles of games, so designers of the future can avoid making the mistakes of the past.  View the full article