IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Equivalent module en VB


Sujet :

C++

  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 309
    Par défaut Equivalent module en VB
    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

  2. #2
    Membre éprouvé
    Inscrit en
    Avril 2008
    Messages
    155
    Détails du profil
    Informations forums :
    Inscription : Avril 2008
    Messages : 155
    Par défaut
    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 )

  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 309
    Par défaut
    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"

  4. #4
    Membre éprouvé
    Inscrit en
    Avril 2008
    Messages
    155
    Détails du profil
    Informations forums :
    Inscription : Avril 2008
    Messages : 155
    Par défaut
    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
    }

  5. #5
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 309
    Par défaut
    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 ?

  6. #6
    Membre éprouvé
    Inscrit en
    Avril 2008
    Messages
    155
    Détails du profil
    Informations forums :
    Inscription : Avril 2008
    Messages : 155
    Par défaut
    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)

  7. #7
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 635
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 635
    Par défaut
    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
    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.
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #8
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 309
    Par défaut
    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 ??

  9. #9
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 635
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 635
    Par défaut
    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)
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  10. #10
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 309
    Par défaut
    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

  11. #11
    Alp
    Alp est déconnecté
    Expert confirmé

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Juin 2005
    Messages : 8 575
    Par défaut
    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)

  12. #12
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 635
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 635
    Par défaut
    Citation Envoyé par Alp Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  13. #13
    Alp
    Alp est déconnecté
    Expert confirmé

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Juin 2005
    Messages : 8 575
    Par défaut
    Au temps pour moi, mais je voulais juste signaler l'existence des namespaces en C++

  14. #14
    Expert confirmé
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 526
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 526
    Par défaut
    koala01 j'ai pas tout lu mais tu complexifies la chose avec les namespaces..
    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...

  15. #15
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 309
    Par défaut
    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
    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

    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

Discussions similaires

  1. Réponses: 2
    Dernier message: 18/11/2002, 09h12
  2. equivalent à explode?
    Par djridou dans le forum Langage
    Réponses: 3
    Dernier message: 28/08/2002, 11h01
  3. [Kylix] Equivalent ShellExec en CLX
    Par Anonymous dans le forum EDI
    Réponses: 7
    Dernier message: 14/08/2002, 11h55
  4. Equivalent à ExeName pour une DLL
    Par Smortex dans le forum Langage
    Réponses: 7
    Dernier message: 16/07/2002, 21h07
  5. [Kylix] equivalent winsock avec kylix
    Par Victor dans le forum EDI
    Réponses: 2
    Dernier message: 08/05/2002, 07h43

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo