Version imprimable
salut tous le monde
je vx savoir quand on doit allouer de la memoire pour un noeud dans les liste chainées ?
car des fois dans le cour le prof il n'allou pas pour certain noeud... et quand on doit declarer des variables globales ?Code:debut = (noeud*)malloc(sizeof(noeud)) ;
Bin tu alloues un noeud à chaque fois que tu ajoutes un élément (noeud) à la liste ! S'il le fait pas, peut être qu'il ne le fait pas directement mais qu'il passe par une fonction de création du noeud... Faut voir le contexte !Citation:
Envoyé par josef24
Jamais !!Citation:
Envoyé par josef24
merci Franck.H mais pour les variable globale quel est leur inconvénient
- Non-traçabilité
- Modification possible à des endroits non prévus pour
- Débugage plus difficile
pour un début...
Mais on pourrait citer aussi danger de corruption, d'utilisation par d'autres (à moins d'en limiter la portée), etc etc...
Pour un programme classique, A EVITER ABSOLUMENT, sauf cas d'absolue nécessité (fonctions aysnchrones de signaux par exemples).
Et SURTOUT A EVITER entre fichiers différents.... Déjà à l'intérieur d'un seul, peu recommandé, mais des fois on peut pas faire autrement. Mais RIGOURESUEMENT DECONSEILLE entre fichiers..
Par contre, je préfère une variable globale à un fichier à une variable locale static : Les deux présentent les mêmes problèmes de durée de vie, non-réentrance, non-thread-safety, mais le fait qu'une variable soit globale au fichier attire l'attention sur cela.
J'utilise une convention de nommage qui essaye d'être claire :Citation:
Envoyé par Médinoc
- G_xx globales publiques (variables hors blocs)
- g_xx globales privées (variables static hors blocs)
- S_xx 'globales' blocs (S pour 'static' s_, c'est déjà 'string' ...)
C'est tellement laid qu'on évite !
J'utilise le g_ également, et dans les mêmes circonstances.
Bien sûr là plupart du temps on évite, mais il y a certaines choses qui ne peuvent être faites qu'avec des variables globales, ou au moins statiques.
- Dans un horrible bricolage que j'ai fait à base de macros, je dois utiliser un paramètre qui ne peut être dans le prototype de la fonction ->globale*
- Également dans des fonctions de débogage en C++, mais en beaucoup moins horrible.
- Note: Le problème de réentrance ne se pose pas ici, la variable en question étant une pile chaînée.
- Dans un bricolage encore plus horrible (et non-réentrant!) en assembleur, je dois sauvegarder un registre ailleurs que sur la pile ->statique*
- Lorsqu'on fait du subclassing de fenêtre sous Windows, on est obligé d'utiliser une variable globale pour stocker le pointeur vers l'ancienne procédure de fenêtre, qu'il faut appeler à chaque fois ->globale.
- Ceci peut être évité en utilisant à la place une pratique hélas moins répandue car moins "vite-fait", le superclassing.
- Sans compter le traitements de signaux en C... ->globales
- Et certains objets de synchronisation qui doivent nécessairement être statiques.
Tu remarqueras que près de la moitié de ces cas ont le qualificatif "horrible" ;). Ce n'est pas le genre de choses qu'on fait tout les jours...
* Par "globale" ou "static" ici, je peux aussi parler de thread-local storage: Tout aussi peu réentrant, mais au moins thread-safe. Toutefois, le thread-local storage nécessite l'utilisation d'au moins une variable globale au processus...