Discussion :

[Invité]

Bonjour,
J'avais 2 questions : histoire de comprendre :
=> d'abord les allocations dynamiques : sur leur utilité : sur un des tutos c++ il est dit que les allocations dynamiques de mémoire sont faites quand on ne sait pas combien de place prendra la variable.
Or quand quand je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int n

j'alloue un espace mémoire non-défini à l'avance : mon n peut valoir 10 ou 1000000000, ce qui prendra une place différentes en Ko suivante la valeur du nombre n.

Ensuite dans la POO quand on déclare un objet, disons un pushButton, il suffit syntaxement parlant de mettre la classe devant et ensuite de mettre l'objet : alors pourquoi un new ? Analogiquement c'est comme pour int n sauf qu'à la place on met QPushButton pushButton. Pas besoin de new dans le constructeur... Non ?

=> ensuite le fameux pointeur this qui me perturbe mdr : sur les tutos il est dit qu'il pointe sur l'objet lui-même : en prenant l'exemple du constructeur de la fenêtre principale d'une appli Qt, fichier mainwindow.cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
}

Ce qui me pose problème c'est la dernière ligne : pourquoi ne met-on pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ui->setupUi(*this)

car c'est pas à la valeur pointée que l'on s'intéresse, ici ui, et non pas à l'adresse mémoire de l'objet ui non ?

Merci à vous. Bonne journée.

[omc24]

Bonjour,

j'alloue un espace mémoire non-défini à l'avance : mon n peut valoir 10 ou 1000000000, ce qui prendra une place différentes en Ko suivante la valeur du nombre n.

Ha non, quelque soit la valeur du int, la taille allouée en mémoire reste la même, soit 4 octets.
Ceci est valable pour tous les types.

[Astraya]

=> d'abord les allocations dynamiques : sur leur utilité : sur un des tutos c++ il est dit que les allocations dynamiques de mémoire sont faites quand on ne sait pas combien de place prendra la variable.

L'allocation ne dépend pas du tout de la valeur mais du type. Il allouera pour 1 octets pour char, 2 octets pour short, un int 4 octets (processeur 32 bits) 2 octets(processeur 16bits), float 4 octets, double 8 octets, long double 10 octets, booléen est un int voir 1 bits sur certains compilateurs.
Un int peut avoir une valeur allant -32 768 à 32 767, il prendras quoi qu'il arrive 4 octets. Un unsigned int prendra aussi 4 octets mais pourras allez de 2 147 483 648 à 2 147 483 647.

Ensuite dans la POO quand on déclare un objet, disons un pushButton, il suffit syntaxement parlant de mettre la classe devant et ensuite de mettre l'objet : alors pourquoi un new ? Analogiquement c'est comme pour int n sauf qu'à la place on met QPushButton pushButton. Pas besoin de new dans le constructeur... Non ?

Un new te servira à dire en quelque sorte, je créer un objet, mais je veux gérer ça durée de vie et le détruire quand je le désire. Pour ce faire, je vais donc le mettre dans la mémoire appeler "le tas" et non pas dans la mémoire appeler "la pile".

• Une pile est un espace mémoire bien ordonnancé, un peu comme une pile de livre, si l'on veux retiré les 3 premiers livre, ont devras retiré celui du dessus, puis celui d'encore en dessous et le 3ème.Une pile n'a pas de trou dans la mémoire.

• Un tas, c'est disons, un fourre tout brodelique, aucun ordonnancement. Elle te permet de créer des variables et de pouvoir faire ce que tu désires avec, imagine que au lieu de faire une pile de livre, tu les mets un peu partout sur le sol. Tu veux supprimé le bouquin qui était au milieu de la pile, tu n'a pas besoin de passé par ceux du dessus, tu n'as qu'a "pointer" sur celui que tu veux directement car tu peux le prendre sans bouger les autres bouquins. Le tas à ses avantages et ses inconvénients et n'est pas une solution prioritaire, mais secondaire. Il occasionne un accès plus long que la pile et des trous mémoires.

[Oussapik]

=> ensuite le fameux pointeur this qui me perturbe mdr : sur les tutos il est dit qu'il pointe sur l'objet lui-même : en prenant l'exemple du constructeur de la fenêtre principale d'une appli Qt, fichier mainwindow.cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
}

Ce qui me pose problème c'est la dernière ligne : pourquoi ne met-on pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ui->setupUi(*this)

car c'est pas à la valeur pointée que l'on s'intéresse, ici ui, et non pas à l'adresse mémoire de l'objet ui non ?

Merci à vous. Bonne journée.

this est un pointeur sur l'objet courant. Dans ton constructeur de la classe MainWindow, l'objet courant est de type MainWindow. La méthode setupUi attend un pointeur sur un QMainWindow. this convient donc en tant que paramètre dans la ligne qui te pose problème.

Si tu mettais *this, alors tu passerais l'objet de type QMainWindow et non un pointeur, créant ainsi une copie de l'objet. Dans le corps de la méthode setupUI, tu travaillerais sur la copie de l'objet et cela poserait problème.

En espérant avoir répondu à ta question.

[Steph_ng8]

Un autre intérêt du new :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void uneFonction()
{
    (...)
    UnType obj;
    UnType *ptr = new UnType();
    (...)
}

À la sortie de cette fonction, l'objet obj est détruit.
Autrement dit, la mémoire utilisée pour créer et stocker cet objet, allouée statiquement, est libérée.
Par contre, l'objet pointé par ptr reste valide ; la mémoire utilisée pour sa création et son stockage a été allouée dynamiquement, et reste « valable » tant que l'on ne dit pas explicitement qu'elle doit être libérée (par un delete).

On peut également s'en servir pour allouer une plage mémoire continue (dont tous les éléments sont contigus en mémoire) dont on ne connaît pas la taille à l'avance.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
UnType *plage = new UnType[taille];
(...)
delete[] plage;

[Astraya]

L'allocation dynamique ( ainsi que la référence ) tu permettras aussi d'utiliser le principe du polymorphisme. Non disponible avec une instanciation statique (standard)

[Invité]

Merci pour vos réponses.
=> en ce qui concerne l'allocation dynamique c'est nous gérons la durée de vie de la variable en fait : ça donne plus de maîtrise au développeur
Maintenant je vais reprendre mon exemple : lorsque je crée un bouton : on fait une allocation dynamique car on ne connaît pas les dimensions du bouton (longueur x largeur) : il peut être petit comme énorme et prendre une place différente, donc on fait une allocation dynamique... Non ?

[Steph_ng8]

Non, ça n'a rien à voir.
Peu importe quel sera le rendu final, l'objet est stocké de la même manière en mémoire.
Les dimensions du boutons sont stockés en interne par des entiers ; comme on l'a dit plus haut, quelle que soit la valeur d'un entier il prend la même place en mémoire.

Il faut que tu comprennes que toutes les instances d'un type/d'une classe donné(e) ont exactement la même taille en mémoire.
C'est impératif, sinon le compilateur ne saurait pas quelle taille allouer, que l'allocation soit statique ou dynamique.
Mais je ne vais pas entrer dans les détails, je ne m'y connais pas assez.

Tu remarqueras qu'on ne passe jamais la taille de l'objet que l'on veut allouer.
C'est le constructeur qui se charge de définir la taille nécessaire, en fonction des paramètres passés ?
Ah non, certainement pas.
L'allocation est faite AVANT l'exécution du code du constructeur appelé.

Pourquoi exactement faut-il faire une allocation dynamique dans ton cas, je ne saurais répondre précisément.
C'est vrai qu'on pourrait créer le bouton statiquement et modifier ses paramètres après coup si nécessaire.
Mais Qt est un peu particulier.
Il y a un système de parent/enfants, où le parent est responsable de la destruction de ses enfants.
Ça risque de planter s'il y a des allocations statiques dans ce bazar…

PS: Pas sûr que ce soit une bonne idée de se mettre à Qt avant d'avoir une maîtrise raisonnable du C++…

[Astraya]

en ce qui concerne l'allocation dynamique c'est nous gérons la durée de vie de la variable en fait : ça donne plus de maîtrise au développeur

Tu as de meilleur façon de faire ça, l'allocation dynamique n'est pas à utiliser pour se seul motif!
Tu as des blocs {//code}, des fonctions, des classes.

[Invité]

ok eh ben merci pour cet éclaircissement. je retiens surtout le fait qu'avec l'allocation dynamique, on décider quand la variable va mourir et comme je l'ai dit une fois avec les pointeurs : cela semble être un truc assez puissant !
Bonne soirée à vous.

[Astraya]

La bombe H est un outils puissant et pourtant il est déconseillé de sans servir. C'est pareil pour les pointeurs...

[Invité]

Bonjour,
Tu compares la bombe H aux pointeurs ? Un pointeur ça n'a jamais irradié et causé la mort à moyen terme.
Je pense que cela dépend plutôt de la personne qui l'utilise.
Pour moi c'est pas le pointeur qui peut être dangereux mais plutôt la manière avec laquelle on l'utilise.

Je voulais revenir sur le pointeur this car je n'ai toujours pas compris : je reprend le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
}

Ce code pourrait s'écrire aussi comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent)    
{
    QMainWindow=parent;
    ui=new Ui::MainWindow;
    ui->setupUi(this);
}

Donc dans le constructeur de cette classe, les objets sont : QMainWindow et ui
Donc ici c'est bien le pointeur vers l'objet ui non ?
Je ne comprend pas.

Merci et bonne journée.

[Astraya]

Un pointeur ça n'a jamais irradié et causé la mort à moyen terme.

Bas utiliser à toutes les sauces ils peut tué ton programme si ils ne sont aps géré avec la plus grande prudence... et après le garbage de Windows ramasse les cadavres

Je pense que cela dépend plutôt de la personne qui l'utilise.Pour moi c'est pas le pointeur qui peut être dangereux mais plutôt la manière avec laquelle on l'utilise.

Même des gens d'expériences se demande si c'est vraiment utile car ils ne sont pas "memory safe" et beaucoup de développeur les prennent trop à la légère. Beaucoup de language s'en passe.

Je voulais revenir sur le pointeur this car je n'ai toujours pas compris

"this" est un pointeur sur l'objet courant, un pointeur sur l'instance de la classe. Donc un objet statique n'a pas de pointeur "this" puisque ce n'est pas l'instance d'une classe.

Ce qui ce passe ici, c'est simple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ui(new Ui::MainWindow)

On alloue l'espace mémoire nécessaire pour un MainWindow.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ui->setupUi(this);

On dit ici que cette espace mémoire, qui est un MainWindow, à besoin d'un MainWindow. Ceci est un pattern qui te permet de spécialiser ta MainWindow.

Pour ce qui est de ta modification de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
}

à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent)    
{
    QMainWindow=parent;
    ui=new Ui::MainWindow;
    ui->setupUi(this);
}

Cela marche aussi mais est moins optimisé. Tu fera appel dans ton cas au constructeur par défaut, puis au constructeur par copie...
Dans le premier cas, il feras appelle au constructeur paramétrique, en créant l'objet directement avec les bonnes valeurs.

Edit : j'avais pas vu mais QMainWindow=parent ne marchera pas du tout.

[burndev]

Un autre intérêt du new :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void uneFonction()
{
    (...)
    UnType obj;
    UnType *ptr = new UnType();
    (...)
}

la sortie de cette fonction, l'objet obj est détruit.
Autrement dit, la mémoire utilisée pour créer et stocker cet objet, allouée statiquement, est libérée.
Par contre, l'objet pointé par ptr reste valide ; la mémoire utilisée pour sa création et son stockage a été allouée dynamiquement, et reste « valable » tant que l'on ne dit pas explicitement qu'elle doit être libérée (par un delete).

sauf erreur de ma part

il me semble pourtant que *ptr est local a la fonction non ?
Il est pas perdu a la sortie de la fonction ?

[Astraya]

il me semble pourtant que *ptr est local a la fonction non ?
Il est pas perdu a la sortie de la fonction ?

Le pointeur est local oui, mais la mémoire alloué est toujours alloué à la sortie de la fonction si tu ne fais pas de delete. Tu pourrais le récupérer en copiant l'adresse contenu dans le pointeur. Mais c'est plus que suicidaire et dangereux.

[Steph_ng8]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
}

Ce code pourrait s'écrire aussi comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent)    
{
    QMainWindow=parent;
    ui=new Ui::MainWindow;
    ui->setupUi(this);
}

Donc dans le constructeur de cette classe, les objets sont : QMainWindow et ui

Tu peux t'amuser à écrire ça si tu veux, mais le compilateur va te jeter comme un malpropre.
Si tu jettes un œil à la définition de la classe, tu auras certainement quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
class MainWindow : public QMainWindow
{
 
(...)
 
    private:
        Ui::MainWindow* ui;
 
(...)
 
};

« QMainWindow » n'est pas un attribut membre de la classe « MainWindow », mais sa classe-mère.
Le seul moyen d'appeler un constructeur d'une classe parente est par l'intermédiaire de la liste d'initialisation.

Par contre, « ui » est bien un attribut membre, donc les deux manières de l'initialiser sont valides.
Mais la remarque d'Astraya reste valable (même si c'est moins grave pour un pointeur, enfin je crois…)

Cela marche aussi mais est moins optimisé. Tu fera appel dans ton cas au constructeur par défaut, puis au constructeur par copie...
Dans le premier cas, il feras appelle au constructeur paramétrique, en créant l'objet directement avec les bonnes valeurs.

Donc ici c'est bien le pointeur vers l'objet ui non ?

« ui » et « this » sont tous les deux des pointeurs, en effet.
« L'objet ui », comme tu dis, est alloué dynamiquement dans le constructeur, et son adresse est stockée dans la variable membre « ui » de la classe « MainWindow ».
En fait, si on voulait être complet, il faudrait écrire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    this->ui->setupUi(this);
}

[burndev]

je profite de ce topic pour essayer moi aussi de comprendre les avis.

Au niveau de ma formation on me relate tout la puissance des pointeurs et de leurs utilisation ainsi que des dangers.

Une discutions dernièrement avec un autre développeur a commencé a me faire douté sur l'utilisation des pointeurs. Je vois que la aussi certain on peur de l'utilisation des pointeurs.

est ce a cause du problème de débogage ou de leur utilisation pure ?

[Astraya]

Une discutions dernièrement avec un autre développeur a commencé a me faire douté sur l'utilisation des pointeurs. Je vois que la aussi certain on peur de l'utilisation des pointeurs.

est ce a cause du problème de débogage ou de leur utilisation pure ?

Et bien il faut prendre conscience que si c'est ton métier, tu ne seras pas seul à travailler ou a utiliser le code, si ça ce trouve tu ne seras même pas celui qui le maintiendras. En bon développeur tu dois faire en sorte que ton code sois facile à comprendre, à maintenir, éfficace, et ne montrer que ce que tu veux bien montrer au code client. Un développeur c'est un bidouilleur qui adore mettre les mains dans le cambouis, il chercheras à regarder dans ton code car c'est plus fort que lui si il veux comprendre, alors il faut fermer des portes. Le pointeur n'est pas quelque chose de facilement compréhensible dans le code d'un point de vue porté et impacte sur le code global quand tu ne sais pas qui et comment ça à été coder.
On peut facilement en modifiant certains élément casser le code sans s'en rendre compte et créer des fuites mémoires ou faire du segment fault.
Le pointeur laisse au développeur la liberté de gérer lui même la mémoire, c'est quelque chose de dangereux dans le sens ou il faut réfléchir à toute éventualité de modification, de copie de classe, d'allocation etc...

Bref les pointeurs c'est une boite de pandore. Il t'offre quelque chose d'incroyablement puissant mais incroyablement dangereux

[burndev]

Et bien il faut prendre conscience que si c'est ton métier, tu ne seras pas seul à travailler ou a utiliser le code, si ça ce trouve tu ne seras même pas celui qui le maintiendras. En bon développeur tu dois faire en sorte que ton code sois facile à comprendre, à maintenir, éfficace, et ne montrer que ce que tu veux bien montrer au code client. Un développeur c'est un bidouilleur qui adore mettre les mains dans le cambouis, il chercheras à regarder dans ton code car c'est plus fort que lui si il veux comprendre, alors il faut fermer des portes. Le pointeur n'est pas quelque chose de facilement compréhensible dans le code d'un point de vue porté et impacte sur le code global quand tu ne sais pas qui et comment ça à été coder.
On peut facilement en modifiant certains élément casser le code sans s'en rendre compte et créer des fuites mémoires ou faire du segment fault.
Le pointeur laisse au développeur la liberté de gérer lui même la mémoire, c'est quelque chose de dangereux dans le sens ou il faut réfléchir à toute éventualité de modification, de copie de classe, d'allocation etc...

Bref les pointeurs c'est une boite de pandore. Il t'offre quelque chose d'incroyablement puissant mais incroyablement dangereux

tu m'excusera mais je ne suis pas convaincu de ce que tu avance. Car la plupart des codes que je regarde et en cherche une certaine compréhension. Il y a toujours l'utilisation des pointeurs.

Sur l'ensemble de cette discutions, il en ressort un manque de maitrise ou une peur avec l'utilisation des pointeurs. Et je suis assez étonné de cela. Lorsque l'on sais que les pointeurs sont l'essence même de ce langage.

est ce peut être le fait que je sois encore jeune avec l'utilisation de ce langage.
merci

[Astraya]

tu m'excusera mais je ne suis pas convaincu de ce que tu avance. Car la plupart des codes que je regarde et en cherche une certaine compréhension. Il y a toujours l'utilisation des pointeurs.

Du code sur internet? Du code de prof ( sans vouloir les offenser )?
Du code avec de forte demande au niveau de la sécurité et des bugs auras un minimum de pointeur et ceux qui existerons seront encapsuler et ne donneront pas un accès direct sans raison valable.

Sur l'ensemble de cette discutions, il en ressort un manque de maitrise ou une peur avec l'utilisation des pointeurs. Et je suis assez étonné de cela. Lorsque l'on sais que les pointeurs sont l'essence même de ce langage.

Je dirais une expérience qui fais prendre du recul sur les outils du langage...