Pointeurs et classes : besoin d'éclaircissements

Version imprimable

27/07/2010, 11h31
Kaluza

Pointeurs et classes : besoin d'éclaircissements
Bonjour.

Je me mets doucement à Qt, et j'aurai plusieurs questions relatives aux pointeurs et aux classes. En effet, on trouve plusieurs types de déclarations et je voudrais être certain de bien comprendre. Pour cela, je prendrais des exemples avec une "QString _chaine"

1) Sans pointeurs
Tout d'abord la méthode pour définir des variables membres classiques :
Déclaration dans le header du type :
Code:

1 2 private : QString _chaine
La _chaine est vraiment "membre" de la classe, elle est déclarée à la création de la classe et est détruite à la destruction de celle-ci. Dans n'importe quelles fonction membre de la classe je peux faire appel à _chaine et exécuter des fonctions du type

Code:

_chaine.resize(10)

2) Avec pointeurs
Maintenant, je peux décider de passer par des pointeurs et c'est apparemment ce qu'il est courant d'utiliser avec Qt.
Déclaration dans le header :
Code:

1 2 private : QString *_chaine
Ensuite, il faut obligatoirement passer par des allocation/désallocation de mémoire dans les fonctions membres de la classe :
Code:

1 2 _chaine = new QString delete chaine
Avec cette méthode j'ai plusieurs questions :
2-1) L'allocation doit-elle se faire obligatoirement dans le constructeur de la classe et la désallocation dans le destructeur ? Ce que je veux dire par là c'est "la pratique d'une programmation "propre" veut-elle que lorsqu'une variable membre est déclarée en tant que pointeur on l'initialise dans le constructeur et on la delete dans le destructeur " ?
2-2) Si on ne delete pas le pointeur dans le destructeur que se passe-t-il concrètement ?
2-3) Si la réponse a la première question est "non" alors cela signifie que l'on peut très bien avoir des "_chaine = new QString" dans plusieurs fonctions membres de la classe : n'est-ce pas un peu la pagaille du coup au niveau de l'allocation/désallocation ?

3) Avec pointeurs, autre version
3ème syntaxe, que j'avoue avoir un peu du mal à comprendre à quoi elle sert et quelle sont les subtilités. Il s'agit de la syntaxe :

Code:

QString *_chaine = new QString ("Bonjour")

3-1) Dans ce cas là il s'agit à la fois de la déclaration du pointeur et de l'allocation en mémoire c'est çà ?
3-2) Si j'ai bien compris ce type de syntaxe permet de définir non pas des variables membres, mais des variables locales à certaines fonctions membres d'une classe. Et c'est là que cela devient plus difficile à comprendre pour moi : que se passe-t-il si l'on ne fait pas de "delete _chaine" à la fin de l'exécution de la fonction membre ? La variable locale est-elle automatiquement détruite à la fin de l'exécution de la fonction membre ?
Merci de m'éclairer sur ce point.

En tous les cas si vous avez des éclaircissements à m'apporter je suis preneur ;)
27/07/2010, 11h37
ram-0000

Citation:

Envoyé par Kaluza

La _chaine est vraiment "membre" de la classe

Oui

Citation:

Envoyé par Kaluza

elle est déclarée à la création de la classe et est détruite à la destruction de celle-ci.

Je dirais plutôt définie
mais oui elle est définie à la création de la classe et détruite à la destruction de la classe.

Citation:

Envoyé par Kaluza

Dans n'importe quelles fonction membre de la classe je peux faire appel à _chaine et exécuter des fonctions du type

Code:

_chaine.resize(10)

Oui à la condition que la fonction membre de la classe ne soit pas une fonction static.
27/07/2010, 12h36
haraelendil

2-1)
Tu n'est pas obligé d'instancié ta variable dans le constructeur, mais si tu ne le fait pas, tu devras tester si ton pointeur n'est pas nul à chaque fois que tu veux l'utiliser. Ca peut être utile de faire comme ça dans certain cas, mais dans la grande majorité, un instanciation dans le constructeur est bien plus simple.

2-2) L'espace mémoire ou se trouve ta chaine ne sera jamais libéré, si tu as beaucoup d'instances de cette classe qui sont crées, ça finira pas ronger ta mémoire jusqu'à ce qu'y en ait pu de disponible, ça s'appelle une fuite mémoire.

2-3) Oui, c'est la pagaille, il faut tester si ton pointeur est valide à chaque utilisation, et vérifier si il faut faire un delete avant chaque new

3-1) Oui

3-2) Oui la variable locale est détruite à la fin de la fonction membre, mais si celle-ci est un pointeur classique, le bout de mémoire sur lequel elle pointe ne le sera pas, fuite mémoire, comme en 2-2

Citation:

Envoyé par Kaluza

Maintenant, je peux décider de passer par des pointeurs et c'est apparemment ce qu'il est courant d'utiliser avec Qt.

Attention il est en effet courant d'utiliser l'allocation dynamique dans Qt mais uniquement avec les classes qui héritent de QObject. En effet, à leur création, on peut leur donner un parent. Dans Qt c'est le parent qui s'occupe de la destruction des ses fils, tu n'as donc pas a t'en occuper.

Ici tu utilise un QString qui n'hérite pas de QObject et qui ne peut donc utiliser cette mécanique. A priori pour une simple QString la solution 1 est plus adapté (mais bon tout dépend de ce que tu veux faire).

voici un exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class Dialog : public QDialog { Q_OBJECT private: QPushButton* bouton1; public: Dialog(QWidget *parent = 0): QDialog(parent) { bouton1 = new QPushButton("bouton1",this); QPushButton* bouton2 = new QPushButton("bouton2",this); } };
ici le deuxième argument du constructeur de QPushButton est le parent que l'on souhaite donné a notre bouton. Ainsi, même si j'ai créer dynamiquement mes boutons je n'ai pas a les détruire moi même avec un delete, ce sera fais automatiquement lorsque l'instance de ma classe Dialog sera elle même détruite.

27/07/2010, 14h02
3DArchi

Bonjour,
Le C++ propose 2 gestions de la mémoire : une gestion automatique et une gestion manuelle.
La gestion automatique est celle utilisée lorsque tu déclares des variables par valeur (membre d'une classe, locale à une fonction, variable globale). Le C++ s'occupe tout seul d'obtenir la mémoire nécessaire et d'appeler le constructeur de la variable au moment opportun. De même, il appelle le destructeur et relâche la mémoire utilisée lorsqu'il le faut. Cette gestion est liée à la portée de la variable (celle de la fonction ou du bloc pour une variable locale, celle de l'objet la contenant pour un membre d'une classe).

Une autre façon est de gérer manuellement, c'est à dire par le développeur, la durée de vie des variables. Cela se fait avec new et delete. new réserve la mémoire nécessaire et appelle le constructeur. delete appelle le destructeur puis libère la mémoire réservée. Les pointeurs permettent de récupérer l'adresse sur l'objet alloué et construit. L'avantage est que la durée de vie d'une variable peut être différente de celle qui contient cette variable. Ainsi, le membre d'une classe peut avoir une durée de vie plus courte que la variable qui la contient. Un autre avantage (qui n'est pas spécifique au C++ mais aux architectures PC) est que les allocations automatiques et les allocations dynamiques ne se font pas au même endroit : la pile pour celles gérées par le compilateur, le tas pour celles gérées manuellement. La pile est une zone en général plus petite que le tas et ne permet donc pas de stocker des variables trop importantes en taille. Les inconvénients de la gestion manuelle des pointeurs sont connus et cette gestion dynamique est souvent source de bug dont les classiques restent :
=> fuite mémoire : oubli d'un appel de delete sur une variable allouée dynamiquement ;
=> utilisation d'une variable libérée : on appelle delete mais on continue d'utiliser le pointeur sur la variable ;
=> double delete : comme précédemment, on appelle delete plusieurs fois sur la même zone mémoire ;
etc.
Pour cela, il existe une solution : les pointeurs intelligents ! Ce tutoriel présente la problématique et les pointeurs intelligents du langage. Qt possède ses propres pointeurs intelligents mais le concept reste le même.

Ceci dit, pour répondre à tes questions :

Citation:

2-1) L'allocation doit-elle se faire obligatoirement dans le constructeur de la classe et la désallocation dans le destructeur ? Ce que je veux dire par là c'est "la pratique d'une programmation "propre" veut-elle que lorsqu'une variable membre est déclarée en tant que pointeur on l'initialise dans le constructeur et on la delete dans le destructeur " ?

Non. Ce serait presque le contraire : si tu alloues systématiquement dans le constructeur et que tu libères systématiquement dans le destructeur, alors pourquoi t'occuper de la gestion de la mémoire manuellement ? Utilise une variable par valeur et laisse le compilateur s'en occuper automatiquement. Surtout pour des variables de type QString. La seule raison serait d'avoir une variable membre par pointeur qui suit strictement la durée de vie de l'objet la contenant serait une taille trop importante. Mais là il faut penser pointeurs intelligents :)

Citation:

2-2) Si on ne delete pas le pointeur dans le destructeur que se passe-t-il concrètement ?

La zone mémoire n'est pas libérée. C'est ce qu'on appelle une fuite mémoire. Si tu fais ça de nombreuses fois, à un moment toute ta mémoire sera marquée comme réservée et utilisée et ton application ne pourra plus allouer de nouveaux objets dynamiquement.

Citation:

2-3) Si la réponse a la première question est "non" alors cela signifie que l'on peut très bien avoir des "_chaine = new QString" dans plusieurs fonctions membres de la classe : n'est-ce pas un peu la pagaille du coup au niveau de l'allocation/désallocation ?

Oui on peut et oui c'est la pagaille. D'où les pointeurs intelligents ;)

Citation:

3-1) Dans ce cas là il s'agit à la fois de la déclaration du pointeur et de l'allocation en mémoire c'est çà ?

Beaucoup de choses se trament derrière cette innocente ligne :

Code:

QString *_chaine = new QString ("Bonjour")

QString *_chaine définit un pointeur de type QString
= initialise le pointeur à gauche avec la valeur de droite
new QString ("Bonjour") : alloue la mémoire nécessaire à QString et appelle le constructeur à un argument (probablement QString::QString ( const char * str )) et retourne un pointeur de type QString sur cette nouvelle variable.

Citation:

3-2) Si j'ai bien compris ce type de syntaxe permet de définir non pas des variables membres, mais des variables locales à certaines fonctions membres d'une classe. Et c'est là que cela devient plus difficile à comprendre pour moi : que se passe-t-il si l'on ne fait pas de "delete _chaine" à la fin de l'exécution de la fonction membre ? La variable locale est-elle automatiquement détruite à la fin de l'exécution de la fonction membre ?
Merci de m'éclairer sur ce point.

Comme expliqué plus haut, si tu t'engages à gérer la mémoire manuellement avec new alors il est de ta responsabilité de la détruire avec delete. Si tu ne le fais pas, alors tu peux avoir une fuite mémoire. Le delete peut avoir lieu dans la fonction. Cependant si l'adresse est transmise à l'extérieur de la fonction, ce delete peut très bien avoir lieu ailleurs. Mais comme dit jusqu'à présent, ceci est une source récurrente de bugs. D'où les pointeurs intelligents :lol:

C'est un autre débat, mais je m'interroge sur l'opportunité d'apprendre conjointement le C++ et Qt. Qt est un framework spécifique. Peut être ne faut-il pas mélanger les deux : d'abord acquérir de bonnes bases en C++ puis si cela t'intéresse aller vers Qt.

Merci à tous pour votre aide et vos explications, j'y vois déjà un peu plus clair.
J'ai encore 3 questions :

1) Dans le cadre de la programmation de classes Qt (donc héritées de QObject) y-a-t-il des règles "communément admises" de quand on doit utiliser des pointeurs ou des variables normales ? Parce qu'en regardant les exemples fournis avec le SDK, très très très souvent, on utilise des pointeurs.

2) Questions beaucoup plus terre à terre maintenant :
Mon but est d'afficher une QPixmap en passant par un QPainter, les deux étant variables membres d'une classe. La fonction de QPainter en question est :
void drawPixmap ( int x, int y, const QPixmap & pixmap )
Si je procède comme suit, cela ne fonctionne pas :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class MaClasse : public QWidget { Q_OBJECT public : MaClasse(const QString &fichierimage, QWidget *parent=0) private : QPainter *_painter QPixmap *_monimage }; MaClasse::MaClasse(const QString &fichierimage, QWidget *parent):QWidget(parent) { _painter=new QPainter(); _monimage=new QPixmap(fichierimage); _painter->drawPixmap(0,0,_monimage) }
Erreur : no matching function for call to 'QPainter::drawPixmap(int,int,QPixmap*&)

Si je procède comme cela, sans passer par des pointeurs pour le QPixmap, ça fonctionne bien :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class MaClasse : public QWidget { Q_OBJECT public : MaClasse(const QString &fichierimage, QWidget *parent=0) private : QPainter *_painter QPixmap _monimage }; MaClasse::MaClasse(const QString &fichierimage, QWidget *parent):QWidget(parent) { _painter=new QPainter(); _monimage.load(fichierimage); _painter->drawPixmap(0,0,_monimage) }
Ma question est : comment faire fonctionner la première méthode en passant par des pointeurs pour à la fois QPainter et QPixmap.

3) Enfin, j'ai un petit problème de "setter" en passant par des pointeurs.
En effet, si je met
Code:

1 2 3 4 5 6 7 8 inline void setPath(const QString &path) { _path=path; } ... avec un peu plus loin .... private : QString *_path
ça ne fonctionne pas, alors que le code suivant fonctionne (sans pointeur):
Code:

1 2 3 4 5 6 7 8 inline void setPath(const QString &path) { _path=path; } ... avec un peu plus loin .... private : QString _path
Je sais que c'est le "=" qui pose problème mais je ne vois pas comment faire un setter quand je passe par des pointeurs.

Merci beaucoup ;)

27/07/2010, 16h11
haraelendil

1)
Qt fournissant un système de gestion de mémoire (et surtout de la destruction) de père en fils, il est intensivement ancré dans le framework que tous les objets héritant de QObject sont utilisés avec des pointeurs uniquement.
Rien ne t'oblige à le faire, mais comme la majorité des argument suivent cette logique, si tu ne le fait pas, tu va passer ton temps à mettre des & et des * pour passer de valeur à adresse et vice versa.

Par contre, pour les objets n'héritant pas de QObject (notamment ici QString et QPixmap), ils ont tendance à être utilisés par valeur, comme des variables classique (donc pareil, si tu veux pas galérer pour rien, tu devrais en faire de même)

2)
Déjà, des problèmes:
si tu veux que ton painter dessine dans ton widget, il faut lui passé un pointeur sur ce widget (sinon il ne sait pas ou dessiner).
Donc quand tu appelle le constructeur de ton QPainter, il faut lui passé this en paramètre.
Cela dit, le painter est sensé effectuer ses actions de dessin dans une méthode prévue à cet effet ( void QWidget::paintEvent(QPaintEvent*); ), qu'il te faut redéfinir dans ta classe si tu veux dessiner dans ton widget, je ne sais pas trop ce que va donner le résultat si tu dessine dans le constructeur...

Enfin, la réponse à ta question:
drawPixmap prend en 3e paramètre un QPixmap, et non pas un pointeur sur un QPixmap, pour faire marche ta 1ere version, il faudrait faire

Code:

_painter->drawPixmap(0, 0, *_pixmap);

Enfin, c'est la même chose pour la 3.
Si ta string est déclarée par valeur, l'opérateur = marche, par contre si le premier est un pointeur et le deuxième une instance de QString, ça ne marchera pas.

PS: comme le dit Archi, tu a l'air d'être débutant en C++, aussi je ne saurai que trop te recommander de déjà commencer par apprendre le C++ "classique" avant de te mettre au framework Qt, qui fait appel à beaucoup de notions qui ont l'air de t'échapper.
27/07/2010, 16h24
atttchoum

Vu tes problèmes je ne peut qu'appuyer 3DArchi

Citation:

C'est un autre débat, mais je m'interroge sur l'opportunité d'apprendre conjointement le C++ et Qt. Qt est un framework spécifique. Peut être ne faut-il pas mélanger les deux : d'abord acquérir de bonnes bases en C++ puis si cela t'intéresse aller vers Qt.

1)

Citation:

Dans le cadre de la programmation de classes Qt (donc héritées de QObject)

Justement toute les classes de Qt n'héritent pas de QObject (QString par exemple mais aussi QPainter).
En revanche pour toute les classes qui héritent de QObject il est vrai qu'elles sont souvent manipulées par pointeur pour les raisons que j'ai déjà expliqué mais aussi car beaucoup de fonction prenne des pointeur en paramètre dans Qt.

2) et 3) :
Tu sembles confondre pointeur et référence.

Je te conseil vivement de bien comprendre ces notions (cf les tuto et la FAQ) avant de te mettre à Qt car le système parent/enfant risque de te faire prendre de mauvaises habitude si tu ne comprend pas ce que cela implique.
27/07/2010, 16h58
Kaluza

Citation:

PS: comme le dit Archi, tu a l'air d'être débutant en C++, aussi je ne saurai que trop te recommander de déjà commencer par apprendre le C++ "classique" avant de te mettre au framework Qt, qui fait appel à beaucoup de notions qui ont l'air de t'échapper.

En fait j'ai commencé le C++ il y a deux ans de mon côté (sans maîtriser préalablement le C), j'ai travaillé sur quelques projets de "computation", mais à part avec Qt, je n'ai jamais eu vraiment besoin de travailler avec des variables définies au travers de pointeurs à l'intérieur de classes. Le concept d'héritage est à peu près clair, c'est seulement qu'au niveau des pointeurs j'ai encore une conception assez floue des choses ... et Qt est pour moi la première occasion d'être confronté à ces problèmes. C'est pour cela que je bosse en même temps cet aspect du C++ et Qt.

Je pense que je vais approfondir les exemples fournis avec le SDK de Qt, parce qu'en gros je sais "faire fonctionner" Qt pour parvenir à ce que j'ai en tête, mais je voudrais prendre de bonnes habitudes et éviter de coder ça n'importe comment (parce que pour l'instant c'est un peu le cas).

Déjà, si j'ai bien compris, tout ce qui dérive de QObject est en général passé par pointeurs alors que ce n'est pas forcément le cas des autres composants de Qt.
28/07/2010, 01h01
koala01
Salut,

Citation:

Envoyé par Kaluza

En fait j'ai commencé le C++ il y a deux ans de mon côté (sans maîtriser préalablement le C),

Contrairement à ce qu'essayent de faire croire beaucoup de cours et de tutoriaux, la connaissance de C n'est vraiment pas un prérequis pour l'apprentissage de C++, même si, en pratique, elle (la connaissance de C) peut s'avérer être un avantage certain tant il est fréquent de rencontrer un odieux mélange des deux...

Citation:

j'ai travaillé sur quelques projets de "computation", mais à part avec Qt, je n'ai jamais eu vraiment besoin de travailler avec des variables définies au travers de pointeurs à l'intérieur de classes.

Tu as surement eu de la chance... ou très bien choisi les projets auxquels tu t'attelais :P

Citation:

Le concept d'héritage est à peu près clair,

C'est déjà pas mal :D

Citation:

c'est seulement qu'au niveau des pointeurs j'ai encore une conception assez floue des choses ...

Reprenons donc depuis le début:

Un pointeur n'est jamais qu'une variable un peu particulière dans le sens où elle représente... l'adresse mémoire à laquelle on va retrouver l'objet du type indiqué.

C'est souvent utilisé en relation avec ce que l'on appelle communément la "gestion dynamique de la mémoire" qui nous permet de prendre la responsabilité du moment où l'on demande de réserver un espace mémoire suffisant pour représenter un objet et du moment où l'on décide de libérer cet espace mémoire parce que l'on n'en a plus besoin.

En C++ la réservation de mémoire se fait avec new (ou new[]) qui provoque automatiquement la construction de l'objet (en invoquant le constructeur) une fois que la mémoire est disponible, et la libération de mémoire se fait avec delete (ou delete[]) qui provoque automatiquement la destruction (en invoquant le destructeur de l'objet) avant de libérer la mémoire.

Grâce à ce système, et pour autant que l'on veille à récupérer le pointeur, il est possible de faire en sorte qu'un objet existe et que l'espace mémoire nécessaire pour le représenter reste considérée comme utilisée bien au delà de la portée dans laquelle l'objet est construit, pour le réutiliser "plus tard".

Cela nous autorise également le raisonnement inverse, à savoir: sous réserve de transmettre le pointeur comme argument, d'utiliser un objet qui sera construit (et détruit) parfois bien loin de la fonction qui l'utilise.

Contrairement à une référence qui fera systématiquement... référence à un objet existant, un pointeur peut faire référence à... rien du tout, pour autant que nous lui ayons affecté la valeur NULL.

Si l'on estime, pour une raison ou une autre (et elles sont nombreuses :D) qu'une variable peut représenter un objet qui n'existe pas (ou qui n'existe pas encore), il est préférable d'utiliser un pointeur, mais il s'agira alors de prendre certaines précautions, comme:
- affecter la valeur NULL au pointeur chaque fois que l'objet n'existe effectivement pas
- vérifier que le pointeur ne contient pas la valeur NULL avant toute tentative d'accès à l'objet référencé.
En outre, lorsqu'un objet de type quelconque doit disposer d'un membre qui fasse référence à un autre objet de type identique, nécessite un espace mémoire clairement défini pour représenter l'adresse mémoire à laquelle trouver l'objet du type indiqué, et ce, quel que soit le type pointé: cet espace correspond au nombre de bytes nécessaires pour représenter l'ensemble des adresses mémoires accessibles sur le système utilisé (classiquement 32 ou 64 bits (4 ou 8 bytes), sur les architectures PC actuelles).

Citation:

et Qt est pour moi la première occasion d'être confronté à ces problèmes. C'est pour cela que je bosse en même temps cet aspect du C++ et Qt.

Et pourtant, je rejoins les autres pour te dire qu'il serait préférable d'éviter les "interférences" que pourrait provoquer Qt et de n'envisager de t'intéresser aux pointeurs qu'au travers du langage lui-même :aie:

Citation:

Je pense que je vais approfondir les exemples fournis avec le SDK de Qt, parce qu'en gros je sais "faire fonctionner" Qt pour parvenir à ce que j'ai en tête, mais je voudrais prendre de bonnes habitudes et éviter de coder ça n'importe comment (parce que pour l'instant c'est un peu le cas).

L'optique est saine, mais c'est justement parce que Qt met en place une politique "particulière" de gestion de la mémoire allouée avec new qu'il serait sans doute préférable de ne pas utiliser ce framework (excellent au demeurant) pour l'apprentissage des bonnes habitudes

Citation:

Déjà, si j'ai bien compris, tout ce qui dérive de QObject est en général passé par pointeurs alors que ce n'est pas forcément le cas des autres composants de Qt.

Il se fait que, justement, les pointeurs sont principalement utilisé en C++ pour assurer le polymorphisme, lorsqu'il est question de gérer des collections d'objets dont les types interviennent dans une hiérarchie de classe, comme s'il s'agissait d'objet du type de base.

Si tu as compris le principe de l'héritage, essaye maintenant de t'intéresser au polymorphisme (et donc aux fonctions virtuelles) en dehors de toute utilisation de Qt.

Cela te sera bien plus profitable, et, surtout, ne dit on pas qu'il faut savoir marcher avant de vouloir courir :question:
28/07/2010, 07h56
3DArchi
D'abord, je ne défini aucun membre par pointeur mais par pointeur intelligent :mouarf:

Citation:

Envoyé par Kaluza

Déjà, si j'ai bien compris, tout ce qui dérive de QObject est en général passé par pointeurs alors que ce n'est pas forcément le cas des autres composants de Qt.

A mon avis, il y a différents points :
(1) l'interface de Qt demande un pointeur pour certaines fonctions ;
(2) l'interface de Qt demande une valeur/référence pour certaines fonctions ;
(3) tu définis des membres/variables dont tu gères la mémoire dynamiquement à l'aide de pointeur ;
(4) tu définis des membres/variables par valeur pour laisser une gestion automatique de la mémoire.

(1) et (2) ne sont absolument pas liés (enfin presque) à (3) et (4) : les opérateurs * et & permettant respectivement de déréférencer un objet ou de récupérer son adresse :
Code:

1 2 3 4 5 6 7 8 9 void fonction_1(TYPE const &); void fonction_2(TYPE const *); TYPE var; fonction_1(var); fonction_2(&var); TYPE* p_var; fonction_1(*p_var); fonction_2(p_var);
A mon avis, se poser la question de la définition de membre par pointeur ou par valeur ne doit pas être (au début) guidé par le framework. Il faut d'abord en comprendre l'intérêt, les contraintes et les limites de ces deux gestions en C++ puis voir comment cela s'articule avec ce que t'impose Qt.

Avoir une variable membre par valeur ou par pointeur va dépendre de différents critères déjà plus ou moins évoqués : la taille, la durée de vie, la sémantique (de valeur => valeur, d'entité => ça dépend, RAII => valeur), et j'en oublie probablement.

Tu dis avoir déjà des connaissances en C++ et en objet. A toi de voir si tu butes d'abords sur le langage ou sur le framework.
Qt possède une rubrique à part entière avec son forum, ses tutos, sa F.A.Q., etc... Pour les questions vraiment spécifiques au framework, c'est plutôt par là-bas que tu auras les meilleurs réponses aux problèmes Qt.