Discussion :

[Melem]

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 ?

[gl]

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).

[Melem]

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.

[Erwan-Overseas]

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).

[souviron34]

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

A plus..

[Obsidian]

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.

[Melem]

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é.

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 :

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

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

superproc.c :

Code :

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

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 :

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

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.

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

A plus..

On compatit tous .

[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 ).

[D[r]eadLock]

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 superproc.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
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)

[gl]

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.

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.

[Melem]

OK. Merci à tous pour vos réponses.

[Moopie]

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