Equivalent module en VB

Bonjour

C'est la premiere journée que je fais du C++ et je suis tres content :D
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

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

tu peux avoir:

Code:

---

1 2 3 4 5 6 7 8 9

//main file   #include fichierA.hpp   main() { //traitement }

---

Code:

---

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 :mrgreen:)

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:

---

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:

---

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:

---

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" 8O

tu peux faire un truc du genre:

un fichier avec tes fonctions

Code:

---

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:

---

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 }

---

Merci beaucoup LOICOUNET 8-)

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 ?

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:

---

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:

---

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)

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:

---

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:

---

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:

---

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:

---

void fonctionConnue();

---

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

Code:

---

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:

---

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.

Merci mille fois de votre precieuse aide :D

Et merci beaucoup KOALA01 de ton explication détaillée 8-)
Bien le coup de la récursivité des include 8-)

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

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 :D

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

Le dossier dans lequel se trouve le fichier d'en-tête n'a pas énormément d'importance pour autant que le compilateur sache qu'il doit aller voir dedans s'il le trouve.

Certains dossiers sont configurés d'office, et entre autre <dossier du compilateur >/include.

Ceci dit, il faut se mettre d'accord sur la signification à donner au terme "créer" utilisé dans ta question.

S'il s'agit de la déclarer (dire qu'elle existe), oui, nous sommes bien d'accord, tu donne l'extension .h au fichier et tu le met dans le dossier HEADER (ou du moins dans le dossier déclaré comme contenant les en-tête).

S'il s'agit de la définir (indiquer ce qu'elle doit faire), alors, non, tu dois donner l'extension .cpp à ton fichier et le mettre dans le dossier Sources (dans le dossier dans lequel se retrouvent tous les fichiers .cpp)

D'accors KOALA, cette fois c'est claire net et précis.

Les nom de dossiers n'ont pas vraiment d'importance
Quand au fichier .h il servent à déclarer
Et les .CPP à mettre la fonction dedans.

Je te remercie beaucoup de ton aide et de tes explications précises, car tu sais quand on commence le moindre petit détail a son importance pour pas démarrer mal et foirer tous le reste par la suite.

Encore merci pour tout 8-)

Et sinon, si tu veux regrouper tes classes & fonctions dans des "modules", renseigne-toi sur le mot clé namespace (recherche dans la FAQ C++ et sur le forum, ça devrait aller)

Citation:

---

Envoyé par Alp

Et sinon, si tu veux regrouper tes classes & fonctions dans des "modules", renseigne-toi sur le mot clé namespace (recherche dans la FAQ C++ et sur le forum, ça devrait aller)

---

Non, très cher...

A moins que je ne me trompe tout à fait au sens donné au terme "module" en VB, il s'agit ni plus ni moins que de l'équivalent d'unité de compilation.

Ainsi, un module VB peut contenir plusieurs classes et un namespace (car cela existe aussi en VB) peut contenir les classes définies dans plusieurs modules.

La seule différence (et encore, il faudrait que je vérifie ce point) résiderait dans le fait qu'il est impossible de déclarer deux classes appartenant à des espaces de noms différents en VB alors que c'est admis (même si c'est rarement fait en réalité) en C++ ;)

Ainsi, il faudrait sans doute partager cette unité de compilation en deux pour l'adapter en VB car elle est malgré tout valide en C++ ;):
fichier d'en-tete:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

namespace Application { namespace Core { class UneClasseDuCoeur { /* tout ce qu'il faut */ }; } //namespace Core namespace Persistance { class UneClasseDeGestionDePersistance { /* tout ce qu'il faut */ } } //namespace Persistance }//namespace Aplication

---

fichier d'implémentation

Code:

---

1 2 3 4 5 6 7 8 9 10 11

namespace Application { namespace Core { /* définitions des méthodes de UneClasseDuCoeur */ } //namespace Core namespace Persistance { /* définitions des méthodes de UneClasseDeGestionDePersistance */ } //namespace Persistance }//namespace Aplication

---

Au temps pour moi, mais je voulais juste signaler l'existence des namespaces en C++ ;)

koala01 j'ai pas tout lu mais tu complexifies la chose avec les namespaces..:D
Basiquement le distinguo est fait en VB6 entre modules et forms parce qu'un module est plus générique et fourre-tout alors qu'une formsdans l'esprit RAD de VB c'est une entité GUI visuelle...
c'est la même chose avec Delphi il me semble entre les .DCU et les fichiers .pas.


En C++ par exemple avec MFC une form =classe .cpp de même qu'une classe .cpp peut-être générique et regrouper n'importe quoi...

Citation:

---

Basiquement le distinguo est fait en VB6 entre modules et forms parce qu'un module est plus générique et fourre-tout alors qu'une formsdans l'esprit RAD de VB c'est une entité GUI visuelle...

---

Oui c'est exactement ça ...

Le module en VB, n'est pas visuel, on ne peux y mettre que des fonctions et des sub, et il est comme VC++ on n'as pas le droit d'ecrire en dehors d'une sub ou d'une fonction.
L'avantage, c'est que tu créé autant de module que tu veux, tu leur donne le nom que tu veux (pas deux fois le meme evidemment), et donc tu peux par exemple creer un module "Cryptage" et mettre dedans une dizaine d'algo qui seront appellé dans tes FORMS ou meme par un autre module.
C'est tres utile pour classer tes fonctions, et aussi quand apres dans un autre code tu as besoin du meme cryptage, et bah , hop tu exporte le module et le reimporte dans un autre projet :D
Y'a aussi une chose importante, c'est que VB commence a executer tous les modules avant les FORMS.
Et aussi que tous ce qui est déclaré public dans un module est dispo dans tout le programme.

Voila pour les modules "standards", Y'a aussi les modules de classes, mais la j'ai pas trop compris, je crois que c'est pareil qu'un module traditionnel mais plus voué a etre exporté.
Faut dire que cette histoire de CLASSE j'ai encore rien compris, au bout de 20 ans de prog :oops:

Donc ce que je voulais savoir c'etait si je pouvais organiser mes fonctions en VC++ comme en VB.
Creer un repertoire nommé "Cryptage" mettre dedans autant de fichiers .cpp que je veux avec les fonctions dedans etc ....

Mais apparement ça ne fonctionne pas vraiment pareil en VC++ car j'ai l'impression qu'il est plus procedural que VB.
Comme je l'ai dit l'avantage des modules en VB, c'est qu'il sont lu avant les FORMS, donc des que tu as ta premiere FORM, VB connait et a déclaré toutes les fonctions de tous les modules, ce qui veux dire qu'a la premiere form tu as disponibles n'importe quelle fonction des modules.
J'ai l'impression qu'en VC++ il faut inclure tous les fichiers les un derriere les autres, cela ne se fait pas automatiquement :roll: