La compilation séparée en C

Version imprimable

18/12/2009, 20h47
Melem

La compilation séparée en C

Tutoriel : La compilation séparée en C

Citation:

La compilation séparée désigne le fait de compiler plusieurs fichiers sources séparément puis de les lier ensuite pour générer le produit final qui peut être un exécutable par exemple. Elle comprend plusieurs techniques que nous allons explorer tout au long de ce tutoriel.

A vos commentaires ;) !

Bonjour,

Je trouve quelques limites à ce tutoriel qui pour l'instant me rebutent à le conseiller à ceux qui veulent s'initier à la compilation séparée.

Dans ce tutoriel, les fichiers d'entête sont presque abordés à la va-vite, alors que c'est un point majeur de la compilation séparée. Pour preuve, les exemples des sections II-A et II-D reprennent la mauvaise pratique de placer les déclarations de fonctions dans les .c les utilisant, alors que cet exemple typique n'apparait jamais :

dsomme.c :
Code:

1 2 3 4 5 6 7 #include "dsomme.h" int somme(int a, int b) { return a + b; }
dsomme.h :

Code:

extern int somme(int a, int b);

exemple.c :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include <stdio.h> #include <dsomme.h> int main() { int a = 2, b = 5; printf("%d + %d = %d\n", a, b, somme(a, b)); printf("%d * %d = %d\n", a, b, produit(a, b)); return 0; }
Après peut être que le fait de placer les déclarations dans un .c est une windowserie (je ne connais pas assez Windows), mais cela m'étonnerait.

Enfin idéalement, on pourrait introduire aussi les Makefile, pour les UNIXiens, mais c'est plus avancé je le concède.

En espérant avoir apporté été constructif.

Cordialement.

31/05/2011, 17h05
Melem

Je ne partage ton avis sur l'utilisation des fichiers d'en-tête, et ça n'a rien à voir avec le système. C'est juste une différence de style de codage. Personnellement, je trouve qu'il est avantageux d'utiliser un fichier d'en-tête quand il y a beaucoup de déclarations ou quand une déclaration risque d'être utilisée dans plusieurs projets ou dans plusiers fichiers sources mais pas quand on veut juste déclarer une fonction externe dans un fichier source d'un projet.

D'autre part, je pense avoir correctement introduit l'utilité et la manière d'utiliser les fichiers d'en-tête, justement parce que je suis parti d'un projet qui ne s'en servait pas. Je permets ainsi au lecteur d'assister en direct à la transformation d'un projet mal conçu en un projet correctement conçu.

Citation:

Enfin idéalement, on pourrait introduire aussi les Makefile, pour les UNIXiens, mais c'est plus avancé je le concède.

"Make" peut aussi être utilisé sous Windows bien qu'il existe d'autres solutions plus avancées comme msbuild par exemple, mais les développeurs préfèrent de toute façon utiliser un EDI plutôt qu'un logiciel en ligne de commandes. Ainsi, pour alléger le tutoriel, j'ai opté pour la solution EDI - la plus simple - plutôt que de présenter 1000 façons d'arriver au même résultat. Mais c'est vrai que du coup j'étais pas très sympa envers les unixiens :P.
31/05/2011, 18h36
PIC16F877A

())))))))

merci pour le tout :ccool:
31/05/2011, 20h40
Lucien63

Citation:

Nous allons créer un programme qui affiche la somme et la différence de deux nombres...
31/05/2011, 21h38
Melem

Citation:

Envoyé par PIC16F877A

merci pour le tout :ccool:

Content pour toi ;).
Lucien63 : Merci.
01/06/2011, 10h27
pfeuh

Citation:

Envoyé par Sékiltoyai

la mauvaise pratique de placer les déclarations de fonctions dans les .c les utilisant

Peux tu développer? Il me semble que si des fonctions, des variables ou des structures doivent être opaques, il est normal de les déclarer dans le fichier C. Les déclarer dans le fichier h, c'est donner l'accès à tous et augmenter la portée de ces objets.

@Melem j'aime bien, je trouve juste un peu dommage que tu aies choisi un IDE au départ (codeblocks) pour passer sur un autre (MS Visual Studio .NET) au chapitre des bibliothèques.

A+

Pfeuh
01/06/2011, 12h08
Melem

Citation:

Envoyé par pfeuh

Peux tu développer? Il me semble que si des fonctions, des variables ou des structures doivent être opaques, il est normal de les déclarer dans le fichier C. Les déclarer dans le fichier h, c'est donner l'accès à tous et augmenter la portée de ces objets.

Sékiltoyai ne parlait pas des structures opaques, en plus tu sembles encore mélanger "déclaration" et "définition" mais au fond, tu as tout à fait raison.

Citation:

Envoyé par pfeuh

@Melem j'aime bien, je trouve juste un peu dommage que tu aies choisi un IDE au départ (codeblocks) pour passer sur un autre (MS Visual Studio .NET) au chapitre des bibliothèques.

Je me suis dit que dans la partie I, les techniques présentées pouvaient s'appliquer sous n'importe quel système et qu'il serait donc mieux d'utiliser un EDI multiplateforme alors que dans la partie II, il fallait choisir un système et comme j'ai choisi Windows, je suis passé à l'EDI de référence sous Windows à savoir Visual mais c'est tordu en effet :D. Que dis-tu d'utiliser les deux tout au long du tutoriel ?
02/06/2011, 12h09
Erwan-Overseas

Citation:

Envoyé par pfeuh

Peux tu développer? Il me semble que si des fonctions, des variables ou des structures doivent être opaques, il est normal de les déclarer dans le fichier C. Les déclarer dans le fichier h, c'est donner l'accès à tous et augmenter la portée de ces objets.

@Melem j'aime bien, je trouve juste un peu dommage que tu aies choisi un IDE au départ (codeblocks) pour passer sur un autre (MS Visual Studio .NET) au chapitre des bibliothèques.

A+

Pfeuh

Si on compile le .h, alors le .h n'est pas visible (le .h compile est utilise directement), et la fonction est declaree dans un .h. (apres c'est pas forcement intelligent).

vu que tu parles d'IDE,

Citation:

Envoyé par Melem

(...) mais les développeurs préfèrent de toute façon utiliser un EDI plutôt qu'un logiciel en ligne de commandes. (...)

je prefere les lignes de commandes qui marchent, a un ide qui plante.

Sinon par rapport au tutoriel, je comprend pas non plus l'interet de la declarer dans le .c, et c'est peut etre un gout personnel, mais je prefererais voir static devant la fonction elle meme.

(sinon c'est un bon tutoriel, pour qui utilise windows).
03/06/2011, 08h33
pfeuh

Citation:

Envoyé par Melem

comme j'ai choisi Windows, je suis passé à l'EDI de référence sous Windows à savoir Visual mais c'est tordu en effet

Vu que codeblocks est multiplateformes, il y a de grandes chances pour que la gestion des librairies soit identique pour tout le monde. Je pense que s'il y a un IDE de référence, c'est bien celui là.

Citation:

Envoyé par Erwan-Overseas

Si on compile le .h, alors le .h n'est pas visible (le .h compile est utilise directement), et la fonction est declaree dans un .h. (apres c'est pas forcement intelligent).

Donc 2 headers à gérer, un pour la compilation et un pour la distribution? C'est une approche que j'ai essayée, mais assez pénible pour la maintenance. Problèmes de synchro entre les 2 headers. C'est vraiment source de bugs durs à cerner.

Un compromis serait d'appeler le header public par le header qui fabrique la libraire. Comme ça, pas de doublon.
03/06/2011, 10h20
Melem

Citation:

Envoyé par Erwan-Overseas

Si on compile le .h, alors le .h n'est pas visible (le .h compile est utilise directement), et la fonction est declaree dans un .h. (apres c'est pas forcement intelligent).

Qui compile des .h ?

Citation:

Envoyé par Erwan-Overseas

je prefere les lignes de commandes qui marchent, a un ide qui plante.

C'est sûr que s'il pante je ne vois pas trop l'intérêt de l'utiliser. Heureusement qu'avec mes 8 ans d'expérience avec les EDIs, je n'ai jamais rencontré ce problème.

Citation:

Envoyé par Erwan-Overseas

Sinon par rapport au tutoriel, je comprend pas non plus l'interet de la declarer dans le .c, et c'est peut etre un gout personnel, mais je prefererais voir static devant la fonction elle meme.

Dans ce cas, on n'aurait qu'un seul fichier source et ça ne doit pas être le meilleur exemple de mise en oeuvre de la compilation séparée.

Citation:

Envoyé par Erwan-Overseas

sinon c'est un bon tutoriel, pour qui utilise windows

Merci. Et j'espère que j'ai fait le bon choix en choisissant Windows car l'écrasante majorité des tutoriels et même des livres de C sont déjà orientés unix. Pauvres windowsiens toujours délaissés :cry:.

Citation:

Envoyé par pfeuh

Vu que codeblocks est multiplateformes, il y a de grandes chances pour que la gestion des librairies soit identique pour tout le monde. Je pense que s'il y a un IDE de référence, c'est bien celui là.

Le plus utilisé peut-être ? Je n'en ai aucune idée. Ce qui est sûr par contre c'est que le l'EDI de référence sous Windows, c'est bien Visual ;).
03/06/2011, 11h15
Erwan-Overseas

Citation:

Envoyé par pfeuh

(...)Donc 2 headers à gérer, un pour la compilation et un pour la distribution? C'est une approche que j'ai essayée, mais assez pénible pour la maintenance. Problèmes de synchro entre les 2 headers. C'est vraiment source de bugs durs à cerner.

Un compromis serait d'appeler le header public par le header qui fabrique la libraire. Comme ça, pas de doublon.

Je suis d'accord pour dire que c'est sources de probleme, d'autant plus qu'un header compile est souvent d'une taille importante...
Je n'utilise jamais de header compile.
Simplement pour dire, que l'on peut declarer dans un .h, et rester opaque.

@melem:
la compilation de .h existe (et elle est necessaire), je n'ai pas dit qu'avoir des header precompile soit d'une utilite capitale (je me cite "apres c'est pas forcement intelligent", ce qui ne veut pas dire que ca ne peut pas l'etre).

Moi en 10 minutes je fais cracher eclipse, np++ et consorts. (j'avou que visual studio n'a jamais crashe, mais je l'utilise si peu), d'une maniere generale, edi, ou simplement sous taches utile au developpement, les lignes de commande, et le travail sur un terminal, offre une foule bien vaste de possibilite, apres les EDI ont leur gros avantages... question de taches, et de gouts.

"Dans ce cas, on n'aurait qu'un seul fichier source et ça ne doit pas être le meilleur exemple de mise en oeuvre de la compilation séparée."
je ne dis pas d'utiliser des fonctions static partout, d'ailleurs, c'est pas ce que j'ai di (je ne vais pas me citer... :) ).
simplement, si tu connais ton tuto, tu sais que tu as declarer dans un fichier c un prototype de fonction prefixe du mot clef 'static', alors, plutot qu'un prototype local, on peut developper de bas en haut, et mettre le mot clef static devant la fonction plutot que devant le prototype, me semble plus clair (surtout si on supprime le prototype).

et enfin, je suis d'accord avec toi, ce tutoriel est utile.
je l'ai di avec moins d'emotion, si je le trouvais inutile, alors apporterais-je d'inutiles commentaires?
03/06/2011, 14h25
souviron34
bin, je vais ajouter mon commentaire...
- introduction :
  
  on ne précise pas grand chose d'intéressant... Ce qui serait plus utile serait de signaler qu'un langage comme le C, compilé, n'est pas exécutable directement, et qu'il faut passer par une transformation (bref, expliquer ou pointer vers Wiki pour expliquer ce qu'est la différence entre un fichier d'instructions ASCII, une compilation, et une édition de liens).
- le projet :
  
  on arrive de but en blanc sur 2 fichiers.. Pédagogiquement, il serait bon de commencer par un, puis d'expliquer que l'intéressant est de pouvoir séparer les fonctions dans un fichier séparé (avec les diverses raisons : modification, exportation, clarté..). Ce qui donnerait le pourquoi on veut un .h (voir plus bas)
- Tu donnes la compilation sous CodeBlock. Une compilation sous unixoide (ou cygwin) serait également pédagogiquement un bon exemple, puisqu'on voit chaque étape de la compilation séparément.
- le mot-clé extern :
  
  Citation:
  
  Nous avons déjà résolu le problème pour les fonctions, ne reste donc plus que les variables
  
  Késako ? D'où ça vient ? On a rien résolu du tout à ce stade, et il n'y a pas d'explication (d'autant plus que tu ne te sers pas d'extern...)
- le mot-clé static : erreur, puisque tu déclares le protype en static mais pas la fonction...
- les fichiers d'entête : outre le fait que cela arrive comme un cheveu sur la soupe (voir plus haut), là encore tu ne déclares pas les prototypes comme extern.. Mauvaise pratique...
- les structures opaques : pourquoi prendre comme exemple ça, qui est compliqué et inutile ? Pourquoi ne pas se servir simplement de FILE, ou de struct tm, et pourquoi parler directement de créateur/destructeur ??? quand on utilise FILE, on n'a ni créateur ni destructeur en tant que tel... Notions inutiles et superflues dans le cadre des types opaques (en outre, Emmanuel Delahaye a fait un excellent chapitre dessus, si tu veux expliquer vraiment réfère-toi à cette partie de son cours).
- Les bibliothèques :
  - Bibliothèques statiques :
    
    Citation:
    
    Une bibliothèque statique (.lib ou .a) est un fichier qui regroupe un ou plusieurs modules objets. Elles s'utilisent donc de la même manière que ces derniers.
    
    C'est également vrai des bibliothèques dynamiques, et NON elles ne s'utilisent pas de la même manière (il faut les mot-clés spéciaux à l'édition de lien)
    
    Ces explications seraient à remonter dans "blibliothèques", la seule différence entre statique et dynamqiue étant dans le recopiage du code (donnant un binaire autonome) ou dans l'insertion d'une adresse de jump (donnant un binaire nécessitant la présence runtime de la DLL en question)..
  - bibliothèque dynamqiue :
    
    mêmes remarques
    
    Citation:
    
    Une bibliothèque dynamique est un fichier qui ne sera effectivement lié à l'exécutable que pendant l'exécution
    
    Ceci est faux (c'est lié à la compil puisqu'on insère l'adresse du début de la fonction)
- le concept d'API :
  
  outre le fait que ce chapitre est franchement plus que faible (avec un tel titre) quel est son intérêt dans le cadre des fichiers d'entête si ce n'est simplement d'égaler API avec définition dans le .h ?
Désolé, mais je trouve pas mal à y redire...

Citation:

Envoyé par Melem

Personnellement, je trouve qu'il est avantageux d'utiliser un fichier d'en-tête quand il y a beaucoup de déclarations ou quand une déclaration risque d'être utilisée dans plusieurs projets ou dans plusiers fichiers sources mais pas quand on veut juste déclarer une fonction externe dans un fichier source d'un projet.

Je suis plutôt d'accord avec Sékiltoyai. En effet, si tu change le prototype d'une fonction, il faut la changer dans le .c de celui qui appelle la fonction. Ça ne devient "plus" modulaire. Et pire, le compilo peut ne rien voir et générer du code faux (genre somme prend des pointeurs ou une signature différente). Après les compilo windows ajoute peut-être les signatures des fonctions dans les objets, mais pas gcc.
Exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 #include <stdio.h> extern int somme(int a, int b); int main(void) { int a = 5; int b = 10; printf("somme(%d,%d) = %d\n", a, b, somme(a, b)); return 0; }
Code:

1 2 3 4 int somme(int *a, int *b) { return *a + *b; }
À la compil, aucun warning, rien (sauf si -Wmissing-prototypes, et encore, si on ajoute int somme(int *, int*); (ce qui est "redondant" avec ce qu'il y a dans main.c) ça passe), par contre à l'exécution...

Pour moi, tout ce qui est accessible dans un objet doit être clairement défini (et donc dans un .h).

03/06/2011, 14h33
souviron34

Citation:

Envoyé par D[r]eadLock

Pour moi, tout ce qui est accessible dans un objet doit être clairement défini (et donc dans un .h).

absolument, et être déclaré comme extern.

Toutes les autres doivent être déclarées comme static (ou extern si c'est dans un .h privé)
03/06/2011, 19h24
Melem

Je suis plutôt d'accord avec souviron34 pour cette remarque :

Citation:

on arrive de but en blanc sur 2 fichiers.. Pédagogiquement, il serait bon de commencer par un, puis d'expliquer que l'intéressant est de pouvoir séparer les fonctions dans un fichier séparé (avec les diverses raisons : modification, exportation, clarté..). Ce qui donnerait le pourquoi on veut un .h (voir plus bas)

Présentée de cette façon là, on peut en effet éviter de déclarer des fonctions dans un .c tout en gardant une bonne pédagogie. Merci de ton tuyau.

Je le suis nettement moins avec les autres :

Citation:

Envoyé par souviron34

Tu donnes la compilation sous CodeBlock. Une compilation sous unixoide (ou cygwin) serait également pédagogiquement un bon exemple, puisqu'on voit chaque étape de la compilation séparément.

On ne voit pas chaque étape de la compilation dans l'EDI ? Peux-tu expliquer ce que l'on ne voit pas ?

Citation:

Envoyé par souviron34

le mot-clé extern :

Citation:

Nous avons déjà résolu le problème pour les fonctions, ne reste donc plus que les variables

Késako ? D'où ça vient ? On a rien résolu du tout à ce stade, et il n'y a pas d'explication (d'autant plus que tu ne te sers pas d'extern...)

On a résolu le problème d'utilisation d'une fonction externe : il suffit de la déclarer. On n'avait pas besoin d'extern pour ça, comme il est clairement expliqué dans le tutoriel. Et à la ligne que tu cites on s'apprête à voir comment utiliser une variable externe. Là il faut maintenant extern. Mais ce n'est peut-être pas assez clair, donc je vais essayer de trouver une meilleure tournure.

Citation:

Envoyé par souviron34

les structures opaques : pourquoi prendre comme exemple ça, qui est compliqué et inutile ? Pourquoi ne pas se servir simplement de FILE, ou de struct tm, et pourquoi parler directement de créateur/destructeur ??? quand on utilise FILE, on n'a ni créateur ni destructeur en tant que tel... Notions inutiles et superflues dans le cadre des types opaques (en outre, Emmanuel Delahaye a fait un excellent chapitre dessus, si tu veux expliquer vraiment réfère-toi à cette partie de son cours).

- Contrairement à ce que tu dis, je ne connais pas d'exemple plus simple de structure opaque. Certes inutile dans la vie pratique, mais le but était de présenter le plus simplement possible le concept, pas de proposer une bibliothèque professionnelle.
- FILE est une structure bien plus compliquée que celle que j'ai proposée, et son implémentation est inconnue, ou du moins dépendante du système.
- struct tm n'est pas une structure opaque ...
- Et pourquoi parler directement de créateur/destructeur ? Parce qu'une structure opaque en a obligatoirement besoin. Par exemple pour la structure FILE : constructeur = fopen, destructeur = fclose.
- Je ne sais pas si on aura l'honneur et le plaisir d'avoir Emmanuel dans ce fl, mais j'ose espérer qu'il sera plutôt du même avis que moi sur ce coup là.

Citation:

Envoyé par souviron34

le mot-clé static : erreur, puisque tu déclares le protype en static mais pas la fonction...

La norme ne requiert pas que la définition commence aussi avec le mot-clé static. static est juste requis dans la déclaration :

Citation:

Envoyé par 6.2.2 Linkages of identifiers

If the declaration of a file scope identifier for an object or a function contains the storageclass specifier static, the identifier has internal linkage.

Tu as du mélanger avec inline ou autre chose ;).

Citation:

Envoyé par souviron34

Citation:

Une bibliothèque statique (.lib ou .a) est un fichier qui regroupe un ou plusieurs modules objets. Elles s'utilisent donc de la même manière que ces derniers.

C'est également vrai des bibliothèques dynamiques, et NON elles ne s'utilisent pas de la même manière (il faut les mot-clés spéciaux à l'édition de lien)

Ton attitude est celle d'une personne qui cherche juste à critiquer mais pas à comprendre, et moins encore à construire. Ce n'est pas non plus comme si j'ai laissé le tutoriel s'achever sur cette phrase. Il y a une suite qu'il faut lire ...

Même remarque pour l'histoire de bibliothèque dynamique.

Citation:

Envoyé par souviron34

le concept d'API :

outre le fait que ce chapitre est franchement plus que faible (avec un tel titre) quel est son intérêt dans le cadre des fichiers d'entête si ce n'est simplement d'égaler API avec définition dans le .h ?

Là aussi je suis d'accord. En fait, je voulais à la base fournir une petite initiation à l'utilisation de l'API Windows en guise d'application pratique supplémentaire de ce que l'on vient d'apprendre, mais j'ai mis du temps à trouver un bon thème et à la longue j'ai abandonné l'idée sans supprimer cette pauv' section. Je me suis dit que ça fera toujours un peu de terminologie :P. Maintenant qu'on en reparle, l'API MCI Audio serait peut-être un bon thème ? Une deuxième démo avec cette fois-ci une bibliothèque open source aussi serait peut-être aussi la bienvenue. Je pense en ce moment à PDCurses. Qu'en dis-tu ?

Citation:

Envoyé par D[r]eadLock

Je suis plutôt d'accord avec Sékiltoyai. En effet, si tu change le prototype d'une fonction, il faut la changer dans le .c de celui qui appelle la fonction. Ça ne devient "plus" modulaire.

Ici, le but n'était pas encore de parler de modularité ni de réutilisabilité du code. Je voulais juste montrer qu'il était possible de répartir l'implémentation d'un projet sur plusieurs fichiers sources. C'est après seulement qu'il est intéressant de se poser le problème de modularité. Voilà comment moi je décompose un problème complexe en sous-problèmes simples selon les principes exposés par Descartes dans son fameux Discours sur la méthode. Avec la décomposition proposée par souviron34, ça va encore aller mieux.

Citation:

Envoyé par D[r]eadLock

Et pire, le compilo peut ne rien voir et générer du code faux (genre somme prend des pointeurs ou une signature différente).

Et c'est quoi la différence ici si on utilisait un fichier d'en-tête ?

Merci pour toutes vos critiques et n'hésitez surtout pas s'il y en a d'autres.

Melem
04/06/2011, 22h52
D[r]eadLock
Citation:

Envoyé par Melem

Et c'est quoi la différence ici si on utilisait un fichier d'en-tête ?

C'est que tu es obligé (si tu compiles avec -Werror, ou du moins supprime les warnings les plus dangereux) d'avoir un code correct:
- Si tu oublies de modifier le .h: tu as une erreur à la compil du source qui implémente la fonction error: conflicting types for 'somme'
- Si tu oublies de modifier le "client" (le main), tu as un warning/erreur: genre argument 1 makes pointer from integer without a cast
En gros le compilo t'aide à changer tes prototypes sans faire de grosses boulettes.

Le seul 'danger' (i.e. de faire confiance au compilo en cas de changement d'API) est d'oublier d'inclure le .h dans le .c qui implémente la fonction (c'est pour ça que gcc propose -Wmissing-prototypes pour "forcer" la définition à être quelque part (pour moi, dans un .h :wink:), à noter que ce warning ne s'applique pas aux fonctions 'static')).

Si je relève ce point (mettre le extern... dans un .h) c'est que je suis déjà tombé sur des cas comme ça au boulot et qui auraient pu être évité par des bonnes pratiques. Du coup, je trouve 'dangereux' de "dire" que l'on peut mettre des 'extern...' dans du code "client" qui pour moi relève plus du hack de la programmation "propre" :wink:
05/06/2011, 00h26
Melem

Citation:

Envoyé par D[r]eadLock

En gros le compilo t'aide à changer tes prototypes sans faire de grosses boulettes.

Je vois.

Citation:

Envoyé par D[r]eadLock

Du coup, je trouve 'dangereux' de "dire" que l'on peut mettre des 'extern...' dans du code "client" qui pour moi relève plus du hack de la programmation "propre"

Ce que moi j'en pense, c'est que le C en tout cas le permet et que je ne vois donc toujours pas d'inconvénient à l'utiliser dans un but pédagogique. Ce qu'il manque réellement, c'est un avertissement sur ses éventuels dangers. En plus, ça fera une bonne introduction aux fichiers d'en-tête. Mais j'avoue que le plan proposé par souviron34 aussi est tout aussi intéressant. Personnellement, lequel trouves-tu meilleur ?

Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 #include <stdio.h> - static int id(int x); /* ... */ - int id(int x) + static int id(int x) { return x; } - int main() + int main(void) { int x = 0; printf("id(%d) = %d\n", x, id(x)); return 0; }
remise des fonctions dans l'ordre,
l'ordre ne compte pas. (analogie avec l'arrangement). (mon humour est particulier... :lol:)

apres juste pour la forme, une fonction produit qui marche, avec les elements qu'elle accepte selon son prototype, pourrait avoir du sens.
(depassement de la valeur d'un int en retour (ce qui est acceptable... tout comme pour l'addition), impossibilite d'avoir b negatif fonctionnel). mais c'est juste pour la forme.

05/06/2011, 18h41
gl

Citation:

Envoyé par souviron34

les fichiers d'entête : outre le fait que cela arrive comme un cheveu sur la soupe (voir plus haut), là encore tu ne déclares pas les prototypes comme extern.. Mauvaise pratique...

Sur un prototype, extern n'est pas indispensable (l'absence de "storage class specifier" est équivalent à l'utilisation de extern).

Dans le cas d'une déclaration à l'intérieur d'un fichier source, la présence d'extern peut éventuellement avoir un rôle documentaire intéressant.
Dans un header, à part pour avoir une symétrie entre la déclaration de fonction et la déclaration de variable, il n'y a pas vraiment d'intérêt. En tout cas rien qui puisse faire considérer l'absence d'extern comme une mauvaise pratique dans l'absolue [1].

Citation:

Envoyé par Melem

La norme ne requiert pas que la définition commence aussi avec le mot-clé static. static est juste requis dans la déclaration

Juste un petit aparté, or cas particulier d'appel croisé, je n'ai jamais vu réellement d'intérêt à avoir à la fois une simple déclaration et une définition d'une fonction static.
Je préfère amplement n'avoir qu'une définition et ordonner mes fonctions correctement.

[1] Si la norme de codage l'impose, je conçois que ne pas le mettre et donc ne pas respecter les conventions stylistiques de ladite norme soit une mauvaise pratique. Mais là ce qui pêche n'est pas l'absence de extern en soi mais le non respect de la norme.
05/06/2011, 19h50
Melem

Citation:

Envoyé par gl

Juste un petit aparté, or cas particulier d'appel croisé, je n'ai jamais vu réellement d'intérêt à avoir à la fois une simple déclaration et une définition d'une fonction static.
Je préfère amplement n'avoir qu'une définition et ordonner mes fonctions correctement.

Personnellement, je préfère toujours avoir main au niveau le plus haut possible dans le fichier source plutôt que tout en bas. De façon générale, si je dois implémenter, dans un fichier func.c, une fonction func qui appelle des fonctions f1, f2 et f3 que je dois implémenter dans le même fichier, je commencerai mon fichier par func même si f1, f2 et f3 doivent naturellement dans ce cas être déclarées static. Ou alors mettre f1, f2 et f3 dans un fichier .h, mais est-ce que ça se fait ?
05/06/2011, 22h43
gl

Citation:

Envoyé par Melem

Personnellement, je préfère toujours avoir main au niveau le plus haut possible dans le fichier source plutôt que tout en bas. De façon générale, si je dois implémenter, dans un fichier func.c, une fonction func qui appelle des fonctions f1, f2 et f3 que je dois implémenter dans le même fichier, je commencerai mon fichier par func même si f1, f2 et f3 doivent naturellement dans ce cas être déclarées static.

Pourquoi ?

En dehors d'un choix de style (que je peux tout à fait comprendre), qu'apportes le fait de commencer le fichier par func ? (il s'agit d'une vrai question, je ne vois vraiment ce que ça apporte).
05/06/2011, 23h04
Melem

Citation:

En dehors d'un choix de style (que je peux tout à fait comprendre), qu'apportes le fait de commencer le fichier par func ?

Vu que func.c est censé avant tout contenir l'implémentation de la fonction func, ça permet d'avoir la fonction principale (ici func) au premier plan et détails (les "sous-procédures") en second plan.
06/06/2011, 13h12
Erwan-Overseas

Citation:

Envoyé par Melem

Personnellement, je préfère toujours avoir main au niveau le plus haut possible dans le fichier source plutôt que tout en bas. De façon générale, si je dois implémenter, dans un fichier func.c, une fonction func qui appelle des fonctions f1, f2 et f3 que je dois implémenter dans le même fichier, je commencerai mon fichier par func même si f1, f2 et f3 doivent naturellement dans ce cas être déclarées static. Ou alors mettre f1, f2 et f3 dans un fichier .h, mais est-ce que ça se fait ?

Ça a le risque de faire des warning a la compilation (j'ai eu la faiblesse de me souvenir que cela générait une erreur) si on fait des .h utilisable pour tout un projet.

D'une façon générale, même si c'est possible...
Si on a des fichiers de code bien structure, on a pas besoin de .h pour comprendre une fonction static.
Et le fait de mettre static devant l’implémentation d'une fonction static est seloin moi la base.

Je pense que le seul cas ou ce serait utile... c'est lorsque une fonction portant le même nom dans plusieurs fichier du projet serait systématiquement implémente différemment.
(j'ai jamais fait ça... mais ça peut avoir du sens).
06/06/2011, 16h21
souviron34

grrr... Je reviendrais mais ça fait 1h1/2 que je tapais une réponse et ça a disparu....

A plus..
:calim2::calim2::calim2::calim2:
06/06/2011, 16h44
Obsidian

Citation:

Envoyé par souviron34

grrr... Je reviendrais mais ça fait 1h1/2 que je tapais une réponse et ça a disparu....

Ça, c'est agaçant quand ça arrive. C'est pour cela que, passé un certain temps, je me mets toujours à faire un copier-coller de ce que je suis en train d'écrire.

Cela dit, les dernières versions de Firefox (au moins depuis 3.6, peut-être avant) sont censées être protégées contre ça. J'avais un pilote défectueux sur ma distrib' Linux qui faisait que mon PC tout neuf plantait sans arrêt (bug qui a duré un temps, puis qui a complètement disparu un jour après une mise à jour). Il m'est aussi arrivé de l'éteindre en oubliant le navigateur ouvert sur un autre bureau.

Dans les deux cas, au redémarrage de Firefox, celui-ci m'a restauré ma session avec le texte que j'étais en train d'écrire dans les boîtes idoines.
06/06/2011, 20h49
Melem
Citation:

Envoyé par Erwan-Overseas

En fait, ca a le risque de faire des warning a la compilation (j'ai eu la faiblesse de me souvenir que cela generait une erreur) si on fait des .h utilisable pour tout un projet.

Justement, je n'ai jamais dit que j'allais utiliser le .h dans ailleurs que dans le fichier .c qui lui est associé.

Citation:

Envoyé par Erwan-Overseas

D'une facon generale, meme si c'est possible...
Si on a des fichiers de code bien structure, on a pas besoin de .h pour comprendre une fonction static.
Et le fait de mettre static devant l'implementation d'une fonction static est seloin moi la base.

Je pense que le seul cas ou ce serait utile... c'est lorsque une fonction portant le meme nom dans plusieurs fichier du projet serait systematiquement implemente differemment.
(j'ai jamais fait ca... mais ca peut avoir du sens).

Je ne sais pas si on s'est bien compris mais ce que je cherche à faire c'est ceci :

superproc.h :
Code:

1 2 3 4 #ifndef H_SUPERPROC_H #define H_SUPERPROC_H void superproc(int a, int b, int c); #endif
superproc.c :
Code:

1 2 3 4 5 6 7 8 9 #include "superproc.h" #include "superproc_intern.h" void superproc(int a, int b, int c) { proc1(a); proc2(b); proc3(c); }
superproc_intern.h :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 /* Utilisation reservee au fichier superproc.c */ /* Toutes les fonctions static ici ... */ static void proc1(int a) { ... } static void proc2(int b) { ... } ...
Ma question est : est-ce que quelqu'un d'autre moi a déjà pensé à faire ça.
Puis quelle que soit votre réponse : qu'en pensez-vous de cette pratique.

Citation:

Envoyé par souviron34

grrr... Je reviendrais mais ça fait 1h1/2 que je tapais une réponse et ça a disparu....

A plus..
:calim2::calim2::calim2::calim2:

On compatit tous :D.
06/06/2011, 21h17
Erwan-Overseas

honettement, je pense que un .h n'est pas fait pour mettre du code...
en c++, a la rigueur dans du hpp deux trois trucs vite fait (des trucs vides, ou des methodes pures...).
mais une fonction... je trouve ca etonnant...

apres je vais me contenter de dire que c'est un avis personnel... ( qui ne fait que s'inspirer de ce que j'aurai pu voir ici ou la ).

Citation:

Envoyé par Melem

1) Ma question est : est-ce que quelqu'un d'autre moi a déjà pensé à faire ça.
2) Puis quelle que soit votre réponse : qu'en pensez-vous de cette pratique.[_intern.h]

1) Non et oui.
2) Si ça ne doit apparaître que dans un fichier au final autant tout mettre dans le .c:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #include "superproc.h" /* internal functions declaration */ static void proc1(int a); static void proc2(int b); /* super function */ void superproc(int a, int b, int c) { proc1(a); proc2(b); proc3(c); } /* internal implementation */ static void proc1(int a) { ... } static void proc2(int b) { ... }
1) donc non pour le cas où le .h n'est appelé qu'une seule fois mais sinon oui, pour du debug, i.e. avec un fichier debug.h inclus un peu partout, avec des macros qui génèrent des fonctions statiques, mais là elles sont uniquement définies s'il y a les #define qui vont bien avant (sinon gcc miaule quand une fonction static est définie, mais non appelée)

06/06/2011, 22h31
gl

Citation:

Envoyé par Melem

Vu que func.c est censé avant tout contenir l'implémentation de la fonction func, ça permet d'avoir la fonction principale (ici func) au premier plan et détails (les "sous-procédures") en second plan.

OK.

De mon point de vue, cet avantage ne compense l'inconvénient de devoir écrire et maintenir une déclaration et une définition alors que ce n'est pas obligatoire. Mais je comprends le point.

Citation:

Envoyé par Melem

1 - Ma question est : est-ce que quelqu'un d'autre moi a déjà pensé à faire ça.
2 - Puis quelle que soit votre réponse : qu'en pensez-vous de cette pratique.

1 - Oui.
2 - En pratique ce n'est pas terrible. Si le .h n'est destiné à n'être inclus qu'une fois ça n'apporte pas grand chose, si le .h est destiné à être inclus dans plusieurs sources tu introduit un couplage avec l'implémentation de la fonction qui n'existerait pas avec une fonction classique avec tout ce que ça sous entends en terme de recompilation inutile, de duplication dans l'exécutable, etc.
07/06/2011, 13h05
Melem

OK. Merci à tous pour vos réponses.
31/08/2013, 21h18
Moopie

Merci, ça m'a bien aidé c'est se que je cherchais ;)