division en fichiers

[Portnaouak]

Bonjour à tous et à (peut être) toutes,
Je me suis lancé il y a peu dans le developpement pour NDS avec PALIB. J'ai voulu faire une chose assez simple: une fonction qui affiche une map en fonction d'une tile map défini.
Tout va pour le mieux aucun probléme ne se pose à l'horizon.
Par soucis de lisibilité du code, je veux séparer la fonction ainsi que le struct du tile map dans un autre fichier.
Hop je crée un fichier, je mais les #define habituels, je met les include palib + gfx. et la c'est le drame...
Un Bon nombre d'erreurs appraissent. J'ai cherché pendant un bout de temps, abandonné une semaine ou deux et je suis revenu dessus, et je ne trouve toujours pas de solution. Alors je viens vous exposer mon probléme espérant trouver une solution.

Voici le rapport d'erreurs obtenu:
main.c
map.c
arm-elf-g++ -g -mthumb-interwork -mno-fpu -L/c/devkitPro/PAlib/lib -specs=ds_arm9.specs testtile.o main.o map.o -L/c/devkitPro/PAlib/lib -lpa9 -L/c/devkitPro/libnds/lib -lnds9 -o build.elf
map.o: In function `LoadMap':
c:/devkitPro/tiletest/source/map.c:18: multiple definition of `LoadMap'
main.o:c:/devkitPro/tiletest/source/map.c:18: first defined here
map.o: In function `LoadMap':
c:/devkitPro/tiletest/source/map.c:18: multiple definition of `testtile_Tiles'
main.o:c:/devkitPro/tiletest/source/main.c:14: first defined here
map.o: In function `LoadMap':
c:/devkitPro/tiletest/source/map.c:24: multiple definition of `testtile_Pal'
main.o:c:/devkitPro/PAlib/include/nds/PA9.h:287: first defined here
map.o: In function `LoadMap':
c:/devkitPro/tiletest/source/map.c:18: multiple definition of `testtile_Map'
main.o:c:/devkitPro/tiletest/source/main.c:13: first defined here
map.o: In function `LoadMap':
c:/devkitPro/tiletest/source/map.c:18: multiple definition of `testtile_Width'
main.o:c:/devkitPro/tiletest/source/main.c:12: first defined here
map.o: In function `LoadMap':
c:/devkitPro/tiletest/source/map.c:18: multiple definition of `testtile_Height'
main.o:c:/devkitPro/tiletest/source/main.c:12: first defined here
collect2: ld returned 1 exit status
make[1]: *** [/c/devkitPro/tiletest/tiletest.elf] Error 1
make: *** [build] Error 2

Et pour que vous puissiez voir vous même le probléme:
le projet sous vham (http://portnaouak59.free.fr/testtile.rar)

Je vous remercie d'avance pour vos réponse.

[Link Mauve]

A mon avis, le problème vient du fait que tu charge plusieur fois ton #define:whst: : dans un while ou autres... après peut-être que je me gourre totalement...:lol:

[Portnaouak]

bah non parce que j'ai pensé à ça, je me suis arrangé pour n'avoir qu'une seule fois un inclusion de chaque fichier et ca fait toujours pareil.

[Dr.Vince]

salut.

si tu veux qu'on t'aide tu devrais poster tes sources

[thoduv]

En C, il faut proteger les fichiers H.
Pour déclarer une vaiable dans un fichier H, il faut la déclarer externe, puis l'initialiser dans un fichier compilé C.

fichier.h
#ifndef __FICHIER_H__
#define __FICHIER_H_

extern int une_variable;
extern void une_fonction();

#endif /*__FICHIER_H__


fichier.c

#include "fichier.h"

int une_variable = 0;

void une_fonction()
{
}

[Yodajr]

Moi je comprend pas, j'ai jamais utilisé ces ifndef and co, et ca a toujours marché :huh:
Je veux dire que ca :

fichier h:
int une_variable;
void une_fonction();

fichier c:
#include "fichier.h"

void une_fonction()
{
une_variable++;
}

Ca fonctionne nickel chez moi...

[Dr.Vince]

bien sur que ça fonctionne Yodajr

c'est juste que quand plusieurs fichiers importent le même ça part en cacahuète !!

[Yodajr]

c'est juste que quand plusieurs fichiers importent le même ça part en cacahuète !!
C'est à dire ?
J'ai un header.h qui contient toutes mes variables et il est appelé dans chacun de mes fichiers C
C'est bien de ca dont tu me parles ?

[Nesgba]

moi je procede de la sorte (c'est a moitié de tete y'a peut etre des erreurs :hum: )
y'a des trucs peu catholique vous croyez ? :ph34r:

commun.h

#ifndef _COMMUN_
#define _COMMUN_

#ifdef __cplusplus
extern "C" {
#endif

/////////////////// variables/pointeurs/defines //////////////////////

/////////////////// Prototypes //////////////////////
int initgame(void);

/////////////////// fichiers standart //////////////////////
#include <conio.h>
#include <mem.h>
#include <math.h>
#include <stdlib.h>
#include <stdio.h>
#include <limits.h>
...

/////////////////// fichiers projet //////////////////////
#include "sprites.h"

#ifdef __cplusplus
}
#endif

#endif // _COMMUN_




sprites.h

#ifndef _SPRITES_
#define _SPRITES_

#ifdef __cplusplus
extern "C" {
#endif

/////////////////// variables/pointeurs/defines //////////////////////
unsigned char nb_sprites = 10 ;

/////////////////// Prototypes //////////////////////
void initsprites();

#ifdef __cplusplus
}
#endif

#endif // _SPRITES_





main.c

#include "commun.h"

int main(void)
{
nb_sprites = 10 ;
initgame() ;
initsprites() ;

return 0 ;
}


commun.c

#include "commun.h"

int initgame(void)
{
return 1 ;
}


sprites.c

#include "commun.h"

unsigned char nb_sprites ;

void initsprites(void)
{
}

[Gwoin]

C'est à dire ?
J'ai un header.h qui contient toutes mes variables et il est appelé dans chacun de mes fichiers C
C'est bien de ca dont tu me parles ?

Je pense que c'est bien de ça qu'il parle.
Une même variable ne doit être définit qu'une seule fois.

hors, lors de la complitation, un #include recopie le fichier appelé là où il est appelé.
En gros, si un meme fichier .h est inclus dans différent fichiers .c, alors les variables contenus dans ce .h seront definient autant de fois.

Toute fois tu ne peux ne pas rencontrer le probleme si tes fichiers c n'ont aucun liens entre eux, ce qui est assez rare dans un programme ^^

[edit : j'avais pas vu que NesGBA postait en meme temps que moi ^^ ]

[Yodajr]

Toute fois tu ne peux ne pas rencontrer le probleme si tes fichiers c n'ont aucun liens entre eux, ce qui est assez rare dans un programme ^^
Ben voila, tout le monde semble s'accorder sur ce point, pourtant je n'ai aucun soucis avec mes projets...
M'enfin je verrai bien avec le temps, ca va ptetre merder.

[Dr.Vince]

c'est en fait pour éviter les include cyclique.

exemple :

F1 inclu F2
F2 inclu F1

et bah t'arriveras pas à compiler ça si tu rajoute pas les #ifndef

[Portnaouak]

j'ai mis les sources en fichier a la fin de mon post il me semble.
Sinon, j'ai mis les define, et ca ne semble pas venir d'une inclusion répétée...c'est assez ennuyeux comme probléme.

[thoduv]

Lis mieux mon post , je pense que ta solution s'y trouve :)
Pour déclarer une vaiable dans un fichier H, il faut la déclarer externe, puis l'initialiser dans un fichier compilé C.

[Dr.Vince]

Essaies ça et ça devrait fonctionner :

- les #include c'est sur les fichiers .h et pas .c
- les #ifndef c'est dans les fichiers .h qu'il faut les mettre !

[Gwoin]

- les #include c'est sur les fichiers .h et pas .c
- les #ifndef c'est dans les fichiers .h qu'il faut les mettre !

hmm, pas vaiment d'accord.
il vaux mieux mettre les #include un maximum dans les fichiers c et non les headers (dans les headers seulement quand il y en a besoin pour compiler).
je m'explique.
Imagine que dans A.h tu aies:
#include "B.h"
#include "C.h"


et que tu aies un autre fichier D.h qui contient:
#include "A.h"

et bien il incluera aussi B.h et C.h par la meme occasion alors que ce n'est peut etre pas necessaire.

Ensuite tu peux tres bien faire un truc du genre:

(dans A.c) #include "B.h"
(et dans B.c) #include "A.h"

C'est tout à fait valable (et bien pratique des fois quand des tructures ou classes se croisent).

Et enfin, les #ifndef doivent etre utilisé dans ce qui peut etre inclus (les fichiers .c peuvent etre inclus, donc on peut mettre des #ifndef, c'est meme obligatoire quand un fichier .cpp fait appel à un fichier .c)

Mais ceci dit, en C, et dans de petits programmes, on peux simplifier en ecrivant un maximum de choses dans le même fichier :p

[Dr.Vince]

je me suis mal exprimé, ce que je voualis dire c'est qu'il vaut mieux inclure les fichier H que les fichiers C

[thoduv]

Ouais parce que les histoires de collisions d'headers c'est vraiment galère, du style des strucures qui se pointent mutuellement etc ... :hum:

[Gwoin]

je me suis mal exprimé, ce que je voulais dire c'est qu'il vaut mieux inclure les fichier H que les fichiers C

Tout à fait d'accord :)

Ouais parce que les histoires de collisions d'headers c'est vraiment galère, du style des structures qui se pointent mutuellement etc ... :hum:
D'où l'interet d'inclure les headers dans le fichier .C
Comme ça pas de risque que 2 headers s'appellent mutuellement. Parce que des structures qui se pointent mutuellement ca m'est déjà arrivé un certain nombre de fois, et pas moyen de faire autrement...

[Portnaouak]

Ouf, je viens tout juste de réussir a régler ce probléme. Je ne sais pas pourquoi , mais juste en changeant l'ordre de certains headers et en ajoutant un .h, tout est parti. Alors que lorsque j'avais fait ça plus tot ca n'avait pas marché. Vraiment bizarre.