Discussion :

[josef24]

salut tous le monde
je vx savoir quand on doit allouer de la memoire pour un noeud dans les liste chainées ?

Code :

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

debut = (noeud*)malloc(sizeof(noeud)) ;

car des fois dans le cour le prof il n'allou pas pour certain noeud... et quand on doit declarer des variables globales ?

[Franck.H]

salut tous le monde
je vx savoir quand on doit allouer de la memoire pour un noeud dans les liste chainées ?

Code :

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

debut = (noeud*)malloc(sizeof(noeud)) ;

car des fois dans le cour le prof il n'allou pas pour certain 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 !

et quand on doit declarer des variables globales ?

Jamais !!

[josef24]

merci Franck.H mais pour les variable globale quel est leur inconvénient

[souviron34]

• 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..

[Médinoc]

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.

[Emmanuel Delahaye]

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 :

• 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 !

[Médinoc]

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...