Discussion :

[n0mad]

Hello,

Je souhaiterais developper (plutot découper) mon programme de la manière suivante :

programme.c
h_headers1.h
h_headers1.c

Le programme.c étant le code contenant le main() et compilé (gcc programme.c ...) et dans les h_* mettre toutes mes fonctions. Je souhaiterais enfaite que dans le .h il y ait les signatures des fonctions ainsi que le blabla qui va bien (commentaires!) et que dans le .c associé il y ait le code proprement dit de la fonction.

Deux questions :
1. Comment faire ? (Je pense à une manière autre que programme.c include h_headers.h qui lui-même include h_headers.c) - Je me disais qu'étant donné qu'ils ont les mêmes nom ça pourrait être implicite à la compilation ?
2. Y-a-t-il un interet ?


Merci,

[souviron34]

Deux questions :
1. Comment faire ? (Je pense à une manière autre que programme.c include h_headers.h qui lui-même include h_headers.c) - Je me disais qu'étant donné qu'ils ont les mêmes nom ça pourrait être implicite à la compilation ?

Euh.. Je crois que tu n'as pas compris la notion sous-jacente.

Le .h contiendra bien la déclaration des fonctions, mais c'est la seule chose qu'on incluera dans programme.C (pour qu'à la compilation il y ait vérification des paramètres et que le compilateur sache que les fonctions sont définies extérieurement.

Le ...headers.c sera compilé séparément, et lié (phase de link/édition de liens du compilateur) à programme.c, où les références seront résolues..

2. Y-a-t-il un interet ?

Plusieurs :

• modularité
• maintenance
• fabrication de bibliothèques
• éventuellement code binaire plus petit (si bibliothèque dynamique)

[n0mad]

Euh.. Je crois que tu n'as pas compris la notion sous-jacente.

Ca se discutte, je pencherais plutot pour le fait que je ne sache pas l'implémenter :o)

Bref, j'ai les trois bout de code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
// test.c
#include <stdio.h>
#include "h_header.h"
int main(void)
{
	printf("bonjour !\n");
	ma_fonction(5);
	return 1;
}

Code :

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

1
2
3
4
 
// h_header.h
/* Ma Super Fonction */
void ma_fonction(int);

Code :

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

1
2
3
4
5
6
 
// h_header.c
void ma_fonction(int a)
{
	printf("a x a = %d\n", a*a);
}

Et je compile comme suit :
~$ gcc -o test test.c

et j'obtiens :

Code :

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

1
2
3
/tmp/ccaWyFH8.o: In function `main':
test.c:(.text+0x27): undefined reference to `ma_fonction'
collect2: ld returned 1 exit status

Donc je dois bien oublier un truc....

[souviron34]

Donc je dois bien oublier un truc....

Comme je te l'ai dit au dessus, tu oublies de compiler h_header.c, et de lier test.c (après compilation) à h_header.o (après compil)

[n0mad]

euh oui j'avais compris mais je demandais comment on fait concrètement ! J'ai du mal m'exprimer.

J'ai trouvé l'option qui me manquait "-c"

Code :

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

1
2
3
4
 
~$ gcc -c h_header.c 
~$ gcc -c test.c    
~$ gcc h_header.o test.o  -o test

Merci =)

[Emmanuel Delahaye]

Hello,

Je souhaiterais developper (plutot découper) mon programme de la manière suivante :

programme.c
h_headers1.h
h_headers1.c

C'est techniquement possible, mais le choix des noms a son importance. En effet, la séparation entre interface (header) et implémentation (source C) est déjà faite par l'extension (.h / .c). Elle ne doit donc pas apparaitre dans le nom (il est est en effet absurde de nommer un .c, 'headers_1.c' ...)

Il faut au contraire réfléchir à la manière dont on découpe le code. Le but étant de créer une 'unité fonctionnelle' (ou bloc fonctionnel) qui rassemble les fonctions d'une même 'famille'. Cette famille peut être fonctionnelle (entrées sécurisées, affichage spécialisé etc.) ou formée autour d'un objet (structure de donnée et ensemble de fonctions permettant de la manipuler).

Tout cela n'es en aucun cas du au hasard, mais découle du processus de gestion du projet, et notamment des phases 1 (définition) et surtout 2 (conception) qui sont justement là pour organiser le développement en unités de travail homogènes (les blocs fonctionnels) le plus souvent matérialisés par un couple .h / .c. Par exemple, le bloc fonctionnel xxx est composé de xxx.h et xxx.c. (au minimum).

Le programme.c étant le code contenant le main() et compilé (gcc programme.c ...) et dans les h_* mettre toutes mes fonctions. Je souhaiterais enfaite que dans le .h il y ait les signatures des fonctions ainsi que le blabla qui va bien (commentaires!) et que dans le .c associé il y ait le code proprement dit de la fonction.

Deux questions :
1. Comment faire ? (Je pense à une manière autre que programme.c include h_headers.h qui lui-même include h_headers.c) - Je me disais qu'étant donné qu'ils ont les mêmes nom ça pourrait être implicite à la compilation ?
2. Y-a-t-il un interet ?

J'explique ici la démarche sous Code::Blocks :

http://video.google.fr/videoplay?doc...17817010204120

[n0mad]

Hello,

Merci pour vos réponses... mais ya encore une coui**e dans le potage..

Bref voila mon code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
// session.h
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
 
#ifndef _H_SESSION_H
#define _H_SESSION_H 
 
char *LOG      = NULL;
char *SESSION  = NULL;
 
void start_session(char *, int);
#endif

Code :

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

1
2
3
4
5
6
7
8
 
// session.c
#include "session.h"
 
void start_session(char *name, int flag)
{
        printf("bonjour\n");
}

Code :

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

1
2
3
4
5
6
7
8
9
10
 
// main - test.c
#include <stdio.h>
#include "session.h"
 
int main(void)
{
	start_session("toto",1);
	return 1;
}

La compilation :

Code :

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

1
2
3
4
 
~$ gcc -Wall -c session.c
~$ gcc -Wall -c test.c
~$ gcc -Wall session.o test.o -o test

session.o et test.o sont produit correctement, mais à l'assemblage finale ça coince avec :

Code :

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

1
2
3
4
5
6
 
test.o:(.bss+0x0): multiple definition of `LOG'
session.o:(.bss+0x0): first defined here
test.o:(.bss+0x4): multiple definition of `SESSION'
session.o:(.bss+0x4): first defined here
collect2: ld returned 1 exit status

Help (je dirais que ça viens du session.h qui est ajouté dans le test.c et dans le session.c ...mais du fais de mon #ifndef / #define je ne comprends pas !)

Merci de votre aide (moi ye né pas être développeur!)

:-)

[diogene]

La compilation des deux .c est faite séparément. Le .h est donc inclus dans les deux .c au moment de leur compilation.
Alors, il trouve deux globales définies deux fois: LOG et SESSION.

Ton erreur est de définir des globales dans un .h.
Un .h ne doit contenir que des définitions de types ou des prototypes ou des #define ... Jamais de définitions de variables.
Définis tes globales dans un .c (si vraiment tu en as besoin) et dans le .h déclares les en extern :

Code :

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

1
2
3
4
//.h
extern char *LOG ;
//.c
char * LOG = NULL;

[Emmanuel Delahaye]

Ton erreur est de définir des globales dans un .h.

Mais la véritable erreur est d'utiliser des globales totalement injustifiées ici ...

[n0mad]

Ouki ... donc je créer "globals.c" comme ceci :

Code :

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

1
2
3
4
 
// globals.c
char *LOG        = NULL;
char *SESSION = NULL;

et puis donc dans mon session.h je fais la même chose en ajoutant le mot extern devant les définitions.

...mais euh...le globals.c je l'inclu quand et ou ? :-)

Mais la véritable erreur est d'utiliser des globales totalement injustifiées ici ...

Mwais euh ce genre de réflexion c'est pas franchement utile car quand je pose une question je réduis le code pour ne montrer que l'essentiel....donc bon....

[diogene]

...mais euh...le globals.c je l'inclu quand et ou ? :-)

Nulle part, un .c n'a pas vocation à être inclus. Tu n'es pas forcé de créer un .c supplémentaire pour définir tes deux variables globales (si vraiment tu en as besoin)

[n0mad]

Ah oui je l'ai rajouté dans les objets tout simplement et ça roule ! merci diogene !
gcc -Wall -O3 -fomit-frame-pointer session.o globals.o test.o -o test



Bon sinon votre vraiment commence vraiment à m'ennerver ! Plus sérieusement, j'en ai besoin de ces variables globales car plusieurs fonctions (dans différents .c) y accèdent et j'ai besoin que chaque fonction ait l'état précédent.... donc sinon faudrait que je me fasse des listes d'arguments dans mes fonctions et ça me fait tout simplement chier ! ....ah moins que vous ayez des arguments en ce sens ?

Pourquoi devrais-je éviter les variables gloables ?

[Médinoc]

Variable globales --> Manque de thread-safety, manque de réentrance, risque de collision de noms.

La solution: Employer une structure, et passer à chacune de tes fonctions un pointeur vers cette structure.
C'est ce qui est fait pour les fonctions de fichier, par exemple...

[n0mad]

Uhm justement mon programme est a base de threads !

Enfaite j'ai une structure (variable globale) qui est initialisée, et les threads font des calculs sur cette structure : ils se partagent une ressource. Et je ne veux pas que chacun des threads ait sa propre ressource (car je "divise" le travail de la sorte).

[Médinoc]

Dans ce cas, une synchronisation est nécessaire.
Les objets de synchronisation, eux, sont généralement exempts de tout grief que j'ai contre les variables globales.

Mais tu peux aussi partager lesdites données (et objets de sync) par pointeur, plutôt que par variables globales. Ça reste plus propre.

[n0mad]

pour la synchro j'utilise les mutex.

Sinon je ne suis pas sur de voir ce que veux dire avec le partage par pointeurs, tu aurais un exemple stp?

[diogene]

Bon sinon votre vraiment commence vraiment à m'ennerver !

J'en suis navré. Mais, tu fais ce que tu veux. C'est ton programme. On se contente de te donner des conseils, tu en fais ce que tu veux.

donc sinon faudrait que je me fasse des listes d'arguments dans mes fonctions et ça me fait tout simplement chier ! ....ah moins que vous ayez des arguments en ce sens ?

Je sais que c'est la raison pour laquelle beaucoup introduisent des globales. Mais cette raison est la mauvaise raison (sans vouloir t'énerver le moins du monde ).

Les variables globales font que les fonctions qui les utilisent cessent d'être "autonomes". Leur comportement ne peut être déduit de leur code seul ; elles dépendent d'éléments qui leur sont extérieurs et qui peuvent être altérés par d'autres fonctions sans que cela apparaisse. Elles sont donc difficiles à écrire (oui !), à comprendre et à tester dans toutes les situations possibles y compris les moins probables.
Si un problème se pose, la question sera de savoir qui, dans tout le programme, a pu mettre une valeur inattendue dans ces globales.

Cela simplifie peut être le travail de frappe du code, mais, très souvent, on le paye au prix fort plus tard.

Mon opinion, pour résumer et si je n'ai pas été assez clair, est que ce sont des pestes

[n0mad]

lol diogène ! Ne t'inquiete pas je ne m'ennerve pas je disais cela en rigolant (a cause du jeu de mot...) bref, ton explication a du sens et je n'y avait pas pensé... jvais virer les globales inutiles =)

merci

[diogene]

jvais virer les globales inutiles