c'est rigolo comme on peut enchainer les appels de méthodes quand les valeurs de retour sont des objets
m_ModuleList->back()->manageEvents(&Events, &Messagebox)->dispPlane(&m_MainScreen);
Comment ça c'est pas bien pour la lisibilité ?
</>
m_ModuleList->back() ->manageEvents(&Events, &Messagebox) ->dispPlane(&m_MainScreen);
void maFonction(Objet & objet); Objet monObjet; maFonction(monObjet); // l’objet n’est pas copié, c’est son adresse qui est passée, comme si tu avais écrit &monObjet
), du moins avec mon niveau de C++, de design et de spec. Donc je m'en passe. Avec un pointeur, je sais ce qui se passe.
Et oui, ya rien à comprendre mais c'est comme ça
Folco (./908) :
"Si chaque objet fais gaffe à détruire, dans sont destructeur, les autres objets et espaces mémoires qu'il a alloué, alors on ne leakera pas de mémoire".
GoldenCrystal (./909) :
Après tout, le double-free est tout aussi méchant que la fuite de mémoire
Kevin Kofler (./910) :
(même si les systèmes d'exploitation récents ont [...]
typedef const class Vector &CVector;
class Vector {
int x, y;
public:
Vector(int x, int y) : x(x), y(y) {}
Vector operator + (CVector v2) {
return Vector(x + v2.x, y + v2.y);
}
};Brunni (./911) :
C'est cool que tu t'intéresses toujours à Windows
Kevin Kofler (./910) :
Bah oui, c'est évident. On appelle ça le principe RAII.
Sauf que le fait de sortir de mes objets par une exception me posait pas mal de questions.
/*
Some classes do not permit copies to be made of an object. These
classes contains a private copy constructor and assignment
operator to disable copying (the compiler gives an error message).
*/
#define Q_DISABLE_COPY(Class) \
Class(const Class &); \
Class &operator=(const Class &);
(tu dois sûrement déjà avoir une idée puisque tu te poses la question). Et oui ça sert au polyomrphisme.
), mais pour l'instant considère que alloué par la classe A = libéré par la classe A et rien d'autre.
)Folco (./928) :Ça c'est pas vraiment (pas du tout) une manière propre de faire.
Ca signifie donc que la classe mère comporte un constructeur, alors qu'on pourrait s'en passer si la classe dérivée construisait les objets protected. Ok.
Sinon, g++ refuse que mon destructeur de classe mère ne soit pas virtuel, pourquoi ? Quelle est la conséquence que ce destructeur soit virtuel ?Tiens je savais pas que le compilo t'interdisait carrément les destructeurs non virtuels ^^
Donc si tu déclares A* truc = new BAlors, le compilateur sait juste que "*truc" est de type A. Si ton destructeur n'est pas virtuel, il va apeller le destructeur de A, puisque il sait seulement que *truc est de type A.Il va en fait être redéfini par la classe dérivée, mais les deux destructeurs seront appelés simultanément lors de la destruction de l'"objet dérivé" ? (CROSS !!! Je tombe sur ça GC, mais pourquoi ???)Ils ne sont pas appelés simultanément. Les éléments de la classe enfant dépendent (potentiellement) des éléments de la classe parent.
Pour continuer le cross, oui, j'ai relu cet après-midi le chapitre sur l'héritage multiple, ça suppose visiblement de bien poser ses mécanismes d'héritages et de virtualisation pour ne pas se faire baiser...Bah, le C++ est un peu trop permissif sur ce point malheureusement, mais si tu te limites à de l'héritage multiple propre comme en C#, Java & compagnie, y'a pas besoin d'énormément de contorsions neurales ^^
Et enfin, je suis dans le cas d'une classe mère jamais instanciée en stand-alone (aucun intérêt, l'objet n'est pas fait pour ça et ne représenterait rien). C'est d'ailleurs pour ça que toutes ses méthodes sont virtuelles, sans implémentation.Ouais, mais dans beaucoup de cas tu auras également besoin d'une classe abstraite, proposant une partie de l'implémentation, et demandant aux enfants d'implémenter le reste. Une classe purement abstraite (une interface), par contre, ne doit pas déclarer quoi que ce soit d'autre que des méthodes virtuelles "pures" (au sens C++).
