Discussion :

[Luke spywoker]

Salut les C,

J'ai un programme de plusieurs fichiers sources ayant chacun sont header et j'utilise un Makefile pour compiler chaque fichier *.c.

D'abords le sujet N° 1: les variables externes marqué extern.

J'ai une structure de type GUI ressemblant a 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
16
17
18
19
20
21
22
23
24
25
26
/** File gui_structure.h . **/
 
typedef struct {
 
  GtkWidget *icon ;
 
  GtkWidget *label ;
 
  GtkWidget *accel_label ;
 
} MenuItem ;
 
/** etc more typedef struct { ... } **/
 
typedef struct {
 
  MenuItem files ;
 
  MenuItem action ;
 
  GtkWidget *hbox ;
 
  // etc...
} GUI ;
 
// Etc...

Puis j'ai un fichier de déclaration de variables globale:

Code :

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

1
2
3
/** Files global_variables.h **/ 
 
GUI *gui ;

Puis je me retrouve souvent a n'avoir besoin que de gui->notebook_editor ou gui->notebook_terminals, dans mes fichiers.

Alors dans mes fonctions je déclare:

Code :

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

1
2
3
4
5
6
7
8
void callback(GtkWidget *widget, gpointer user_data) {
 
  extern GUI *gui ;
 
  // ...
 
  return ;
}

Alors j'ai un doute: est que ça serai mieux de déclarer un alias de gui->notebook_editor sous forme de pointeur déclarer comme une variable globale ?

Je ne le fait pas pour l'instant car je pense que si je déclare:

Code :

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

extern GUI *gui ;

cela revient au même: copier l'adresse du pointeur de toute la structure GUI *gui c.a.d la taille d'un pointeur.

A la place d'utiliser un pointeur alias sur un seule GtkWidget *.

NOTE: je ne peut pas passer la variable gui par l'argument user_data.

---

Sinon j'ai un problème avec le Makefile.

Quand j'ajoute un fichier je l'ajoute a une liste (a savoir que l'arborescence est complexe).

Et j'aimerai utiliser le feature de règle implicite...

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
16
17
18
19
20
21
22
23
24
25
26
 
SRC_FILES = ./folder1/file1.c \
                   ./folder2/file2.c \
                   ./folder3/subfolder1/file3.c 
 
TMP = $(notdir $(SRC_FILES:.c=.o))
 
OBJECTS = $(TMP:%=./build/%) 
 
prgname: $(OBJECTS)
    $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
 
$(word 1, $(OBJECTS)): $(word 1, $(SRC_FILES))
    $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
 
# Etc ...
 
# My try for implicite rules build:
 
VPATH = ./folder1 ./folder2 ./folder3/subfolder1 ./build
 
%o: %c $(SRC_FILES) $(OBJECTS)
    $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
 
 
# What lack me to success implicte build ?

Vous avez remarquer que j'utilise un dossier pour le build ce qui rend la chose plus difficile.

Merci pour vos réponses éclairées et votre précieuse aide.

[Matt_Houston]

Mes 2 centimes :

1. Je n'ai pas bien saisi l'interrogation au sujet des alias de fonction, par contre si tu déclares GUI *gui; dans ton .h tu obtiendras une variable gui par module de compilation. De plus tu n'as pas besoin de le déclarer en extern dans tes fonctions puisque la variable est déjà visible (si tu inclus le header). Ce que je ferais à ta place :

Code gui_public.h :

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

1
2
3
4
extern GUI *gui;
 
/* initialize UI */
int gui_init(GUI *);

Code gui.c :

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

1
2
3
4
5
GUI *gui;
 
int gui_init(GUI *gui) {
    // ...
}

Code main.c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <stdlib.h>
#include <stdio.h>
 
#include "gui_public.h"
 
int main(int argc, char *argv[]) {
    if ((int r = gui_init(gui))) {
        fprintf(stderr, "gui initialization failed with code %d", r);
        exit(EXIT_FAILURE);
    }
 
    gui->do_stuff();
 
    // ...
 
    return 0;
}

2. N'écris pas tes makefile à la main lorsque ton projet commence à prendre de l'envergure, on n'est plus en 1988. Utilises plutôt autotools (si tu ne connais pas je te recommande le très bon guide d'Alexandre Duret-Lutz) ou autre chose (waf, CMake...).

[Luke spywoker]

D'accord nous ne somme plus en 1988,

mais je pense qu'il faut connaître la syntaxe des Makefile avant d'utiliser les autotools.

Je dit ça empiriquement (par expérience) car j'ai appris les autotools sans connaître le fond de l'outil make, sur lequel sont basé grand nombre de projets.

Et ça ne m'a pas vraiment réussis car avant de lire le GNU manual de make, je comprenait mal les autotools.

Et ça tombe bien que tu me dise cela car c'est pour générer un Makefile que je pose la question dessus.

Je pense qu'il faut apprendre a lire et a écrire avant de générer des données, car l'ont dit que l'ordi est une extension de son cerveau... a méditer.

Sinon je n'ai aucun problème avec mon programme et mes variables globales mais je voulait simplement savoir si il est plus court d'écrire un pointeur de GtkWidget au lieu d'un pointeur sur une structure de GtkWidget déclaré comme extern ?

Mais sûrement que un pointeur fait la taille d'un pointeur mais qu'en est t il déclaré comme extern ?

[dalfab]

Bonjour,

un pointeur déclaré par extern, static, auto ou autre est un pointeur; il a la taille d'un pointeur.
extern ne sert qu'à indiquer au linker qu'il est dans autre unité, il n'y a à l'utilisation même pas une copie.
Donc l'utilisation de gui->notebook_editor provoque :

• lecture du pointeur gui
• ajout de l'offset notebook_editor
• lecture du pointeur à l"offset, cad gui->notebook_editor

En créant un pointeur global
gui_notebook_editor = gui->notebook_editor; il ne reste que

• lecture du pointeur gui_notebook_editor

En compilation optimisée, les deux instructions gagnées n'utilisent un seul cycle sur quasi-tous les processeurs, donc pas vraiment utile selon moi.

[Matt_Houston]

D'accord nous ne somme plus en 1988,

mais je pense qu'il faut connaître la syntaxe des Makefile avant d'utiliser les autotools.

Je dit ça empiriquement (par expérience) car j'ai appris les autotools sans connaître le fond de l'outil make, sur lequel sont basé grand nombre de projets.

Et ça ne m'a pas vraiment réussis car avant de lire le GNU manual de make, je comprenait mal les autotools.

Et ça tombe bien que tu me dise cela car c'est pour générer un Makefile que je pose la question dessus.

Je pense qu'il faut apprendre a lire et a écrire avant de générer des données, car l'ont dit que l'ordi est une extension de son cerveau... a méditer.

Certes, et c'est tout à ton honneur de chercher à comprendre le fonctionnement des choses si tu en as le temps et la motivation. Je te disais cela dans une optique de productivité, car tu dis que ton projet atteint une taille respectable. Parfois on veut simplement que les choses « marchent » afin de pouvoir se consacrer à un autre aspect du problème.

Parmi tous les langages imbitables sortis des méandres des cerveaux névrosés des programmeurs, celui de Make est bien l'un des pires. Peu lisible, « error-prone »... De plus il n'est pas normalisé - contrairement à un système de build de haut niveau - ce qui signifie que tu n'as aucune garantie que ton makefile fonctionne ailleurs que sur ta distribution de développement.

Sinon je n'ai aucun problème avec mon programme et mes variables globales

Tu n'en as pas parce que ton compilateur est « sympa » (ou pas) et qu'il considère la définition de gui inclue plusieurs fois comme une déclaration. Le mode par défaut de l'éditeur de liens doit faire le reste. C'est toutefois une erreur d'après la norme.

mais je voulait simplement savoir si il est plus court d'écrire un pointeur de GtkWidget au lieu d'un pointeur sur une structure de GtkWidget déclaré comme extern ?

Mais sûrement que un pointeur fait la taille d'un pointeur mais qu'en est t il déclaré comme extern ?

extern sert - grosso modo - à changer une définition en déclaration. Il n'y a aucune incidence sur la nature de la variable déclarée. Si c'est écrire gui-> qui te fatigue, déclares une variable locale pour représenter l'objet pointé ou crées un #define.

À noter qu'il peut-être nécessaire de décorréler le code de la variable globale pour le rendre plus générique. Par exemple, tes fonctions pourraient ainsi intervenir sur un widget - passé en paramètre, donc - qui ne fait pas partie de l'instance principale de GUI (je ne sais pas si ça a un intérêt).

[Luke spywoker]

Merci pour cette réponse technique qui m'aide a voir ce que je voulait savoir et pour votre aide a vous tous.

Donc a ton avis pas besoin de gagner le calcule de l'offset au prix d'une variable globale de plus.

[Luke spywoker]

Citation Envoyé par Luke spywoker
Sinon je n'ai aucun problème avec mon programme et mes variables globales

Tu n'en as pas parce que ton compilateur est « sympa » (ou pas) et qu'il considère la définition de gui inclue plusieurs fois comme une déclaration. Le mode par défaut de l'éditeur de liens doit faire le reste. C'est toutefois une erreur d'après la norme.

Bon merci, mais si je veut pas que mon compilateur soit `sympa' et respecter la norme y a t-il une options a passer a gcc a fin qu'il soit moins permissif ?

---

Je résume j'ai un fichier d'en-tête qui `déclare' mes variables globales comme la variable de type GUI que j'inclus dans les fichiers *.c ou j'ai besoin de ces variables globales.

Puis je les déclares comme extern dans les fonctions ou j'en ai besoin.

Je compiles plusieurs fichiers objet comme cela. Comment fait ont alors pour le faire correctement (ou plutôt selon la norme) ?

Car pour moi c'est déjà un petit exploit de compiler plusieurs fichiers objets en référençant toujours la même instance de variable globale...

PS: je l'ai dit plus haut il ne m'est pas toujours possible de passer en argument avec GTK+3.0.

---

Concernant make je ne comprends pas pas trop:

Parmi tous les langages imbitables sortis des méandres des cerveaux névrosés des programmeurs, celui de Make est bien l'un des pires. Peu lisible, « error-prone »... De plus il n'est pas normalisé - contrairement à un système de build de haut niveau - ce qui signifie que tu n'as aucune garantie que ton makefile fonctionne ailleurs que sur ta distribution de développement.

Car les autotools se basent sur l'outil make, par le biais automake, sans compter ceux que je connais pas (Cmake) ???

J'ai lu le GNU Coding Standards et je pense que l'équipe de Stallman a écrit ce(s) document(s) afin de mettre en place des conventions afin que justement le programme soit le plus portable possible (je parle du système de build).

Mais je vous rassure mes projets n'ont pas besoins des autotools pour la phase de développement, et même:
Distribuer un Makefile.in écrit a la mains est dans la norme du GNU Coding standards, cela va avec la taille de mes projets et un peu de bon sens dans l'écriture du Makefile.

J'attends vos réponses éclairées avec impatience.

Mouarfs je vient de relire tout le poste et je me demande si j'inclue la définition aussi ou seulement dans le fichier main.c...

[Matt_Houston]

Bon merci, mais si je veut pas que mon compilateur soit `sympa' et respecter la norme y a t-il une options a passer a gcc a fin qu'il soit moins permissif ?

Ça je ne sais pas.

Je résume j'ai un fichier d'en-tête qui `déclare' mes variables globales

Non, ce qui est écrit dans ton en-tête est une définition. C'est à dire que le compilateur devrait réserver l'espace de la variable dans chaque unité de compilation, s'il était moins souple sur la norme. Tu aurais donc un gui par fichier compilé dans lequel cet en-tête est inclus, et l'éditeur de lien t'enverrais bouler avec un « multiple definition of ... ». C'est d'ailleurs ce qui se passera si tu initialises cette variable dans sa définition (tu peux essayer avec GUI *gui = NULL; par exemple).

Comment fait ont alors pour le faire correctement (ou plutôt selon la norme) ?

Je l'ai précisé dans mon premier message : extern dans le .h pour forcer la déclaration, et une seule définition (GUI *gui; ou GUI *gui = NULL;) dans l'un des .c qui composent le programme. Tu peux utiliser un .c dédié aux définitions de variables globales si ça t'arrange.

Concernant make je ne comprends pas pas trop car les autotools se basent sur l'outil make, par le biais automake [...]

Oui et c'est là ou je voulais en venir, c'est tellement complexe et fastidieux de gérer cela pour un projet qui s'étend sur plus d'un répertoire que les auteurs d'automake ont décidé de wrapper tout ce bordel dans un système bien plus utilisable.

Je rappelle que ce que j'écris est toujours mon humble avis, si tu es à l'aise avec ça alors va pour les makefiles manuels. Utilises ce que tu apprécies et ce qui te permet d'être efficace.


Peace.

[Bktero]

Tu peux utiliser un .c dédié aux définitions de variables globales si ça t'arrange.

Je trouve ça mal de faire des globales et encore plus de les regrouper. J'explique pourquoi ici : https://gradot.wordpress.com/2014/07...globales-en-c/

[Matt_Houston]

Tu peux utiliser un .c dédié aux définitions de variables globales si ça t'arrange.

J'ai lu ton article mais moi la seule règle absolue à laquelle je crois c'est : n'écrivez pas de code dégueulasse. Ce ne sont pas les concepts de variable globale et de goto qui sont responsables des programmes mauvais ou impossible à maintenir, c'est le manque de rigueur de leurs auteurs.

[ternel]

Le problème des globales, c'est qu'ils augmentent la possibilité d'écrire du code dégueulasse.
Exactement comme les goto ou les macros.

[Matt_Houston]

Et le problème des couteaux dans une cuisine, c'est qu'ils augmentent la possibilité de se couper.

Personne n'a besoin de ces trois fonctionnalités pour écrire du code dégueulasse non plus, les programmes des étudiants en informatique à qui on apprend Java en font chaque jour la preuve.

[ternel]

C'est vrai qu'on peut faire moche sans, mais je n'ai encore jamais vu propre avec.
Sauf dans un tuto expliquant la gestion correcte des erreurs en C et en C++.

Et une variable statique non privée d'une classe publique (j'entends par la "dans un en-tête"), c'est aussi une variable globale.

[Bktero]

Et le problème des couteaux dans une cuisine, c'est qu'ils augmentent la possibilité de se couper.

Personne n'a besoin de ces trois fonctionnalités pour écrire du code dégueulasse non plus, les programmes des étudiants en informatique à qui on apprend Java en font chaque jour la preuve.

Pour éplucher des patates, un épluche-légume est bien plus adapté et bien moins dangereux qu'un couteau à désosser. Et pourtant, on peut se couper avec un épluche-légume.

Je suis d'accord avec ta seule règle. Et je suis aussi d'accord avec leternel sur les conseils pour suivre ta règle.

[Luke spywoker]

Merci pour vos explications.

J'ai compris le principe des variables globales et de extern.

En faîte on peut créer un fichier global_vars.c avec la définitions des variables globales (sans extern) que l'on va compiler.
Et créer un header passe partout avec les variables globales déclaré avec extern.

Merci d'avoir éclaircis ce point, vous pouvez allez vérifier si j'ai fait cela correctement dans mon dernier projet en développement.

Merci pour vos réponses éclairées illuminant les ténèbres de mon ignorance.