bonjour

si dans votre projet vous avez plusieurs fichier, les #include vous les mettez dans les fichiers .c ou .h parce que je vois plein de projet d'autre gens sur github qui mettent dans .h alors que m@teo21 dans son tuto mets dans .c

Les #include tu les mets ou il y en a besoin.

Par exemple des #include qui déclare des fonctions seront souvent utile dans des .c et des #include qui déclare des types seront souvent utile dans des .h

et du coup pourquo ne pas mettre tout dans le .h et inclure le .h avec le prototype des fonction dans le .c ?

Un ficher entête.h c'est fait pour être utiliser dans plusieurs fichiers.c, sinon il n'est pas utile.

Les autres fichier .c n'en on rien à faire des includes qui ne leur sont pas destiné. Et puis si tu mets tout les includes nécessaire à tout les fichier.c qui vont l'utiliser, il va être charger (d'include). 

Donc la bonne résolution, c'est de les mettre la où il y en a besoin, pas plus.

La raison exacte c'est que ça fait perdre du temps d'inclure tout dans tous les *.h. Connais tu la façon dont on compile un projet contenant plusieurs fichier ?

Globalement on va compiler tous les .c vers des .o et ensuite tu lis tout ça ensemble. Quand tu recompile, tu ne va recompiler que les fichiers qui vont avoir changés ou qui incluent des fichier qui ont changés. 

• Dans le cas ou tu inclus dans les sources, ton nombre de ficher à recompiler va se limiter au minimum, 
• Dans le cas ou tu inclus dans les headers, tu vas devoir recompiler tous les fichiers qui vont inclure ce header, et par jeux de ricochet, tous les sources qui incluent des headers qui incluent ton header… bref ça peut aller très vite.

Imaginons :imaginons trois fichiers source et deux headers :

• main.c inclue headers1.h
• source1.c inclue header1.h
• header1.h include header2.h
• source2.c inclue header2.h

Dans une configuration comme  celle ci ton système doit recompiler les trois fichiers source si tu modifier quelque chose dans header2.h

Alors que si tu fais logiquement:

• main.c inclue headers1.h
• source1.c inclue header1.h
• source1.c include header2.h
• source2.c inclue header2.h

Si tu veux comprendre comment parmeche la compilation regarde un tuto sur les makefiles, ça pourra t'intéresser

La conclusion est la même que celle de @rouloude : Donc la bonne résolution, c'est de les mettre la où il y en a besoin, pas plus.

-
Edité par ox223252 7 juin 2019 à 8:07:15

Salut,

Si SDL.h inclus string.h, c'est pour sa pomme. Si tu as besoin de string.h dans TON code alors tu l'inclus. Les fichiers.h sont normalement faits de telle sorte que la double inclusion n'est pas possible. Ne serait-ce que parce que si tu te rends compte que tu n'as plus besoin de SDL.h, il va te manquer le string.h et que tu n'es pas (obligatoirement) censé savoir ce que les autres fichiers incluent ou pas.

C'est plutôt simple :

Pour un fichier.h, si une déclaration de fonction ou de type fait allusion à un type déclaré dans toto.h, on inclus toto.h.

Pour un fichier c, si on appelle une fonction déclarée dans toto.h, on inclus toto.h, si on déclare une variable d'un type déclaré dans tata.h, on inclus tata.h même si toto.h inclus lui-même tata.h.

Bonne continuation.

mais donc si par exemple :

j'ai un fichier toto.h avec dedans les fonctions A et B, donc dans le fichier toto.c j'inclu A

j'ai un fichier titi.h avec une fonction C et une structure S. la fonction A de toto.h utilise S donc il faut que j'inclu titi.h dans toto.h

et si le fichier titi.c utilise la fonction A, j'inclu toto.h dans titi.c pour le prototype de A, mais est-ce que j'inclu titi.h dans titi.c sachant que je l'ai déjà inclu dans toto.h ?

si j'ai bien compris, drx dit que oui alors que plus haut ils disaient que non.

Quand un fichier source foo.c  fait l'inclusion de l'entête foo.h  des fonctions qu'il définit,  le compilateur va vérifier que les déclarations (dans le .h) sont cohérentes avec les définitions (dans le .c).

Donc une bonne pratique est de faire cette inclusion systématiquement, et de ne pas compter sur des inclusions indirectes, qui ne font rien gagner, par flemme de taper une ligne.  

Faut rester simple : en principe on fait un #include pour

• le fichier d'entête correspondant au source
• les fichiers d'entête des trucs qu'on importe

// main.c

#include <stdio.h>
#include <stdlib.h>

#include "toto.h"

int main(int argc, char** argv) {
    A();
    return (EXIT_SUCCESS);
}

// titi.h
#ifndef TITI_H
#define TITI_H

struct S {
    int x;
};

void C(void);

#endif /* TITI_H */

// toto.h
#ifndef TOTO_H
#define TOTO_H

void A(void);
void B(void);

#endif /* TOTO_H */

// titi.c
#include "titi.h"

void C() {
}

// toto.c
#include "toto.h"
#include "titi.h"

void A(void) {
    struct S s;
    s.x = 2;
}

void B(void) {
}

-
Edité par michelbillaud 24 juin 2019 à 9:07:29

Il faut ajouter que les headers bien faits ont un ifndef pour ne pas tout redéfinir:

#ifndef SYMBOLE

#define SYMBOLE

... texte

#endif

Ils sont lus tout de même mais ne devraient pas causer de dégats.

Je n'ai pas testé les #if ... #endif imbriqués

Si on peut mettre un symbole sur le #endif, on pourrait les imbriquer correctement

#ifdef TRUC

#else // TRUC
#error // affiche une erreur, pratique quand tu veux verifier
#endif //TRUC

-
Edité par ox223252 8 juillet 2019 à 7:55:57

C'est très bien si c'est un humain qui vérifie. Je ne connaissais pas le #error.

Si j'ai:

#if quelque chose

#if autre chose

...

#endif

#endif

Le pré-processeur fait-il le jumelage indépendamment si les conditions sont vraies ou pas?

Par exemple, si la première condition est fausse, à quel endif va-t-il sauter?

Et c'est sans compter les #else

Certains macro-assemblers acceptaient les étiquettes sur les else et les endif

Cela veut dire que le préprocesseur lit toutes les lignes et analyse toutes les commandes #?

Ainsi, dans mon exemple, si le premier  if  est faux, il va sauter au dernier  endif . J'ai bien compris?

Si il ne lisait pas toutes les lignes, comment trouverait il le #endif ?

Il n'est pas question de "sauter". Après avoir rencontré un #if dont la condition est fausse, le processeur continue à lire les lignes suivantes. Si ce sont des directives de processeur, il s'en occupe, sinon il ne produit rien en sortie.

-
Edité par michelbillaud 9 juillet 2019 à 8:07:08

le #error va affiche une erreur dans le compilateur, dans ce cas, ça permet juste de verifier que tu pass bien là ou tu veux

#ifdef A
    #ifdef B
        #define V 1
    #else
        #define V 2
    #endif
#else
    #define V 3
#endif

Si :

• A non defini : V = 3
• A defini et B non defini : V = 2
• A defini et B defini : V = 1

-
Edité par ox223252 9 juillet 2019 à 8:41:33