Ma question du jour, est : est ce qu´il existe un moyen d´acceder à l´objet parent d´une classe.

Par exemple :

class a {long truc;};
class b {long machin();};

class c {
a CL1;
b CL2;
};

donc est ce que dans le code de la méthode machin de l´objet b je peut faire référence à la valeur truc de l´objet a qui se trouve dans le même objet de la classe c ?

si je ne suis pas très clair dite le moi.

Merci d´avance.

P.S. j´ai peut que me demande si elle est possible ne fasse appel à des concept avancé de POO, si on peut s´en passer, ça me ferait plaisir...

La reponse sera coute : non

A moins de faire passer la classe ´a´ en arg dans la methode b::machin(a arg)

mince alors... ça m´avance pas.

Mais merci de ta réponse ( c´est pas ta faute après tout).

soit tu mets truc en public
soit tu peux utiliser friend pour avoir acces aux donnees privees d´une classe.

par ex
class a
{...
friend class b;
};

Mais bon, essayes de voir si tu peux faire autrement, pcq les " pros" de la poo n´aiment pas mettre une classe friend pcq ca contourne un peu les principes de membres prives.

C´est clair que ce n´est pas de la POO propre, mais plutôt du bricolage.
Ne connaissant pas la POO en C, mais principalement en Delphi, je ne donnerais pas de conseils sur la syntaxe.

et quand bien meme, si tu utilises des friend, l´instance CL2 sera amie du " concept" de la class a, mais ne fera pas explicitement reférence à l´instance CL1 de ta class c, à moins de faire comme ce que propose kouic, c-a-d fournir explicitement une référence concernant l´instance que tu veux manipuler ( quand on veut garder une relation vers le parent, dans une structure d´objet arborescente, on aime bien faire ce genre de truc).
Mais c´est clair que ton histoire de a et b, là, c´est crade au possible : à mon avis tu devrais repenser ton design de class, ça doit venir de role mals définis de chacun des composants.

ben, je sais pas, c´est toujours ma machine virtuel pour mon espèce de langage.

Alors j´ai découpé les classe pour ce qui m´a semblé le plus logique, la mémoire d´une part, la pile d´un autre etc...

Mais sinon, je sis obligé de tout mettre dans une seul classe, ça me semblait moins propre.

A la limite, on peut mettre le code pour une même classe dans plusieur fichier différend non ?

"A la limite, on peut mettre le code pour une même classe dans plusieur fichier différend non ? "

Nan nan nan nan nan.
Je suis sur qu´il y a moins de concevoir ton application d´une facon plus propre.
As tu modeliser ton application avant de te lancer dans le codage ? As tu quelques shemas ou autre comme exemples ?
Je suis persuader qu´avec une bonne methode il n´y a pas besoin de faire des trucs crades.

je sais pas si ça suffit, ou si ça interesse qqn, mais voici les prototype de mes classe : http://wall.cours-info.net/?id=219&numero=non

mais effectivement je n´ai pas modélisé mon application avant, disont que je n´ai pas l´habitude de la POO ( même à très petite dose).
Je me suis juste aperçu que poru faire des prog un tant soit peu complexe ça facilitait énormément l´écriture ( avant, je ne savait pas par quoi commencer dans mes programmes, maintenant, je sais).

Ok, voyons voir ca.
. ..
Je ne sais pas ce qu´est exactement CL_Stack, d´apres le nom et les methode c´est une zone memoire.
Pourquoi CL_Srom et CL_Stack, etant tout deux de la memoire, n´ont ils aucun lien de parenté ?
Pourquoi ne deriveraient ils pas d´un meme objet ?
Je ne sais pas ce que tu veux faire exactement, mais maintenant je suis persuadé qu´il y a un moins eleguant de structurer tout ca.

Perso, moi je sauterait sur un papier et un crayon et commencerait a dessiner frenetiquemeent un zoli diagramme de classe en UML
Haaaaaaaaa, la modelisation, c´est aussi prenant que le codage lui meme.

en fait, le problème, c´est que je modélise au fur et a mesure que je code, quand j´ai fini de coder CL_Stac ( qui est la pile de ma machine virtuel), je code CL_Srom ( mémoire a accès séquentiel) etc...

Mais je n´ai pas une vue d´ensemble.

Le truc c´est que ces classe n´ont rien a faire entre elle, mais mon problème est qu´une autre classe pas encore présente qui contient des drapeaux ( flags) que l´on peut modifier quand on exécute du code et qui modifie le fonctionnement d´autre composant.

Mais tu as raison, en y réflechisant, je me suis aperçue, que tout ça pouvait être géré par la classe CL_Machine, donc c´est bon puiceque c´est le truc centrl.

Par contre, c´est quoi un diagramme de classe en UML ? si ça ne te dérange pas de ma l´expliquer sommairement.

Aucun probleme.
UML est un ´langage´ qui permet de modeliser plus ou moins precisement ( selon la volonté) un programme ( ou bien d´autre chose) sous une forme graphique.
Il s´adapte tres bien a la programmation orientée objet.
Pour plus d´info il y a http://uml.free.fr

Pour ma part, je commence toujours a modeliser une application C++ avant de la codée. Lors de la modelisation on s´appercoit vite de ce qu´il faut faire pour faire un prog bien structuré, modulaire et évolutif.
Je peux te donné pour exemple le diagrame de classe du moteur graphique sur lequel je planche de temps en temps.
http://membres.lycos.fr/ewok1/src/UML1.png
J´ai pas vraiment regarder si il etait tres rigoureux mais il me permet de structurer mon programme en limitant les relations inter-objets inutiles, en remarquant les parties a regroupées et tout le reste.
Bonne lecture ; -p

Je connais très mal UML, habitué que je suis à utiliser l´analyse organique et l´analyse Merise et ceci bien avant que je découvre la POO.