Discussion :

[makro]

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

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
/* 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,
@+

[Emmanuel Delahaye]

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.

[makro]

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

[elmcherqui]

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

[Emmanuel Delahaye]

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

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

[Thierry Chappuis]

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

[Médinoc]

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

[Emmanuel Delahaye]

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

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

[Emmanuel Delahaye]

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 :

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
 
#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 :

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

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 :

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

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.

[souviron34]

vi ok

mais "might be used uninitialized" m'énerve

[Emmanuel Delahaye]

vi ok

mais "might be used uninitialized" m'énerve

Pourquoi ? C'est un vrai bug.

[souviron34]

Pourquoi ? C'est un vrai bug.

bah non....

Code :

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

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

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

[Emmanuel Delahaye]

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

[daedric]

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)