A voir également:
- "Php version 4.4.3" "build date" "server api" "php variables"
- "Php version 4.4.4" "build date" "server api" "php variables" - Forum PHP
- API php pour Astérisk - Forum PHP
- "Php version 4.4.5" "build date" "server api" "php variables" - Forum PHP
- Php version 4.4.6 build date server api php variables ✓ - Forum C# / .NET
- Api SetBitmapDimensionEx - Forum Visual Basic
4 réponses
Qui à dit que ce n'était pas conseiller d'utiliser des variables global??? Voici un petit exemple ou plutôt ma méthode:
Je cré un fichier ressource.h et dans ce fichier j'écrit par exemple:
// Début du fichier
#ifndef RESSOURCE_HEADER // Si le fichier n'est pas déjà inclus
#define RESSOURCE_HEADER // On l'inclus
// Variables(Exemple)
const char Var_Global[] = "Mon fichier.txt";
const int Var_Global2 = 35;
char *Mon_Char;
unsigned int Mon_Int;
// Etc...
#endif // Fin du fichier
Et dans les autres fichier j'include ce fichier ou ce trouve mes var global, petit fonction, autres headers, etc...
[mailto:NitRic28@Hotmail.com NitRic]
Je cré un fichier ressource.h et dans ce fichier j'écrit par exemple:
// Début du fichier
#ifndef RESSOURCE_HEADER // Si le fichier n'est pas déjà inclus
#define RESSOURCE_HEADER // On l'inclus
// Variables(Exemple)
const char Var_Global[] = "Mon fichier.txt";
const int Var_Global2 = 35;
char *Mon_Char;
unsigned int Mon_Int;
// Etc...
#endif // Fin du fichier
Et dans les autres fichier j'include ce fichier ou ce trouve mes var global, petit fonction, autres headers, etc...
[mailto:NitRic28@Hotmail.com NitRic]
Je n'utilise jamais de variable globales, donc je ne suis pas vraiment compétent à ce niveau, mais j'ai tout de même un doute :
Je suis d'accord pour déclarer la variable globale dans un fichier d'en tête, mais en revanche il ne faut pas les définir dans le .h ! Sinon, lors de la compilation, les différents modules auront chacun leur variable, mais ils ne partageront pas la même variable globale. D'ailleurs, je ne serais pas étonné si cela provoquait des erreurs lors de l'édition de liens.
A mon avis, dans le .h il faudrait plutôt mettre un truc du genre :
extern char * variable_globale;
Ainsi, on déclare la variable. Ensuite, dans un .c on la définit une fois et une seule :
char * variable_globale = NULL;
De plus, ta solution consistant à contruire les variables dans le .h (ce qui est très visible lorsque tu leur attribue une valeur initiale) devrait te mettre la puce à l'oreille, car cela signifie que la variable globale est construite autant de fois qu'il y a de modules utilisant le .h ! Difficile dans ces conditions d'avoir une seule et unique variable globale...
Je n'ai jamais utilisé ce mécanisme, donc il y a peut-être quelques erreurs dans ce que je dis, mais c'était pour exprimer mon doute au sujet de la solution proposée.
D'autre part, cela ne t'étonne pas de déclarer une variable constante ? ;o)
Je suis d'accord pour déclarer la variable globale dans un fichier d'en tête, mais en revanche il ne faut pas les définir dans le .h ! Sinon, lors de la compilation, les différents modules auront chacun leur variable, mais ils ne partageront pas la même variable globale. D'ailleurs, je ne serais pas étonné si cela provoquait des erreurs lors de l'édition de liens.
A mon avis, dans le .h il faudrait plutôt mettre un truc du genre :
extern char * variable_globale;
Ainsi, on déclare la variable. Ensuite, dans un .c on la définit une fois et une seule :
char * variable_globale = NULL;
De plus, ta solution consistant à contruire les variables dans le .h (ce qui est très visible lorsque tu leur attribue une valeur initiale) devrait te mettre la puce à l'oreille, car cela signifie que la variable globale est construite autant de fois qu'il y a de modules utilisant le .h ! Difficile dans ces conditions d'avoir une seule et unique variable globale...
Je n'ai jamais utilisé ce mécanisme, donc il y a peut-être quelques erreurs dans ce que je dis, mais c'était pour exprimer mon doute au sujet de la solution proposée.
D'autre part, cela ne t'étonne pas de déclarer une variable constante ? ;o)
Pour ce qui est des constantes j'en est jamais utiliser, j'utilise #define Ma_Const valeur :|, mais pour le reste j'ai bien l'impression que tu as raison sur tout, désoler d'avoir donner une mauvaise réponse, j'y penserrais 2 fois avant de répondre la prochaine fois :), merci d'avoir corriger! :).
[mailto:NitRic28@Hotmail.com NitRic]
[mailto:NitRic28@Hotmail.com NitRic]
Je trouve dommage d'utiliser des #define pour des constantes en c++, puique c'est un language qui fournit tous les éléments pour les éviter.
Les directives de précompilation devraient, précisément, être réservées aux tâches de précompilation.
En plus, l'utilisation de "vraies" constantes déclarées et définies permet de nombreuses vérifications par le compilateur.
Sans compter que les #define n'ont aucun mécanisme pour éviter les conflits de nommage.
Enfin, un #define ne permet pas vraiment de définir des constantes instances de classes autres que les types de base. Ainsi, le #define n'est pas forcément efficace puisque par exemple :
#define TOTO CToto(18,15,"toto")
fait appel au constructeur paramétré de CToto autant de fois que TOTO est utilisé.
Au contraire :
const CToto TOTO(18,15,"toto");
fait appel une seule fois au constructeur, indépendamment du nombre d'utilisations de TOTO.
Les directives de précompilation devraient, précisément, être réservées aux tâches de précompilation.
En plus, l'utilisation de "vraies" constantes déclarées et définies permet de nombreuses vérifications par le compilateur.
Sans compter que les #define n'ont aucun mécanisme pour éviter les conflits de nommage.
Enfin, un #define ne permet pas vraiment de définir des constantes instances de classes autres que les types de base. Ainsi, le #define n'est pas forcément efficace puisque par exemple :
#define TOTO CToto(18,15,"toto")
fait appel au constructeur paramétré de CToto autant de fois que TOTO est utilisé.
Au contraire :
const CToto TOTO(18,15,"toto");
fait appel une seule fois au constructeur, indépendamment du nombre d'utilisations de TOTO.
