Discussion :

[frederic13870]

Bonsoir ,

Je suis en train d'apprendre la compilation ou programmation modulaire.

Je ne sais pas répondre à cette question :

dans le main() , j'ai des chemin de fichier que j'ai codé :

Code :

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

char nom_fichier[]="/monchemin/fichier";

Je sais que je peux utiliser le préprocesseur pour écrire :

Code :

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

define NOM_FICHIER monchemin/fichier

mais je peux aussi écrire :

Code :

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

const char nom_fichier = "monchemin/fichier"

Quels objectifs doivent guider mes choix ?

[chrtophe]

Si tu utilises #define, lors de la compilation, chaque occurrence de NOM_FICHIER est remplacé par monchemin/fichier. Il ne s'agit donc pas d'une variable. Cela est fait par le pre-processeur, avant la compilation proprement dite.

le #define est adapté si ton fichier n'est pas modifié par du code (selon critère x ou y) dans ton source

[Sve@r]

Salut

mais je peux aussi écrire : const char nom_fichier = "monchemin/fichier"

Tu as oublié l'étoile => const char* nom_fichier = "monchemin/fichier".

En écrivant char nom_fichier[]="toto" tu définis un tableau variable de 5 caractères (5 car il ne faut pas oublier le '\0'). Ce tableau étant situé dans l'espace mémoire de ton code (on l'appelle "la pile") cela signifie que tu pourras modifier ton tableau comme ça te chante (écrire par exemple nom_fichier[0]='x'). La seule obligation est de ne pas dépasser les limites (de nom_fichier[0] à nom_fichier[4]).

En écrivant char *nom_fichier="toto", tu commences par créer une chaine "toto" située dans l'espace statique de ton code (statique donc non modifiable) et tu récupères juste l'adresse de cette chaine, adresse que tu stockes dans un pointeur nommé "nom_fichier".
Tu pourras utiliser "nom_fichier" exactement comme un tableau (aller lire par exemple nom_fichier[2]) sauf en ce qui concerne la modification de son contenu qui te sera interdite (contenu situé dans l'espace statique).

En écrivant define NOM_FICHIER "monchemin/fichier" là tu donnes une directive pré-processeur. Le pré-processeur est une phase de compilation préalable qui transforme un source ".c" en source ".i" (interprété) dans lequel tous les #include ont été réellement inclus, et dans lequel tous les MON_FICHIER que tu peux utiliser sont remplacés par leur valeur. Et c'est ce ".i" qui est lui réellement compilé au final (je crois que l'option "-P" de gcc lui demande de s'arrêter au ".i", à vérifier).
A l'usage général c'est exactement pareil (que tu exécutes printf("%s\n", mon_fichier) ou bien printf("%s\n", NOM_FICHIER) au résultat c'est pareil). Le code généré lui pourra être un peu plus gros (chaque "NOM_FICHIER" sera littéralement remplacé par la string qui lui est définie) mais aujourd'hui cela n'a plus d'importance. Mais tu ne pourras pas aller lire NOM_FICHIER[2] car "NOM_FICHIER" ce n'est pas un tableau.

Quels objectifs doivent guider mes choix ?

Tes chemins peuvent-ils changer durant l'exécution de ton code ou ne fais-tu que les lire ? Et quand tu les lis, as-tu besoin de n'en lire qu'une partie ? Est-ce que ça te gêne d'avoir la string répétée 500 fois das ton code parce que le préprocesseur la remplace partout où tu utilises NOM_FICHIER ?
Personnellement je pense que le const pour une variable c'est un peu idiot car le but d'une variable est de varier durant la vie du code. En revanche j'en use beaucoup dans mes paramètres de fonction (parce que je veux m'auto-protéger contre une modif accidentelle).

[Bktero]

En écrivant char *nom_fichier="toto", tu commences par créer une chaine "toto" située dans l'espace statique de ton code (statique donc non modifiable) et tu récupères juste l'adresse de cette chaine, adresse que tu stockes dans un pointeur nommé "nom_fichier".
Tu pourras utiliser "nom_fichier" exactement comme un tableau (aller lire par exemple nom_fichier[2]) sauf en ce qui concerne la modification de son contenu qui te sera interdite (contenu situé dans l'espace statique).

Pour être même très complet :
- tu pourras dans le code t'en servir comme si c'était modifiable (car le pointeur dit pointer vers des caractères non constants)
- a l'exécution, le programme va normalement crasher car l'OS va détecter que tu écris à un endroit interdit.
C'est un bug très vicieux.

[Xelland]

Le code généré lui pourra être un peu plus gros (chaque "NOM_FICHIER" sera littéralement remplacé par la string qui lui est définie)

en fait non

le compilateur va chercher tous les strings codés en dur dans le code et va les stocker dans une zone à part
et à chaque appel dans le code, il va appeler cette zone

tu peux le voir avec un décompilateur, ou avec un éditeur hexa (tu ne trouveras qu'un seul "NOM_FICHIER")

tu as le même fonctionnement avec les autres types de variables (mais seulement pour celles définies comme variables globales), mais tu ne le vois qu'avec le décompilateur

[foetus]

A l'usage général c'est exactement pareil

en théorie, pas vraiment
Avec 1 variable const, il devrait y avoir des contrôles de type en + (ce qui semble logique).
Mais j'ai fait quelques tests sommaires, et même avec des macros, il y a des contrôles. Donc, peut-être dans des cas très précis, comme celui de @Bktero.

Ensuite, pour reprendre @chrtophe, avec 1 variable const, tu as 1 variable en mémoire ... à moins que les compilateurs modernes optimisent avec des substitutions ou autres.

le compilateur va chercher tous les strings codés en dur dans le code et va les stocker dans une zone à part

segment RODATA (<- lien wiki en français)

[chrtophe]

Envoyé par Sve@r Le code généré lui pourra être un peu plus gros (chaque "NOM_FICHIER" sera littéralement remplacé par la string qui lui est définie)

en fait non

En fait si.

Je suis pas spécialiste en C mais si je compile ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
#include <stdio.h>
#include <stdlib.h>
 
#define NOM_FICHIER "/etc/fstab"
 
int main()
{
    FILE *handle=fopen(NOM_FICHIER,"r");
    char *buffer;
    buffer=malloc(500);
    buffer=fgets(buffer,200,handle);
    printf("%s\n",buffer);
    fclose(handle);
}

et que j'ouvre le fichier a.out avec hexedit, il n'y a nulle part NOM_FICHIER, et une occurrence de /etc/fstab.
NOM_FICHIER est bien remplacé par /etc/fstab
idem si je compile avec gcc -E essai.c >essai.i pas de trace de NOM_FICHIER.

edit :

Par contre, si je remplace par :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <stdio.h>
#include <stdlib.h>
 
int main()
{
    const char nom_fichier[]="/etc/fstab";
    FILE *handle=fopen(nom_fichier,"r");
    char *buffer;
    buffer=malloc(500);
    buffer=fgets(buffer,200,handle);
    printf("%s\n",buffer);
    fclose(handle);
}

Ca marche mais je ne vois pas /etc/fstab avec hexedit, la chaine doit être encodée.

[dalfab]

Je suis pas spécialiste en C mais si je compile ceci :
....
Ca marche mais je ne vois pas /etc/fstab avec hexedit, la chaine doit être encodée.

Une compilation ne peut pas être une preuve, d'ailleurs tu n'indiques pas si tu as compilé en optimisé. Les codes sont effectivement différents, le second utilise une variable intermédiaire supplémentaire, mais après optimisation il ne reste aucune différence fonctionnelle donc ça pourrait générer exactement le même code.

Si on utilise le #define dans plusieurs unités de compilation, au moment de l'édition des liens il y plus de boulot pour voir que c'est la même chose (il va y avoir deux zones constantes qui ont le même contenu mais pas le même nom avec le define et une unique variable dans l'autre cas.)
Si on fait confiance à l'optimiseur les deux possibilités sont très difficiles à séparer.

[Sve@r]

et que j'ouvre le fichier a.out avec hexedit, il n'y a nulle part NOM_FICHIER, et une occurrence de /etc/fstab.
NOM_FICHIER est bien remplacé par /etc/fstab
idem si je compile avec gcc -E essai.c >essai.i pas de trace de NOM_FICHIER.

C'est normal, le préprocesseur a déjà remplacé la macro par son contenu. Et l'interprété étant issu du préprocesseur (à propos merci pour l'option qui est "-E" et non comme je l'avais écrit "-P") tu ne peux bien évidemment plus voir "NOM_FICHIER".

En fait, ce que je voulais dire, c'est qu'avec un code qui utilise plusieurs fois la macro "NOM_FICHIER", l'interprété écrira alors plusieurs fois son contenu dans le source généré.
Exemple

Code c :

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

1
2
3
4
5
6
7
#include <stdio.h>
 
#define NOM_FICHIER "/etc/fstab"
 
int main() {
	printf("%s, %s, %s, %s\n", NOM_FICHIER, NOM_FICHIER, NOM_FICHIER, NOM_FICHIER);
}

L'interprété donne

Code c :

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

1
2
3
4
5
... (tout le contenu de stdio.h)...
 
int main() {
	printf("%s, %s, %s, %s\n", "/etc/fstab", "/etc/fstab", "/etc/fstab", "/etc/fstab");
}

Après j'en ai rapidement supposé qu'écrire 4 fois une string devait donner fatalement un code plus gros qu'écrire 4 fois une variable et effectivement, après test avec un autre code contenant const char *nom_fichier="/etc/fstab" et en utilisant "nom_fichier" à la place de "NOM_FICHIER", les deux codes ont la même taille. Certainement gràce à la technique RODATA exposée par Xelland et complétée par foetus

Il y a toutefois un autre avantage à passer par une macro: le fait que la macro sera connue de tout le code source (et éventuellement de tous les autres sources si la macro se trouve dans un header inclu par tout le monde), donc toutes les fonctions pourront traiter "NOM_FICHIER" ; chose qui n'est pas possible avec une variable sauf à vendre son âme à la facilité de la globalisation des variables.

en théorie, pas vraiment
Avec 1 variable const, il devrait y avoir des contrôles de type en + (ce qui semble logique).

J'avais dit "en général" donc plus ou moins sous-entendu "dans les grandes lignes". Dans l'esprit d'un printf("%s\n", NOM_FICHIER) comparé à un printf("%s\n", nom_fichier). J'ai d'ailleurs ensuite donné un exemple plus pointu d'un truc qui fonctionne avec une variable mais pas avec une macro

Mais j'ai fait quelques tests sommaires, et même avec des macros, il y a des contrôles.

Le contrôle se fait à la compilation donc après la phase préprocesseur. S'il y a un contrôle c'est par exemple dans le cadre d'un void fct(int n) à laquelle tu passerais la macro NOM_FICHIER et dans ce cas, le compilateur réagit exactement comme si tu lui passais la string "/etc/fstab" (c'est d'ailleurs en réalité exactement ce qui se passe). Idem avec un truc style int n=NOM_FICHIER+1 qui sera compilé comme int n="/etc/fstab"+1 et donc traité de la même façon.

[chrtophe]

C'est normal, le préprocesseur a déjà remplacé la macro par son contenu

Oui c'est ce que je voulais dire par rapport à la réponse de Xelland, @dalfab, je ne parlais pas de l'aspect taille. Compilé simplement via gcc essai.c sans aucune optimisation, même pas précisé de nom de fichier final. J'ai juste remarqué que ma chaine /etc/fstab n'apparaissait pas en clair, encodé ou compressé, je ne sais pas, je m'attendais à la voir en clair dans le fichier ELF, mais ne pas la voir dans le contexte, ne me dérange pas.

à propos merci pour l'option qui est "-E" et non comme je l'avais écrit "-P"

Mais de rien, après c'est pas une option qu'on utilise beaucoup, pour ne pas dire jamais.

Après j'en ai rapidement supposé qu'écrire 4 fois une string devait donner fatalement un code plus gros qu'écrire 4 fois une variable

Au niveau assembleur,et donc au niveau exécutable, il stockera 2 chaines : "/etc/fstab", et "%s, %s, %s, %s\n". visible avec la génération du fichier source assembleur avec gcc -S fichier.c, on pourra voir qu'elles sont logiquement stockées dans la section .rodata, comme déjà évoqué.