striiiiiiiiiiiiiiing - Page 30

Hmmm, Folco, je suis désolé, je me permets de squatter ton topic pour avoir un éclaircissement... je n'ai jamais (ou alors quand j'étais petit et que je ne me souciais pas de ça) fais de programmation où on s'intéresse au côté système et à la gestion mémoire de façon poussée (Java et développement Web).
Pour des raisons de mauvaise traductions, j'ai longtemps traduit heap et stack de la même façon (enfin, disons qu'un heap est un stack particulier)... est-ce que vous pouvez m'expliquer la différence entre utiliser la pile et utiliser le tas ? (D'après WP, le tas est un arbre binaire, mais je ne vois pas comment on peut avoir une structure de mémoire de ce type, ce que ça apporte, les différences, etc.).

Désolé du squat, au pire j'ouvre un autre topic, mais bon ce que j'aime dans les topics de Folco, c'est qu'on peut poser n'importe quelle question sans être pris au ridicule

En fait, en algorithmique on appelle aussi « tas » une structure d’arbre binaire particulière, mais ici ce mot a un autre sens.

Un programme a à sa disposition un espace mémoire où il peut stocker des variables, qu’on appelle « tas ». Quand on alloue quelque chose dedans on ne sait pas où exactement ça va tomber, et on n’a d’ailleurs pas besoin de cette information. On peut juste faire des malloc et des free et ça nous suffit.
L’exécution d’un programme nécessite aussi une pile : quand on appelle une fonction qui utilise des variables locales c’est là qu’elles sont allouées. On a besoin d’une structure de pile car les appels de fonctions s’imbriquent les uns par-dessus les autres, ou même sont récursifs : à chaque nouvel appel on réserve ce qu’il faut sur la pile et à chaque fin de fonction on libère ce que la fonction à utilisé. La taille de la pile limite d’ailleurs la profondeur possible des appels récursifs (sauf dans le cas de la récursivité terminale qui peut être optimisée en un branchement).

Nil (./872) :
ce que j'aime dans les topics de Folco, c'est qu'on peut poser n'importe quelle question sans être pris au ridicule

'foiray, merci pour ma gueule

AFAIK, stack = pile, c'est du LIFO, ça sert à y mettre les données "courantes". Genre sur 68k, le proc qui l'utilise via a7 pour les adresses de retour, et certaines instructions (pea) l'utilisent directement sans même avoir à le spécifier. ( http://fr.wikipedia.org/wiki/Pile_%28informatique%29 )

heap = tas, couramment la ram que tu vas te faire allouer via malloc/realloc/etc...
(t'as pas confondu cette page ( http://fr.wikipedia.org/wiki/Allocation_de_m%C3%A9moire ) et celle-ci (structure de données : http://fr.wikipedia.org/wiki/Structure_de_donn%C3%A9es )

La pile c'est la mémoire nécéssaire au fonctionnement même du programme. Typiquement si tous tes registres sont pris (ou même, si tu n'as pas de registres), tu sais (sous réserve qu'il soit pas déjà tout bouffé) que tu as de l'espace de stockage, utilisable pour tes calculs et résultats intermédiaires (donc variables locales et appels de fonctions).
Tu ne peux pas te passer de la pile, mais elle a un emplacement en mémoire fixe, une taille quasiment fixe*, et tu ne contrôles pas directement† son utilisation. En bref, c'est de la mémoire temporaire, dont l'usage doit être très bref et très réduit. Pas vraiment de la « mémoire » dans le sens auquel on penserait au premier abord en fait.
Le tas en revanche, c'est un espace mémoire de taille variable (limité seulement par l'espace d'adressage), non nécéssairement contigu (il peut y avoir des trous dedans, si je ne dis pas de betises), et qui n'est pas strictement nécéssaire au fonctionnement d'un programme (même si ça te limite énormément dans tes possibilités dans ce cas).

Allouer de la mémoire sur la pile est instantané, car la mémoire est déjà alloué, tu ne fais que la « réserver »: « J'ai mis 50 octets là, donc le pointeur de pile en est à x + 50 ». Et comme la taille est fixe, tu peux potentiellement déborder en dehors de la zone autorisée (c'est le débordement de pile, aka stack overflow)
Allouer de la mémoire sur le tas nécéssite de rechercher un emplacement mémoire disponible, de demander de la mémoire à l'OS si il n'y en a plus, et de réserver cet emplacement mémoire (en le marquant occupé de manière adéquate). C'est donc moins rapide niveau performance, surtout si tes objets ne font que quelques octets et/ou ont une durée de vie très courte. (La façon dont c'est implémenté en interne importe peu pour toi ensuite, ça fera juste varier les performances)

En gros, ce que tu alloues dans le tas est alloué de manière dynamique, pour une durée indéterminée (c'est toi qui la détermine, le cas échéant), et ce que tu alloues dans la pile est alloué de manière temporaire (voué à être détruit le plus tôt possible, dans l'ordre exact de création (moyennant magouilles du compilateur))

* tu peux la choisir à la création du thread, c'est 1 Mo par défaut sous Windows il me semble
† autant dire pas du tout, même si ce n'est pas entièrement vrai (typiquement tu sais qu'une récursion infinie va inévitablement bouffer toute la pile‡)
‡ sauf en cas d'optimisation tail-call quand c'est possible, ou quand le compilateur convertit la fonction récursive en fonction linéaire.

Je suis trouducuté de connaitre tout ce genre de trucs par coeur, alors qu'il me faut des heures pour pondre un objet en C++ (et le refaire le lendemain, et le surlendemain, et [...]). Comme quoi j'ai vraiment appris la programmation par le mauvais bout.
(

* tu peux la choisir à la création du thread, c'est 1 Mo par défaut sous Windows il me semble

128 ko sous msdos, paramétrable pour tous les threads dans config.sys )

Y'a pas de threads sous DOS ^^

Oui, pour tous les programmes j'aurais dû dire. ^^

Merci beaucoup pour ces infos... concrètement, quand vous voulez que des données aillent dans l'un où dans l'autre, vous faites comment ? (Le stack overflow, j'ai ai mangé quand je faisais du Pascal pour DOS, et je ne savais pas comment faire pour m'en sortir )

Folco (./874) :
'foiray, merci pour ma gueule

Non, non, c'était vraiment un compliment... je trouve les topics que tu ouvres toujours très intéressants et sympathiques, on ne t'envoie jamais chier en se foutant de toi, et on y apprend plein de choses !
Et sinon, je ne pense pas que tu aies appris l'info par "le mauvais bout"... tu l'as probablement appris par un autre bout que ce qui se fait aujourd'hui, mais regarde... tu connais énormément de choses que je ne connais pas du tout (et qui ne me parlent pas... je sais en gros comment ça se passe, mais... c'est "autre chose").

Les variables que tu déclares normalement sont placée sur la pile. Pour allouer de la mémoire sur le tas, il faut utiliser un mot clé ou une fonction particulière.
En C, c'est malloc () qui te renvoit l'adresse d'une zone mémoire du tas dans laquelle tu vas pouvoir mettre ta variable. en c++, on utilise le mot clé new. Il doit y avoir un équivalent en pascal.

Nil (./879) :
Non, non, c'était vraiment un compliment...

ah, pas 'foiray, merci pour ma gueule

Nil (./879) :
(Le stack overflow, j'ai ai mangé quand je faisais du Pascal pour DOS, et je ne savais pas comment faire pour m'en sortir )

STACK=9,256 dans ke config.sys, help stack pour plus d'infos

Nil (./879) :
mais regarde... tu connais énormément de choses que je ne connais pas du tout (et qui ne me parlent pas... je sais en gros comment ça se passe, mais... c'est "autre chose").

Le truc limitant, c'est que je connais plein de trucs sur 0.1% de l'info, je préfèrerais avoir des connaissances au moins générales mais dans 80% : serveurs, bdd, protocoles, son, divers langages etc... Là à part le 68k et un peu de C(++), voilà quoi C'est pour ça que je parle du mauvais bout, on apprend pas un domaine en regardant à la loupe un détail dès le départ, mais en regardant l'ensemble, puis plus en profondeur un peu de chaque pour se faire une idée, quitte ensuite à creuser vraiment fort un domaine plus particulier. C'est comme ça que je vois une bonne formation quoi. ^^

Folco (./881) :
je préfèrerais avoir des connaissances au moins générales mais dans 80% : serveurs, bdd, protocoles, son, divers langages etc...

T'as conscience de ce que ça couvre, ne serait-ce que 80% de l'info ? C'est tellement large que si tu voulais vraiment connaître autant de domaines, tu devrais te limiter à du superficiel (ou alors, faut être un génie avec une excellente mémoire).

C'est ce qu'il propose, d'avoir des connaissances générales dans ces domaines là. Et avoir des connaissances générales, c'est assez rapide à avoir.
Concernant tout ce qui est serveur/bdd, c'est vraiment pas compliqué... le plus simple pour apprendre ces choses là, c'est faire son propre serveur sur lequel tu fais un petit service en php.

(cross) Oui, c'est sûr, mais j'en vois beaucoup ici qui passent des langages interprétés aux langages compilés, au web et ses 36 technos, qui ont une certaines connaissances de divers serveurs, base de données et architectures de je-ne-sais-quoi, qui ont pratiqué plusieurs types de hw assez spécifiques et j'en passe. Ca donne une certaine assise. Je pense que c'est dû à une bonne formation qui permet d'aborder les choses du plus général au particulier.
Par exemple, j'aurais aimé étudié de manière académiques les OS et toutes les théories qui tournent autour, les modèles de kernels essentiels, l'ingéniérie logicielle en général etc.
Ce que je constate, en en voyant beaucoup ici ouvrir un topic en disant "je vais attaquer telle techno web" ou "la config d'un serveur machin", c'est une compréhension plus aisée, je pense basée sur des connaissances générales plus étendues, et l'habitude d'utiliser plusieurs domaines de l'informatique, pas toujours le même.
Bref, c'est ce que j'ai toujours pensé.

(ya qu'à voir que j'ai toujours pas réussi à installer/lancer/configurer un minimum un serveur web, un serveur de fichier, un svn et quelques trucs cons pour beaucoup pour se rendre compte que j'ai quand même de belles lacunes, et c'est pas faute d'avoir essayé )

Sinon oui, le 80% est sûrement faux, mais c'est l'idée d'une disproportion que j'ai voulu donner.

Jyaif (./883) :
C'est ce qu'il propose, d'avoir des connaissances générales dans ces domaines là

Pour moi, général et superficiel ne sont pas synonymes (mais ça se discute).

Folco (./884) :
Je pense que c'est dû à une bonne formation qui permet d'aborder les choses du plus général au particulier.

Bôh... tu insistes beaucoup là-dessus, mais pour certains d'entre nous au moins, ce n'est pas le cas (je veux dire que la formation n'y est pour pas grand-chose).

Pour le reste, peut-être que tu surévalues la difficulté des domaines que tu ne connais pas ? (ça a été mon cas pendant un certain temps)

Folco (./881) :

STACK=9,256 dans ke config.sys, help stack pour plus d'infos

Oui mais je programmais tellement avec les pieds que ça ne suffisait même pas (boucle infinie pour faire un menu déroulant ; au bout d'une 50aine de tours de menus, paf pastèque !)

Folco (./881) :
Le truc limitant, c'est que je connais plein de trucs sur 0.1% de l'info, je préfèrerais avoir des connaissances au moins générales mais dans 80% : serveurs, bdd, protocoles, son, divers langages etc...

Euh tu sais, je parle pour moi, mais je ne connais pas énormément de choses . J'ai une formation d'analyste programmeur orienté informatique de gestion (donc quasi aucune connaissance poussée de la gestion du matériel et de la mémoire), j'ai dû faire beaucoup de développement Web, j'ai été sur un poste orienté maintenance (ce qui est très intéressant, mais qui est un domaine totalement différent de l'informatique) et, surtout, j'ai eu à mettre en place des annuaires d'établissement, et ça, je commence à bien (voire très bien) maîtriser (et je trouve ça super intéressant en plus... tout ce qui est urbanisation des systèmes d'informations, établissement des périmètres utilisateurs, etc. ; ça permet d'avoir ce que je préfère en analyse sans devoir pisser du code).

Nil (./886) :
j'ai dû faire beaucoup de développement Web

Nil (./886) :
j'ai été sur un poste orienté maintenance

Nil (./886) :
surtout, j'ai eu à mettre en place des annuaires d'établissement

C'est ce que je pointe du doigt, ces travaux t'ont donné à travailler avec combien de technos différentes, et avec quelle hauteur de vue sur l'ensemble d'un système informatique (au sens serveurs + utilisateurs + gestion des soft proposés + gestions des données persos + sécurité + [...]) ?
Moi pendant 10 ans, mon univers informatique n'a pas dépassé les fichiers .asm, .h, et A68k. Mais je ne me plains de rien hein, juste que j'ai encore beaucoup de trous à boucher.

Bah en même temps, c'est aussi ma faiblesse (peut-être moins pour les annuaires, parce que c'est un sujet que j'ai voulu approfondir et qui me plaît)... en dev. web, je m'y connais, mais je ne maîtrise vraiment pas tout (et il y a des domaines que je n'ai jamais abordés). En maintenance, ça évolue tellement vite (surtout ces putains de malwares à dégommer) qu'il ne faudrait jamais arrêter pour être performant. Et je jalouse pas mal ces gens qui, comme mon frangin par exemple, sont experts dans un domaine (lui c'est en Java) parce qu'ils ont pris le temps d'aller au bout d'une démarche d'assimilation et de compréhension (le plus souvent, par plaisir ou par masochisme intellectuel - on me souffle à l'oreille que c'est la même chose )

Faut savoir que c'est le plus souvent le masochisme intellectuel qui complexifie les programmes et leur maintenance

Keep it simple

C'est pas du masochisme, chacun a ses centres d'intérêt

Tiens au fait, pour mon vecteur de Module*, dois-je faire un delete sur les Module avant de détruire le vecteur ?
La destruction d'un objet n'entraine pas la destruction des autres objets qu'il contient d'une manière ou d'une autre, non ?

Folco (./891) :
La destruction d'un objet n'entraine pas la destruction des autres objets qu'il contient d'une manière ou d'une autre, non ?

Oui. Mais que fait le destructeur d'un pointeur? I.e. que se passe-t-il quand on fait:

void f() {
    Objet *o = new Objet;
}    // La variable locale o est détruite

la destruction du vecteur entraine la destruction des objets contenus, donc ici la destruction du pointeur (= ça ne fait rien)
en aucun cas ça ne va détruire l'objet pointé. il faut que tu fasses un delete sur chaque

Brunni -> on a perdu Objet en ram ^^

aze -> ok, merci.

Voilà, il détruit le pointeur mais PAS l'objet pointé. C'est exactement ce qui va se passer avec ton vecteur. Il ne va en tous cas pas appeler explicitement delete, sinon imagine ce qui se passerait dans ce cas:

void main() {
    Objet *o;
    vector<Objet*> v;
    v.push_back(o);
    delete o;
}   // v détruit o une deuxième fois? crash!

Ou plus vicieux, s'il appelait delete sur un type par valeur -> pas possible

Oué, je pensais à ça, je pensais aussi que tu pourrais avoir une copie de l'adresse de l'objet autre part et vouloir l'utiliser.

Et maintenant, si objetA contient objetB, et que je fais un delete &objetA, le destructeur de B est-il appelé lors de la destruction de A ? Ou dois-je faire un delete &objetB dans le destructeur de A ?

Question élémentaire sûrement, mais je sais plus où c'est dans mon bouquin, l'introduction sur les objets fait 50 pages

Oui, si l’objet B est un attribut de la classe A il sera détruit quand une instance de A le sera.

Folco (./896) :
Et maintenant, si objetA contient objetB, et que je fais un delete &objetA, le destructeur de B est-il appelé lors de la destruction de A ? Ou dois-je faire un delete &objetB dans le destructeur de A ?

Aïaïaïaïaïe! Dans 99% des cas si tu fais delete &quelquechose c'est que tu es en train de faire une connerie
Sinon quand tu détruit une classe ses attributs le sont aussi (c'est valable aussi pour les éléments de vector, qui sont toujours des copies de ce que tu lui passes).

Ok, merci

Brunni, le coup du delete &machin était un exemple, pour bien signifier que je passais un pointeur à delete

Bon, ça va chier

<mylife>
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é ?
</>