[C++] Jouons à pile ou tas - Page 1

pouet,

Je me posais une question probablement inutile, donc très angoissante.
Je vois (et je fais) beaucoup d'allocations avec new dans mes constructeurs d'objets.
Qt Designer fait la meme chose, des new partout.

Je me posais la question de la performance et de l'empreinte mémoire d'un tel code. Question overhead, faire une allocation par instruction, ça doit etre rigolo. Alors que cette place pourrait tout simplement être réservée à la création de l'objet, dans la pile, sachant qu'il y a déjà certainement une instruction qui s'occupe d'y faire de la place : l'overhead serait alors nul côté perf.

Alors, qu'en pensez-vous, pile ou tas ? Perso je me dis que je ferais mieux d'utiliser la pile, c'est ce que je ferais en tout cas sur TI.
Maintenant je connais pas l'architecture PC, donc si ça tombe c'est pas une bonne idée, ou alors je risque de me réserver de mauvaises surprises.

Merci pour vos avis.

Si ça marche comme pour les malloc() et que tes objets ne sont pas trop gros, il y a des chances que ton compilo optimise les new en utilisant la pile pour les objets locaux, de toute façon.
Perso j'aurais tendance à utiliser explicitement la pile dans ce cas-là, mais ce n'est que mon avis. Il faut juste faire attention à ne pas retourner un tel objet (mais si tu écris le code de destruction en même temps que le code de création, ce qui est recommandé, tu vas de toute façon voir qu'il y a un souci).

(je pensais qu'il y avait une différence sur le fait que new pouvait renvoyer un pointeur nul en cas de manque de mémoire, mais apparemment non, les compilateurs qui respectent le standard sont censés lancer une exception dans ce cas)

Ok, intéressant. Je suis en train de rechercher ce qu'un compilo sait faire avec new.
Pour info, je ne risque de faire aucune copie ou assignation de mes objets.

Il est dangereux d'allouer un QObject sur la pile (surtout avec un parent non-nul) parce que le QObject peut être détruit à travers la hiérarchie, ce qui ne marche pas s'il a été alloué autrement qu'avec new.

Ah merci beaucoup, donc question Qt je vais tout faire avec new, ok.
(et vu comme les signaux/slots ça powate, pratiquement toutes mes classes héritent de QObject maintenant )

Franchement je doute que le C++ mette même un objet déclaré dans une fonction sur la pile, l'empreinte mémoire d'un objet est plutôt gros, et la pile n'est pas extensible non plus. De toute manière oui il est bien plus courant d'allouer dynamiquement un objet que statiquement.

Si le compilateur alloue quelque chose sur la pile sa sera plutôt un pointeur que l'objet en lui même.

Apres tout this est un pointeur dans tous les cas quelque soit la façon dont l'objet a été alloué.

Ce post n'a pas valeur d'etre exact, et ne reflète que ce que JE pense, pas ce que font reelement les compilo, je peux me tromper (je prends les devants)

De mémoire, Windows alloue quelque chose comme 1 Mo pour la pile par défaut, et l'étend automatiquement si jamais elle déborde. Ça doit être similaire sous Linux.

Donc je pense qu'il y a de la place pour y mettre les petits objets.

Quand on parle d'une petite string, on doit taper dans les 100/200 octets à tout péter, donc ça doit sans problème tenir sur la pile. Après ok, la partie dynamique de la string sera sur le heap, mais ça n'empêche pas d'allouer sur la pile.

Heu non la pile ne s'etends pas sous UNIX/Linux si tu la dépasse tu explose ton app (Stack Overflow)

Ca me surprends pour windows j'aurais dit que la pile a une taille fixe sauf si modifié au moment de la creation du thread ou changé avec une API quelconque

J'aurais tendance à avoir l'avis inverse : tant que tu peux allouer sur la pile, pourquoi faire autrement ? C'est plus efficace, ça te fait un "delete" de moins par objet et ça t'élimine certains candidats aux memory leaks. Pour l'histoire de la taille de la pile c'est vraiment rarissime de l'atteindre, à moins d'avoir des fonctions récursives un peu trop profondes (et alors ça peut être le bon moment pour les réécrire autrement).

Par "tant que tu peux", j'entends la même chose que ce qui a déjà été dit plus haut, à savoir qu'il s'agit de petits objets donc la durée de vie n'excède pas celle de la fonction dans laquelle tu les utilises, et que leur mécanique interne n'empêche pas ce type d'utilisation (encore que perso je n'utiliserais pas une bibliothèque dont les objets ne fonctionnent que s'ils sont alloués avec "new" et risquent de planter sinon).

Ben tu peux dropper Qt alors

En fait, les QObject/QWidget sont apparentés, et en détruire un implique de détruire toute la hiérarchie. Ce problème de libération comporte quand meme pas mal d'avantages, à savoir qu'on ne se soucie plus de la libération de la mémoire. Dans des cas où un objet complexe (une fenetre) est composée d'objets qui viennent d'un peu partout, c'est bien appréciable.

De mon côté, avec Qt, j'alloue sur la pile les fenetres modales, puisqu'elles sont destinées à être détruites dès qu'on les ferme :

QString EditLadderName::getNewLadderName()
{
    return EditLadderName (tr("New ladder"), "").run();
}

Ici, le dialogue EditLadderName est sur la pile, vu qu'il est local, pas besoin de s'embêter avec un new/delete.

Mais en-dehors de l'utilisation d'une lib qui fonctionne comme ça, j'ai tendance à préférer ce que tu dis, les piles sont quand même assez balaises de nos jours pour qu'on hésite pas à y mettre tous les petites donnnées qu'on utilise forcément ici et là ^^

Zerosquare (./7) :
De mémoire, Windows alloue quelque chose comme 1 Mo pour la pile par défaut, et l'étend automatiquement si jamais elle déborde. Ça doit être similaire sous Linux.

Donc je pense qu'il y a de la place pour y mettre les petits objets.

Mais si c'était le cas, on n'aurait jamais de stackoverflow sous windows non ? pourtant il y en a bien un .

En fait, ce que je me dis toujours, c'est que QObject est l'équivalent C++ des objets Java, avec les mêmes avantages (introspection!), mais aussi les mêmes inconvénients (allocation toujours dans le tas, héritage multiple interdit).

(Pour l'histoire de l'héritage multiple, un QObject peut dériver de plusieurs classes C++, mais seule la première peut être une classe dérivée de QObject. Ceci parce que le pointeur sur la classe doit être réinterprétable comme un QObject * sans toucher à l'adresse.)

La pile sous Linux est de 8 Mo par défaut (ce qui est peu pour un système avec une mémoire de 16Go) - elle peut être augmenté. Cf. "ulimit -s".

Godzil > l'agrandissement automatique de la pile, ça existe sous Linux aussi apparemment :
http://unix.stackexchange.com/questions/63742/what-is-automatic-stack-expansion
https://www.cemetech.net/forum/viewtopic.php?t=6551

SCPCD > c'est le cas, mais je pense qu'il y a quand même un maximum à la taille de la pile (mais une recherche rapide ne m'a pas donné grand-chose)

Certains objets relativement larges sont alloués sur la pile dans wow, notamment ce qui part vers le serveur. Pour le traffic entrant, c'est du 100% pointeurs, ce qui s'explique sûrement que des paquets de 80 kilooctets, c'est pas opti de les balader dans la pile Un ça va, mais sur un serveur peuplé, ça spam sec