Ca vous est peut-être déjà arrivé, lorsqu'on utilise certaines librairies, on ne doit plus utiliser de "main", mais on a un objet qui se crée, appelons le Appli, et on doit partir de lui pour notre programme...

Comment vous faites pour vos variables et autres ?
Pour le moment, j'en mets quelques unes en global, et les autres en attribut de la classe Appli, mais c'est pas pratique du tout je trouve.

Des expériences? suggestions ?

[edit] : pour illustrer, voila mes classes
Voila mes classes :
App, Frame et Panel sont obligatoires (librairie wxwidgets)
On remarque que toutes les classes ont besoin des autres, ce qui force à faire des boucle entre elles (genre App* Panel::GetParent()), pas montré ici :

LOL ok, je recommence^^
 
En gros, avec certaines libs, ya plus de main :
avec wxWidgets, on a un objet wxApp qui est instancié à l'exécution, et dont le constructeur (on y touche pas) appelle une méthode "OnInit()" et "OnRun", dans lesquelles en quelques sortes je copie mon main.  
 
Mais comme on est dans une méthode d'une classe, on crée pas des objets comme ca comme un bourrin, donc je les mets en attributs de la classe...

Y a jamais de main() dans une lib (sauf durant le développement pour tests éventuellement).
 
Pour les variables, ben c'est en private dans la classe, avec éventuellement les getter/setter qui vont avec, si besoin.  
Je ne comprends pas ton souci en fait.

Donc je dois recenser toutes les variables possible et les mettre en attribut, et faire des méthodes get/set... arf
Pour le moment c'est un peu moins propre, je mettais tout en public car J.affiche() a besoin des attributs de Appli.J et n'y accède pas.
 
Sinon peut-être faire une classe contenant juste les param, en attribut de Appli, et passé aux méthodes... c'est ptetre le plus simple.

Attends, j'écris un exemple pour être sûr d'avoir compris ton problème :

class A {
private :
   <type> foo;
   <type> bar;
public:
   foobar();
};
 
class B {
public:
   A instance;
   barfoo();
};

Donc d'après toi, B.instance.foobar() n'accèderait pas aux variables foo et bar ?
Pourtant, si. La classe A est une entité à part entière, si tu instancies 10.000 classes A avec des valeurs toutes différentes pour foo et bar, chaque instance de A aura accès à ses propres valeurs de foo et bar...

Donc la fonction foobar() a bien accès aux variables foo et bar. En revanche, la fonction barfoo() de la classe B ne peut pas y avoir accès.

C'est justement cette partie qui m'interesse si tu regardes mon message.
 
 
au final, je pense que le plus simple, ayant une classe A comme suit, et B ayant besoin de tous les bar et foo :

 soit de mettre les paramètres tous en public dans A, et de mettre un lien de B vers A :

Comme ca on a accès à tout par "parent->foo"
 
Soit de faire un truc annexe pour les variables :

Ce qui allège les classes, mais si B a besoin des méthodes de A, il faut quand-même faire le lien vers le parent.
 
 
 

Références circulaires, c'est mal.

C'est bien plus simple d'écrire :

class A {
    private :
      <type> foo;
      <type> bar;
    public:
      foobar();
      getfoo();
      getbar();
    };
     
    class B {
    public:
      A instance;
      barfoo();
    };

Et si B a besoin de foo ou de bar, il appelle getfoo() et getbar().
Ainsi, la classe A conserve le contrôle sur ses membres. Je le mets en gras parce que c'est une notion très importante. De plus, ça améliore la maintenabilité et la lisibilité : tu distingues d'un seul coup d'oeil les membres totalement privés qui servent au fonctionnement interne de la classe, et ne sont donc pas destinés à un quelconque lecteur extérieur, de celles qui sont des informations importantes pour ceux qui instancient la classe.

Oui, je comprends : pour que la "mère" accède proprement aux attributs de la classe qu'elle instancie...
Sauf que mon problème est que les classes doivent être imbriquées : exemple classe A mère qui contient des instances de F1 et F2 :

Et c'est là que ca devient le bordel
Et pour ce qui est de cette structure tordue, j'ai pas le choix, j'aimerais pouvoir éviter...

Uh... F1 et F2 ont besoin de connaître A, qui lui-même instancie F1 et F2 ?
 
Jette ton diagramme de classe et refais-le, tu ne t'en sortiras pas. En tout cas pas proprement.

LOL, comme je te dis, j'ai pas vraiment le choix, c'est la librairie qui me force à ça, enfin c'est l'impression que j'ai, d'où mon post :
Comment structurer un programme avec les classes "forcées" de la librairie (sans main) vu que tous les objets sont attributs de la classe principale... et qu'ils souhaiteraient se parler entre eux
Ce soir je poste le détail des classes auxquelles je peux pas toucher + les miennes, voire si ya une solution moins pire qu'une autre^^

 
Vapeur qui fait genre d'avoir compris  

j'ai édité pour éviter cette confusion

Voila les classes obligatoires : App, Frame, et Panel
App : c'est l'application, Frame la fenêtre (menus...), et Panel l'affichage
 
Le seul truc "à moi" est Jeu, qui a une méthode affiche() (avant affichait en cout<<, et maintenant affiche dans Panel->paint() )
 

J'ai mis mes trucs (jeu et param) dans App, j'aurais pu choisir de les mettre dans Panel, mais il doit être possible d'avoir plusieurs Panels pour un seul Jeu.

D'après ce que j'ai lu en cherchant rapido, vu que c'est tout géré par événement, tu va avoir quelque part (dans onRun?) une boucle qui boucle indéfiniment jusqu'a ce que tu ferme ton programme.
 
Un truc dans le style

 
il me semble...

Justement, c'est ca qui est pas cool avec wxWidgets, ya aucune buocle^^ (du moins pas visible)
En fait, on a une classe qui est instanciée (App), et après, les évènement gèrent en quelque sorte des interruptions : on associe un event à une méthode de la frame ou du panel :

et quand il se passe rien, c'est la méthode OnIdle qui est appelée.

Bah tu surcharge onRun() pour y mettre ta gestion des events ou gère a la fois ceux de wxwidget et ceux de la SDL nan?

En tout cas je voit pas trop le trip de départ du topic avec tes noeuds de dépendances de classes...

les évènements sont apparement gérés tout seul comme j'ai dit (On Idle si rien, et d'autres méthodes de Frame si on couche la souris, clavier ou les menus), on peut pas faire de boucle à la main.
Et ce sont des evenements wx, SDL ne récupère rien, tout est géré en wx.
Pour mon trip de dépendance, dans mon post de 19h39, on voit que chaque classe a besoin des infos des autres, donc si App contient frame qui contient panel, app accède à tout, mais il faut faire une boucle pour que panel accède à App (et donc à Jeu). Enfin c'est le bordel, mais ca marche.

en general, on met dans Idle les calculs necessaires à l'affichage d'une nouvelle frame, dans onKeyboard les controles du jeu, OnPaint l'affichage de la frame en cours ...
 
Pas besoin de boucle explicite.

et donc a quoi te sert sdl si tout est géré en wx?

edit: ah ok (pas refresh avt le post de joel )

@kyntriad : wx pour les menus, sdl pour l'affichage.
@Joel : c'est ce que je fais avec Onkeyboard/OnMouse, mais pour l'affichage, je commence par avoir un programme qui tourne sans (en mode console) : Jeu contient le plateau et les pièces, donc j'ai des méthodes plateau->affiche() et pièces->affiche(), où j'ai remplacé les "cout" par des "SDL_Blit_surface".
Pour afficher, Paint() appelle donc le Jeu J, qui est dans App, d'où la boucle de Panel vers App

Et je veux pas mettre le Jeu dans Panel car un jeu peut avoir plusieurs fenêtres d'affichage.

Autre détail, la variable screen doit être accessible à tout ce qui affiche, donc Panel et Jeu.

déjà Jeu ne devrait contenir que la logique du jeu et utilisé des événements pr dire à une autre classe Affichage que son état à changer. Dans Idle, juste Jeu est manipulée et lance des event sur Affichage. Dans Paint juste Affichage est appelée.

Intéressant, j'avais jamais imaginé ça, j'ai toujours fait des méthodes affiche(), mais jamais séparé le tout...
donc en gros, je change mes ->affiche() en ->SetAffiche(ClassAffiche, paramaffich) et Créer une ClassAffiche qui sera appelée par OnPaint().
Reste à placer ClassAffiche :
 * si on la met dans App, il faudra la passer en paramètre à Panel.
 * sinon on la met dans Panel, et on passe autant de ClassAffiche à Jeu qu'il existe de Panel.

Merci pour cette idée, je vais voir ce que ca donne sur mon code...