Discussion :

[andrebernard]

Bonjour

C'est la premiere journ�e que je fais du C++ et je suis tres content
Je commence � comprendre quelques bribes de ce language tres compliqu� comparativement au VB.

J'aurais aim� savoir si il est possible d'exporter des fonctions dans VC++ 6 dans un fichier autre que le principal.
Un peu comme les modules en VB qui permettent d'avoir acces aux fonctions de n'importe quelle form.
Tout ceci pour pouvoir classer mes fonctions afin qu'elle ne soit pas toutes dans la meme page, pour faciliter la lecture

J'ai essay� en cr�ant un fichier avec un nom "Fonctions.cc" et en ajoutant un include au debut de la main.
Je l'ai mis dans le repertoire "source files"

1/ Ai-je mis la bonne extension ??
2/ Est-ce le bon repertoire ???

Je vous remercie beaucoup de votre aide precieuse
Bonne journ�e

[loicounet]

En gros tu veux savoir s'il est possible d'utiliser diff�rents fichiers comme des boites � outils?

tu peux avoir:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
 
//main file
 
#include fichierA.hpp
 
main()
{
//traitement
}

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
//fichierA.cpp source
 
#include fichierB.hpp
 
fichierA::ma_fonction()
{}

tu peux donc importer des fichiers dans d'autre fichiers que le principal(main)
c'est ce que tu voulais savoir? (je connais pas VB )

[andrebernard]

Oui c'est un peux �a.

Je voudrais cr�er une fonction, mais pas la mettre dans le fichier ou est la procedure "WinMain"
Et je voudrais que cette fontion soit accessible de toutes les autres procedures.

Ce que je ne sais pas, c'est :

1/ Ou dois je d�clarer ma procedure externe ?
2/ Quelle extension dois-je donner � mes fichier externes contenant mes procedures ?
3/ Ou dois-je mettre ce fichier, est ce dans le repertoire source files, Ressource, ou external dependancie ?

Exemple :

Fichier main :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
#include <windows.h>
HWND WindowHandle; /* Handle de la fenêtre que l'on va créée */
 
void MessagePerso(HWND hwnd);
 
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE PrevInstance, LPSTR CmdLine, int CmdShow)
{
MessagePerso(hwnd); // Appel de ma fonction perso dans un autre fichier
}
 
// Inclusion de mon fichier externe
#include "FonctionPerso.cc"

Fichier FonctionPerso :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
 
void MessagePerso(HWND hwnd)
{
MessageBox(hwnd, "Je suis un msgBox dans un fichier externe", "Infos", MB_OK|MB_ICONINFORMATION);
}

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
Et pour les repertoires : 
 
Source Files
             main.cpp
             FonctionsPerso.cc
Header Files
Ressource Files
External Dependancie

Voila, est ce correct ??
Parce que je vois que toi tu as mis l'extension "hpp"

[loicounet]

tu peux faire un truc du genre:

un fichier avec tes fonctions

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
//FonctionPerso.hpp
class FonctionPerso{
public:
  static void MessagePerso(HWND hwnd)  //le static te permet d'utiliser la fonction sans instancier d'objet...normal c'est une boite a outil
  {
      MessageBox(hwnd, "Je suis un msgBox dans un fichier externe", "Infos",MB_OK|MB_ICONINFORMATION);
   }
 
};

et dans le main(pour info, tu ne peux inclure que des fichiers H ou HPP pas de CC/C/CPP

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
#include <windows.h>
#include "FonctionPerso.hpp"
HWND WindowHandle; /* Handle de la fenêtre que l'on va créée */ 
 
 
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE PrevInstance, LPSTR CmdLine, int CmdShow)
{
FonctionPerso::MessagePerso(hwnd); // Appel de ma fonction perso dans un autre fichier
}

[andrebernard]

Merci beaucoup LOICOUNET

Eh ben dis donc, c'est pas simple

Et pourquoi tu met CLASS dans "class FonctionPerso{" pourquoi tu met pas les fonctions directement dans le fichier ???

Une autre question, donc on ne peux pas mettre autre chose que H ou Hpp.
Ce qui est fou, c'est que �a marche avec "cc", mais si tu le dit je te crois

Donc je cr�� un fichier Hpp et dans quel repertoire je le cr��, tu me l'a pas dit, dans le "Source Files" ou le "Header Files" parce que H c'est pas pour les Headers ?

[loicounet]

Ben la je te r�ponds sans tester ce que je dis:

tu peux tenter peut �tre sans d�clarer de class, je mets class afin d'encapsuler les fonction==>si tu en as 36000 ca te permets de savoir d'o� elle vient.

Si tu veux tu peux tenter sans class(mais je sais pas si ca marche direct)

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
//fichier FonctionPerso.hpp
 
 
void MessagePerso(HWND hwnd)  //le static te permet d'utiliser la fonction sans instancier d'objet...normal c'est une boite a outil
  {
      MessageBox(hwnd, "Je suis un msgBox dans un fichier externe", "Infos",MB_OK|MB_ICONINFORMATION);
   }

et dans le main:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
#include <windows.h>
#include "FonctionPerso.hpp"
HWND WindowHandle; /* Handle de la fenêtre que l'on va créée */ 
 
 
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE PrevInstance, LPSTR CmdLine, int CmdShow)
{
MessagePerso(hwnd); // Appel de ma fonction perso dans un autre fichier
}

peut etre que ca marche aussi...

Le H dans le header.

En fait, dans le H tu d�clare tes fonction et dans le C tu d�fini les fonction...c'est d'usage commun.
Mais si tu veux, tu peux d�clarer et d�finir dans le H (par exemple pour l'utilisation de tempate t'es oblig� de le faire)

[koala01]

Salut,

En C et en C++, l'�quivalent aux modules du VB est l'"unit� de compilation" (compile unit).

Une unit� de compilation est compos�e de deux types de fichiers distincts:

• Les fichiers d'en-t�te (header), dont l'extension est g�n�ralement .h ou .hpp qui contient tout ce dont le compilateur doit connaitre l'existence
• Les fichiers d'impl�mentation, dont l'extension est g�n�ralement .c (pour le C) ou .cpp (pour le C++) qui contient ce que le compilateur doit en faire.

Il faut en effet bien �tre conscient de la mani�re de fonctionner du compilateur:

Le compilateur travaille par unit� de compilation, mais oublie, lorsqu'il commence � compiler une nouvelle unit�, tout ce qu'il a fait ou rencontr� lors de la compilation des unit�s pr�c�dentes.

En plus, il lit le code exactement � la mani�re que tu as de lire un livre, de haut en bas, du d�but � la fin.

Et tout comme toi, qui ne sais - a priori - pas ce qui se passe en page 11 quand tu n'en est qu'� la page 10, le compilateur n'a aucune id�e de ce qui se trouve � la ligne 15 au moment o� il traite la ligne 14.

C'est la raison pour laquelle, le compilateur se plaindra que "erreur : "fonction" n'est pas d�clar�e dans la port�e" avec le code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
#include <iostream>
int main()
{
    fonction();
    return 0;
}
void fonction()
{
    std::cout<<"je suis dans la fonction"<<std::endl;
}

alors qu'il acceptera sans aucun probl�me le code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
#include <iostream>
void fonction()
{
    std::cout<<"je suis dans la fonction"<<std::endl;
}
int main()
{
    fonction();
    return 0;
}

ou, qu'il acceptera le code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
#include <iostream>
void fonction();
int main()
{
    fonction();
    return 0;
}
void fonction()
{
    std::cout<<"je suis dans la fonction"<<std::endl;
}

parce que, ayant d�j� rencontr� la d�claration de la fonction sous la forme void fonction();, il "sait qu'elle existe"... m�me s'il ne sait pas lors de l'appel ce qu'elle fait (et qu'il s'en fout royalement d'ailleurs).

Les choses se font souvent en "deux temps":

• la d�claration de "quelque chose", lors de laquelle on se "contente" de dire que quelque chose existe, et
• la d�finition, qui nous permet de "donner un corps" � ce quelque chose, pour lui donner une existence "r�elle".

Si une d�finition peut servir de d�claration (et sert souvent: � chaque fois que tu �cris int i; tu dis au compilateur que i existe, et tu lui donne le "corps d'un entier"), l'inverse n'est par contre pas le cas.

Quand on travaille avec plusieurs "modules" diff�rents (ou, pour utiliser le bon terme, avec plusieurs unit�s de compilation diff�rentes), il arrive tr�s souvent qu'une unit� de compilation ait besoin d'utiliser tout ou partie de ce qui se trouve dans une autre.

Et c'est l� qu'intervient la s�paration entre les fichiers d'en-t�te et les fichiers d'impl�mentation.

Chaque fois que l'on va cr�er "quelque chose" dans une unit� de compilation qui doit �tre connu "de l'ext�rieur" de cette unit� de compilation, on va simplement en rajouter le moyen de savoir que ce "quelque chose" existe dans le fichier d'en-t�te correspondant.

Chaque fois qu'une unit� de compilation aura besoin de disposer du contenu d'une autre, il nous "suffira", � l'aide de la directive pr�processeur #include, de rajouter l'en-t�te de l'unit� de compilation qui est n�cessaire.

La particularit� que l'on rencontre est au niveau des classes et des structures:

on peut - parfois - se contenter que le compilateur sache que la classe ou que la structure existe, mais ne sache absolument pas ce qu'elle contient.

On peut alors temporairement se contenter de ce que l'on appelle la d�claration anticip�e, mais, le plus souvent, les unit�s de compilation qui utilisent des classes et des structures venues d'autres unit�s de compilation auront besoin de savoir de quoi elles sont compos�es (d'en connaitre le corps).

C'est la raison pour laquelle la d�finition d'une classe ou d'une structure (qui n'est en d�finitive qu'un groupe de d�clarations de variables et de fonctions membres) prend "naturellement" place dans les fichiers d'en-t�te (sauf cas particuliers dans lesquels une structure ou une fonction ne devrait pouvoir �tre utilis�e que dans une unit� de compilation bien particuli�re et n'a absolument pas besoin d'�tre connue du "reste du projet").

Ainsi, et bien qu'il manque encore le concept de "guard dogs" (cf la FAQ) si tu as deux fonctions dans une unit� de compilation dont une seule doit �tre connue dans tout le projet, tu pourrais tr�s bien avoir
un fichier d'en-t�te (unit.h) contenant la d�claration de la fonction connue sous la forme de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

void fonctionConnue();

un fichier d'impl�mentation (unit.cpp) compos� des d�finitions des deux fonctions sous la forme de

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
#include "unit.h"
/* comme fonctionConnue fait appel à fonctionInconnue, il faut que le 
 * compilateur sache que fonctionInconnue existe 
 */
void fonctionInconnue();
void fonctionConnue()
{
    /* tout ce qui doit être fait avant */
    fonctionInconnue();
    /* tout ce qui doit être fait après */
}
void fonctionInconnue()
{
    /* tout ce que doit faire la fonction */
}

et on peut envisager d'utiliser cette unit� de compilation ailleurs (par exemple main.cpp) gr�ce � un code proche de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
#include "unit.h" /* permet de connaitre le contenu de unit.h dans ce fichier
                        * ci */
int main()
{
    fonctionConnue();//OK le compilateur connait la fonction
    /* par contre l'appel à
    fonctionInconnue(); 
    * n'est pas autorisé : le compilateur ne connait pas la fonction
    */
}

Pour terminer cette (d�j� fort longue) intervention, il faut savoir que la directive #include est r�cursive.

En effet, si tu inclus un fichier fichier1.h dans fichier2.h, fichier2.h dans fichier3.h, fichier3.h dans fichier4.h (et on pourrait continuer longtemps ainsi) ca revient exactement "comme si" tu avait fait un copier/coller du contenu de fichier1.h dans fichier2.h, puis de fichier2.h (avec le contenu de fichier1.h) dans fichier3.h, et de fichier3.h (avec le contenu "modifi�" de fichier2.h) dans fichier4.h.

Et donc, en incluant fichier4.h dans fichier4.cpp, le compilateur "connait" (et dont t'autorise � utiliser) tout ce qui se trouve dans fichier1.h, fichier2.h, fichier3.h et fichier4.h.

[andrebernard]

Merci mille fois de votre precieuse aide

Et merci beaucoup KOALA01 de ton explication d�taill�e
Bien le coup de la r�cursivit� des include

Donc en r�sum�, parce que je comprend vite, mais faut m'expliquer longtemps
Faut dire aussi que 20 ans de basic "�a esquinte"

Je peux creer mes fonctions dans un autre fichier, je lui met l'extension h et dans le r�pertoire HEADER.

Ce qui est rigolo, c'est qu'entretemps, j'ai cr�� un nouveau repertoire pour faire un essai, en plus des 4 originaux que j'ai appell� "Fonctions" et j'ai mis mon fichier "FonctionsPerso.h" dedans, et �a marche pareil

Donc apparement le repertoire ou est situ� le fichier, n'a pas une tres grande importance, qu'en pensez vous ??