Oui, c´est grossier, mais c´est aussi la première chose qui m´est venu à la tête quand je me suis aperçu qu´on ne pouvait pas avoir de constructeurs ou destructeurs privés en C++, ce qui fait que je ne peux pas interdire leur surcharge.

Et ça c´est plutot chiant quand on avait en tête de faire cela depuis plusieurs semaines.

Quelqu´un ne connaitrait-il pas un moyen de contourner cette règle à la . ..?

Merci d´avance.

Ca serait plutôt ennuyeux d´avoir un constructeur ou destructeur privé ! ! Ton objet ne pourrait jamais être créé ou détruit !

Pouruqoi souhaites tu interdire la surcharge ?

En fait voilà, la classe dont le constructeur et destructeur ne doivent pas etre surchargé est destinée à etre héritée.
Le blem, c´est que le constructeur et le destructeur modifie les valeurs privées d´autres objets, grâce à une liaison d´amitié. Pour éviter d´avoir à les surcharger, j´y ai mis aussi des fonctions virtuelles appelées par le constructeur et le destr., mais cette fois-ci simplement protégées.
Donc voilà, il n´est peut-etre pas obligatoire d´interdire la surcharge pour le fonctionnement, ce serait quand même vachement plus lisible, simple, et surtout ça éviterais quelques méchants bogues si on arrivais à le faire.

Une idée?

Si je comprends bien le problème tu aimerais que les classes qui héritent ne modifient pas les valeurs privées des classes amies de la classe mère ?

Etant donné que le code du constructeur/destructeur de l´objet qui est herité est appelé automatiquement a la destruction de l´objet qui en herite, j´ai du mal a voir le probleme de la surchage qui pose probleme...
Aurais tu plus d´info sur le probleme ?

" Pour éviter d´avoir à les surcharger, j´y ai mis aussi des fonctions virtuelles appelées par le constructeur et le destr."

NE FAIT JAMAIS D´APPEL DE FONCTION VIRTUELLE DANS UN DESTRUCTEUR ! !!

C´est le plantage assuré si ta classe est dérivée, pour la simple et bonne raison que la vftable est détruite pendant le destructeur, donc si tu appeles une fonction virtuelle de ta classe mere, la vftable sera déja détruite puisque son destructeur sera appelé avant le tiens.

Et oui, encore un bug du C++

ya pas de bugs en C++ t´inkete tout a été pensé.

gamerfou2 > au fait les classes amies vaut mieu eviter c un peu kk comme prog.

<<Oui, c´est grossier, mais c´est aussi la première chose qui m´est venu à la tête quand je me suis aperçu qu´on ne pouvait pas avoir de constructeurs ou destructeurs privés en C++, ce qui fait que je ne peux pas interdire leur surcharge.
Et ça c´est plutot chiant quand on avait en tête de faire cela depuis plusieurs semaines.
Quelqu´un ne connaitrait-il pas un moyen de contourner cette règle à la . . .?
Merci d´avance.>>
Cherches donc le design pattern SINGLETON, il pourrait t´aider à resoudre quelques problèmes.

PS: et oui, on peut avoir des constructeurs privés

ex: ( origine: http://infonomade.linuxfr.org/articles/brillant/designPattern.html)

public CanvasFactory {
/** Donnée de classe contenant l´instance courante */
private static CanvasFactory instance = new CanvasFactory();

/** Constructeur privé interdisant l´instanciation en dehors de cette classe */
private CanvasFactory ( ) {}
/** Singleton de la classe courante */
public static CanvasFactory getInstance() { return instance; }
. ..
}

Typiquement l´usage de la classe CanvasFactory se fera sous la forme suivante :
CanvasFactory cf = CanvasFactory.getInstance();

Le singleton limite le nombre d´instance en mémoire.

gamerfou2 > au fait les classes amies vaut mieu eviter c un peu kk comme prog.

? ? c´est pas moi qui utilises ca je te signale . .. mais c´est Superdindon qui en a parlé

Qu´est-ce que vous avez contre les classes amies? C´est superpratique, et pour le moment je n´ai jamais eu de bogue avec. Le seul truc naze, c´est qu´il n´y a aucun moyen de faire hériter les fonctions d´amitié, mais à part ça c´est du tout bon, comparé à d´autres langages.

Par contre OK -Q-, il est possible d´avoir des constructeurs privés, en déclarant d´autres classes ou fonctions amies ou en utilsant ton procédé, mais au final j´ai toujours le meme problème, puisque les objets ne peuvent être instanciés seulement par les amies de la classe, ou par une fonction membre qui peut être aussi surchargée.

D´accord avec toi, Kouic, j´avais pas fait attention. Je vais quand même tester le bogue de Dino mais il reste plus que le constructeur qui pose vraiment problème. Et pour ça j´en suis au même point qu´avant.

lol je comprend rien de rien a ce que vous raconter

poliment : coment vous en etes arriver a un tel niveau ? car a premiere vu c´est du charabia or je ne suis pas plus con qu´un autre.
par ou débuter ?

Si tu débutes, c´est normal que tu ne comprennes rien. ( Moi j´ai peu d´experience tout de même).
Car, c´est comme pour les maths, au début tu ne sais faire que des additions ( que tu as appris par coeur, par exemple la table de trois: 1+3=4, 2+3=5, 3+3=6, . ..) puis ensuite tu apprends des choses plus dur ( les tables de multiplications dans le cas le plus simple). En programmation c´est pareil.

Qu´est-ce que vous avez contre les classes amies?

Bin justement c´est peut etre pratique mais c´est hyper crade au niveau de la conception... C´est un peu le même principe que le goto.

La programmation objet est basée sur l´écriture de classes et la protection de ses composants ( attributs/méthodes).
Avec l´utilisation des fonctions/classes amies tu fais "sauter" ce principe.

Un constructeur privé c´est possible.
Perso je l´utilise souvent pour limiter le nombre d´instance a une classe. Cette classe implemente une fonction statique permettant de gerer le nombre d´instance et de faire appel au contructeur.

Mince, c´est la même chose aussi pour les constructeurs. Bon bah merci beaucoup, j´ai tout ce qu´il faut pour me remettre au boulot.

"Ca serait plutôt ennuyeux d´avoir un constructeur ou destructeur privé ! ! Ton objet ne pourrait jamais être créé ou détruit ! "

class KToto
{
private:
KToto(){};
public:
static KToto* AllocToto()
{
return new KToto();
}
};

int _tmain(int argc, _TCHAR* argv[])
{
KToto* pToto;

pToto = KToto::AllocToto();
return 0;
}

Voila, c´est juste pour contredire GamerFou ; )

Voila, c´est juste pour contredire GamerFou

Mouarf! je parie que tu en rêvais depuis des mois! ( joyeux noel, un peu tard je l´avoue)

Pauvre toi...