Ou apprendre le C++??
sur quelle site??
Merci

http://casteyde.christian.free.fr/online/cours_cpp/book1.html

Ou un bon bouquin!! Rien de tel qu´un livre à potasser à tête reposée!
Perso, j´ai appris le C sur bouquin, c´est parfait.

bye
http://rom3fr.free.fr

pixcoder > Pour ton projet de jeu, tu utilises 1 seul fichier C et tu mets tout les reste dans des headers ? C´est pas franchement recommandé et c´est pour ca que les .c existent aussi.
L´idéal c´est un fichier source et le header correspondant...

Oui OxFFFF. Mais pour l´instant, je n´ai pas commencé à coder le jeu même, seuls les fichiers du moteur sont des headers. Les fichiers du code du jeu lui-même seront des .c
Et puis, je préfère centraliser mes fonctions.
Je trouve que la technique du fichier source et du header correspondant entraine un manque de clarté, on pourrait très bien appeler le même header pour plusieurs fichier .c et on ne va quand même pas pour autant appeler plusieurs fois ce header!

http://rom3fr.free.fr

Oui mais ne serais ce que pour le temps de compilation, l´emploi de headers est désatreux vu qu´aucun fichier objet n´est génré pour ce type de fichier : la moindre modification d´une fonction d´un header entrainera la nécessité de recompiler l´ensemble des modules .c employant ces fonctions, tandis que si tu employais des fichiers source, une modification interne d´une des fonctions du moteur ne nécessiterait que la recompilation du seul fichier source incriminé. Alors c´est vrai qu´au début d´un projet, les temps de compilation paraissent ridicules, mais ca augmente très vite. Et il y a d´autres raisons (accessibilité de certaines fonctions du moteur par l´ensemble du programme etc...).

Que ce passe-il en outre si tu souhaite quelques années plus tard, autoriser la création de mods sans pour autant libérer le source du renderer ? (c´est à titre d´exemple). Impossible, ou alors fractionner le programme, utiliser des dll etc... tandis qu´avec des .h/.c : il suffit de ne fournir que les modules objet (regroupés en libs par exemple) et les header : les headers, parce qu´il sont clairs et consics, permettent de voir tout de suite le rôle des fonctions etc... tout en masquant l´implémentation contenue dans les fichiers .obj.

Ce n´est pas un hasard si tous les projets professionnels et même amateurs emploient cette règle du couple .h/.c

"on pourrait très bien appeler le même header pour plusieurs fichier .c et on ne va quand même pas pour autant appeler plusieurs fois ce header!"

C´est quand même l´objectif de la chose : lier les fichiers source entre eux.

D´un point de vue conception c´est vraiment pas conseillé : le projet débute, il est donc facile d´y remédier.

J´ai pas regardé le programme en question mais tu veux dire que tu as mis du code dans un .h ?

Si c´est ça, à moins de savoir très très exactement ce que tu fait, ce n´est pas bon du tout. Car ça veut dire que les fonctions du fichier ne pourront être utilisé que dans un seul fichier .c car si tu inclue cet header dans plusieurs fichier .c (ou .cpp) alors tu auras une erreur au linkage immanquablement.
Je ne comprend pas ce que tu raconte dans ton dernier paragraphe, par appeler un header ton veux dire l´inclure dans un fichier .c ? si oui, il n´y a aucun problème normallement à inclure un .h dans plusieurs .c, c´est même prévue pour.

dnob700 : tu me dis "si tu inclue cet header dans plusieurs fichier .c (ou .cpp) alors tu auras une erreur au linkage immanquablement" et "il n´y a aucun problème normallement à inclure un .h dans plusieurs .c, c´est même prévue pour", contradiction?? J´ai surement mal compris.

Oui, j´ai compris ta recommendation OxFFFF.

En fait, l´intérêt de cette hiérarchie de fichiers est de centraliser mes données; mon objectif était de n´inclure qu´une fois pour toute les fonctions graphiques (réunies dans ces headers) dans le fichier principal.
Ceci entraine en effet que s´il y a modification d´une des fonctions des headers, il faut tout recompiler. N´est pas grave si mon projet reste court.

Vous me conseillez peut-être d´en faire des fichiers .c? et de ne réserver les headers .h que pour des définitions ou des déclarations de fonctions utiles au .c correspondant?

Il n´y a pas contradiction dans el premier cas c´est si tu as du code dans les header et dans le second cas c´est le cas normal ou tu n´inclue des header qui ne contiennent que des déclarationou au pire des fonctions inline.

d´accord dnob700, j´ai compris. je ne comprenais pas ce que tu voulais dire par "code". En fait, ce que tu nommes "code", ce sont des fonctions?

tout à fait, par opposition à de simples déclarations de fonctions.

Au début je voulais aussi faire ça, et c´est vrai que ça marche bien, mais dès que ton projet dépasse le stade initial sa devient invivable à cause des inclusions etc.

aahh! J´ai plein d´erreur partout!
En fait, j´ai changé en .c tous mes fichiers anciennement en .h et et j´ai crée d´autres fichiers .h cette fois-ci avec les même noms et dans lesquels je déclare les fonctions crées dans les fichiers .c associés, mais la compilation me donne plein d´erreurs!

quel genre d´erreur ?

globalement que fe-t-il que tu es ?

Pas de variable globale au programme. Tu ne dois déclarer des variables que dans les fonctions, ou au pire au début d´un fichier .c si cette variables doit forcement être vu par plusieurs fonctions du fichier.
Normallement le svariables ne devrait pas être globale à tout ton projet. Si c´est obligatoire tu déclare en plus la variable dans le fichier .h qui porte le même nom que le fichier .c où la variable est déclaré, mais dans le fichier .h tu mets le mots clef "extern" avant la déclaration de la variable. Par exemple:
extern int age;

Ensuite les fichier .c ne doivent contenir que des fonctions donc et les fichiers .h doivent contenir les prototype des fonctions qui se trouve dans le fichier .c du même nom.

Enfin tu doit inclre dans chaque .c tout les fichier .h qui déclare des fonction qui sont utilisé dans le .c en question.

Si tu fait tout ça, théoriquement tu n´a pas d´erreur de linkage.

Vérifie et sinon donne nous tes erreurs.

oki. J´ai tout refait.
En fait, j´ai des petits soucis à la compilation surement parce que je ne comprends pas exactement ce qu´il fait quand il compile.
En fait, je suis sous DevC++. J´ouvre un "projet" (.dev) pour coder AloE. Et, à ce projet, je peux associer plusieurs fichiers : des .h ou des .c. Puis, DevC++ me propose de compiler le projet, donc de compiler "tous ces fichiers", mais compile-t-il chaque fichier, ou cherche-t-il uniquement le .c où la fonction "main" est contenue?
Bref, je crois que DevC++ mélange la compilation et le linkage...
J´ai en fait l´impression que la notion de "projet" (associée au type de fichier .dev) n´est pas très claire avec DevC++, d´autant plus que j´en ai besoin pour "linker" des fichier .a nécessaires au fonctionnement de OpenGL.
(d´ailleurs, autre question, que sont réellement ces .a (ce sont des fichiers compilés?) et comment le compilo les utilise-t-il?)
En tout cas, mon objectif est d´inclure les .c dans un fichier principal où sera la fonction "main" pour obtenir un fichier .exe.

Merci pour les conseils précédents.

++
PiX

En fait, j´aurais une autre question :

mes fichiers .c utilisent des structures définies dans un autre fichier (structures_m.h), et quand j´inclus ce header dans plusieurs .c, le compilateur me dit, lors de la compilation, qu´il y a redéfinition de structures, ce qui est une erreur.
Donc j´enlève structures_m.h des fichiers .c, mais le problème, c´est que quand je veux compiler mes .c séparément, on peut pas, parce que les structures utilisées ne sont pas connues!

L´idée serait bien sûr de les "déclarer" comme des variables (en extern) ou des fonctions à l´intérieur du fichier .h de même nom que le fichier .c, mais ca n´existe pas! si?

non, ce qu´il faut, c´est mettre, dans les .h :

1. ifndef _TONFICHIER_H
2. define _TONFICHIER_H

// tout le reste du .h

1. endif