Est-il normal que mon header ne soit pas indispensable?!

Salut,
J'ai bien compris le principe de la programmation modulaire comme telle:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

/* main.c */ #include "hello.h" int main (void) { hello (); return 0; } /* hello.h */ #ifndef H_HELLO #define H_HELLO void hello (void); #endif /* guard */ /* hello.c */ #include "hello.h" #include <stdio.h> void hello (void) { puts ("Hello world!"); }

---

mais je ne comprends pas pourquoi cela marche quand même sans le fichier .h (ou de manière équivalente si je met les #include "hello.h" en comentaires).
On dit partout que c'est la bonne manière d'organiser ses fichiers, mais pourquoi mon .h semble être facultatif??! Est-il obligatoire finalement?
Merci d'avance,
@+

Citation:

---

Envoyé par makro

mais je ne comprends pas pourquoi cela marche quand même sans le fichier .h (ou de manière équivalente si je met les #include "hello.h" en comentaires).
On dit partout que c'est la bonne manière d'organiser ses fichiers, mais pourquoi mon .h semble être facultatif??! Est-il obligatoire finalement?
Merci d'avance,
@+

---

Non, ce n'est pas obligatoire.

1 - tu pourrais fournir le prototype 'a la main', mais la maintenance deviendrait cauchemardesque
2 - tu pourrais ne pas fournir de prototype, et dans ce cas, ça pourrait fonctionner (ou non, tout dépend des types), mais tu prives le compilateur des éléments indispensables qui lui permettent de coder l'appel correctement et de vérifier la cohérence des appels.

Il existe 40.000 façons de se tirer une balle dans le pied en C. Nous nous efforçons de promouvoir les quelques Bonnes Pratiques qui évitent ça.

Donc le mécanisme que tu as décrit est fortement encouragé pour ne pas dire obligatoire, du moins vu des Règles de Bonnes Pratiques.

Merci pour ta réponse, j'en prends bonne note.

Ça m'arrive souvent sous code::blocks (implicite declaration of ..... ) et sous visual si il manque quoi que se soit il compile pas .

Citation:

---

Envoyé par elmcherqui

Ça m'arrive souvent sous code::blocks (implicite declaration of ..... ) et sous visual si il manque quoi que se soit il compile pas .

---

Ça, c'est parce que tu compiles en C++... Caÿ mal.

D'ailleurs , pour éviter les balles dans le pied , on active les warnings , et aussi on respecte la norme. ( Certain mettront les warning en erreurs ... mais ça peut être excessifs ( enfin ça dépend du cas ) )

Citation:

---

Envoyé par LittleWhite

D'ailleurs , pour éviter les balles dans le pied , on active les warnings , et aussi on respecte la norme. ( Certain mettront les warning en erreurs ... mais ça peut être excessifs ( enfin ça dépend du cas ) )

---

C'est mon cas. Pourquoi est-ce excessif ?

Thierry

Quand tu as un warning "condition constante" pour ta macro qui contient un do {} while(0), c'est excessif.

Citation:

---

Envoyé par Médinoc

Quand tu as un warning "condition constante" pour ta macro qui contient un do {} while(0), c'est excessif.

---

Ca n'arrive pas avec gcc... Pour ça, il faut au moins VC++...

moi je dirais que le warning qui m'énerve le plus et que je ne mettrais jamais en erreur c'est "variable non initiialisée".. j'le sais bien, c'est moi qui l'ai fait exprès... Puisque je lui mets une valeur dedans à un moment donné, et pas avant... grrr.... ;)

Citation:

---

Envoyé par souviron34

moi je dirais que le warning qui m'énerve le plus et que je ne mettrais jamais en erreur c'est "variable non initiialisée".. j'le sais bien, c'est moi qui l'ai fait exprès... Puisque je lui mets une valeur dedans à un moment donné, et pas avant... grrr.... ;)

---

Ce warning n'existe pas. Ce qui existe, c'est "risque d'utilisation de variable non initialisée'.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <stdio.h>   int f (int x) { int ret;   if (x > 4) { ret = 1; } return ret; }   int main (void) { int x = f (3);   printf ("x = %d\n", x); return 0; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

-------------- Build: Debug in hello ---------------   Compiling: main.c Linking console executable: bin\Debug\hello.exe C:\dev\hello\main.c: In function `f': C:\dev\hello\main.c:5: warning: 'ret' might be used uninitialized in this function Output size is 18.08 KB Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 1 warnings

---

Ce qui est toutà fait justifié. Evidemment, avec ce code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

int f (int x) { int ret;   if (x > 4) { ret = 1; } else { ret = 0; } return ret; }

---

le warning disparait.

vi ok ;)

mais "might be used uninitialized" m'énerve :oops:

Citation:

---

Envoyé par souviron34

vi ok ;)

mais "might be used uninitialized" m'énerve :oops:

---

Pourquoi ? C'est un vrai bug.

Citation:

---

Envoyé par Emmanuel Delahaye

Pourquoi ? C'est un vrai bug.

---

bah non....

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int toto=1, tata, titi ;   if ( toto == 1 ) tata = 3 ;   ....   if ( toto == 1 ) { titi = tata + toto ; .... }

---

ça n'est un bug que si on se contente de déclarer les varaibles uniquement par blocs. Si la variable est globale à la fonction, et qu'on s'en sert comme ci-dessus, ça n'est pas un bug... :P

Peut-être que ça ne correspond pas à ta pratique, mais ça n'est quand même pas un bug..

Citation:

---

Envoyé par souviron34

Peut-être que ça ne correspond pas à ta pratique, mais ça n'est quand même pas un bug..

---

C'est difficile à suivre dans un code complexe... on a pas besoin de ça ! D'ailleurs, l'optimiseur de gcc jette l'éponge, et moi aussi. je préfère le code facile à lire. Ce n'est effectivement pas ma pratique (enfin j'évite).

Puis ce n'est pas maintenable, imagines qqjours apres tu changes ton code pour une raison X et tu as laisse le warning .
Pour que peu que tu ai introduit une utilisation systematique de la variable alors qu'elle n'est pas forcement initialise, tu auras des comportement bizarres (et au mieux un segfault)