Discussion :

[Mike888]

Bon, une fois n'est pas coutume, j'ai besoin de vos lumières...

J'ai fini le code d'un programme (jeu des tours de Hanoï). C'est donc un fichier au format .cpp

Dans ce fichier, je fais appel (via un #include) à un fichier .h (qui contient des fonctions auxquelles le programme principal fait appel; c'est en fait, un fichier pour l'usage des piles).
Seulement, on m'a conseillé de scinder ce fichier .h en 2 parties:
- la partie qui contient les prototypes de fonctions reste le fichier .h
- la seconde partie qui contient le corps des fonctions devrait être compilée de manière à devenir une librairie.

* Comment est-ce que je dois faire cela ?
* Au final, quand j'aurai mes 3 fichiers, peuvent-ils se trouver dans le même répertore (ou dois-je placer le .h dans le répertoire Include) ?
* Dans mon programme principal, je présume que je laisse mon appel au fichier .h ?


Si vous pouviez m'en dire davantage, ce serait hyper-sympa, parce que je nage et je rame ...

[PINGOUIN_GEANT]

.cpp c'est pour le C++
compiles-tu déjà de la façon suivante ?

Code :

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

1
2
3
gcc hanoi.c -c
gcc main.c -c
gcc main.o hanoi.o -o main

[Mike888]

En fait, j'emploie la version "windowsée" du Borland C 3.1.

[PINGOUIN_GEANT]

question + générique: as-tu des notions de compilation séparée, modularité...
parce que je suis étonné de lire que tout est dans un header:
pour plus d'infos: http://c.developpez.com/tutcpp/c2450.php
(c et c++ pareils à ce niveau)

[Meyn]

pour creer une librairie c est
ar cr nomdelalib.a fichier.o
ranlib nomdelalib.a
pour la statique

et
gcc -c -shared nomdelalib.so fichier .o
pour la dynamique

[Emmanuel Delahaye]

Bon, une fois n'est pas coutume, j'ai besoin de vos lumières...

J'ai fini le code d'un programme (jeu des tours de Hanoï). C'est donc un fichier au format .cpp

C'est donc un programme C++. Les fichier sources de programmes C doivent avoir l'extension .c

Dans ce fichier, je fais appel (via un #include) à un fichier .h (qui contient des fonctions auxquelles le programme principal fait appel; c'est en fait, un fichier pour l'usage des piles).

Mauvais plan. Les fichiers .h ne doivent contenir que les déclarations des fonctions (entre autre). Pas de définition de fonctions, ni de variables.

Un peu de lecture:

http://emmanuel-delahaye.developpez.com/codage.htm

Seulement, on m'a conseillé de scinder ce fichier .h en 2 parties:
- la partie qui contient les prototypes de fonctions reste le fichier .h

Oui.

- la seconde partie qui contient le corps des fonctions devrait être compilée de manière à devenir une librairie.

Pas forcément une bibliothèque (librairie est un anglicisme : library). Tu peux dans un premier temps regrouper les fonctions dans un .c (ou .cpp selon le langage). Tout est expliqué dans le lien que j'ai indiqué au-dessus.

* Comment est-ce que je dois faire cela ?
* Au final, quand j'aurai mes 3 fichiers, peuvent-ils se trouver dans le même répertore (ou dois-je placer le .h dans le répertoire Include) ?

Non. Je recommande une organisation des fichiers comme ceci

Code :

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

1
2
3
4
 
projet/src -> fichier sources (.c, .cpp)
projet/inc -> fichier d'entêtes (.h)
projet/out -> fichiers de sorties (objets, executables, mapping etc.)

en principe, ton environnement de développement permet ça.

Pour les fichier d'entête, je recommande d'indiquer la racine projet : .../projet et de mettre le chemin à partir de cette racine:

#include "inc/myheader.h"

Pour les gros projets, un découpage en blocs fonctionnels (BF) est souhaitable :

.../projet/xxx
.../projet/yyy
.../projet/zzz

chaque BF ayant sa structure inc, src, out.

le chemin des headers devient alors

Code :

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

1
2
3
 
#include "inc/xxx/myheader.h"
#include "inc/yyy/myheader.h"

Les même noms peuvent être utilisés (on a que 8 lettres) et le chemin lève l'ambigüité.

* Dans mon programme principal, je présume que je laisse mon appel au fichier .h ?

Le header doit être inclus dans le fichier de définition des fonctions (pour garantir la cohérence), ainsi que dans chaque header ou fichier source qui en a besoin. (Bien lire l'article sur la protection des headers contre les inclusions multiples).