J'ai remarqué que certains programmeurs, lorsqu'ils créaient une classe en
C++, déclaraient tout dans leur fichier class.h.
ex:
class.h:
class MaClass{
public:
//constructeur
MaClass();
//methode lambda
int methode();
....
};
MaClass:MaClass(){
....
}
int MaClass::methode(){
...
}
//****************
Ceci, au lieu de déclarer la class dans le fichier class.h et d'alimenter
les méthodes dans le fichier class.cpp.
Si j'y vois un avantage certains, à savoir l'utilisation d'un seul fichier
pour tout décrire, en revanche, ma faible expérience en C++ ne me permet pas
d'en voir
les inconvénients.
Est-ce possible de faire cela ou doit-on respecter rigoureusement le contenu
d'un fichier .h ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
AG
Nicolas ROBERT wrote:
Bonjour,
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une classe en C++, déclaraient tout dans leur fichier class.h. ex:
class.h:
class MaClass{ public: //constructeur MaClass(); //methode lambda int methode();
.... };
MaClass:MaClass(){ .... }
int MaClass::methode(){ ... } //**************** Ceci, au lieu de déclarer la class dans le fichier class.h et d'alimenter les méthodes dans le fichier class.cpp. Si j'y vois un avantage certains, à savoir l'utilisation d'un seul fichier pour tout décrire, en revanche, ma faible expérience en C++ ne me permet pas d'en voir les inconvénients. Est-ce possible de faire cela ou doit-on respecter rigoureusement le contenu d'un fichier .h ?
Les experts en C++ seront ravis de te redonner la réponse. fu2 fr.comp.lang.c++
Nicolas ROBERT wrote:
Bonjour,
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une classe en
C++, déclaraient tout dans leur fichier class.h.
ex:
class.h:
class MaClass{
public:
//constructeur
MaClass();
//methode lambda
int methode();
....
};
MaClass:MaClass(){
....
}
int MaClass::methode(){
...
}
//****************
Ceci, au lieu de déclarer la class dans le fichier class.h et d'alimenter
les méthodes dans le fichier class.cpp.
Si j'y vois un avantage certains, à savoir l'utilisation d'un seul fichier
pour tout décrire, en revanche, ma faible expérience en C++ ne me permet pas
d'en voir
les inconvénients.
Est-ce possible de faire cela ou doit-on respecter rigoureusement le contenu
d'un fichier .h ?
Les experts en C++ seront ravis de te redonner la réponse.
fu2 fr.comp.lang.c++
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une classe en C++, déclaraient tout dans leur fichier class.h. ex:
class.h:
class MaClass{ public: //constructeur MaClass(); //methode lambda int methode();
.... };
MaClass:MaClass(){ .... }
int MaClass::methode(){ ... } //**************** Ceci, au lieu de déclarer la class dans le fichier class.h et d'alimenter les méthodes dans le fichier class.cpp. Si j'y vois un avantage certains, à savoir l'utilisation d'un seul fichier pour tout décrire, en revanche, ma faible expérience en C++ ne me permet pas d'en voir les inconvénients. Est-ce possible de faire cela ou doit-on respecter rigoureusement le contenu d'un fichier .h ?
Les experts en C++ seront ravis de te redonner la réponse. fu2 fr.comp.lang.c++
Thierry
Bonjour,
Il est d'usage de separer declaration et implementation comme on le faisait en C (.h et .c) pour des raisons fonctionnelles (modules, librairies) et esthétiques. Cependant il y avait un bug dans les versions precedentes de VC obligeant les class "template" a être declarées et implementées dans le même fichier .h. D'où peut-etre les claas que tu as vu.
Xpost+fu2 fclc++
Nicolas ROBERT a écrit :
Bonjour,
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une classe en C++, déclaraient tout dans leur fichier class.h. ex:
class.h:
class MaClass{ public: //constructeur MaClass(); //methode lambda int methode();
.... };
MaClass:MaClass(){ .... }
int MaClass::methode(){ ... } //**************** Ceci, au lieu de déclarer la class dans le fichier class.h et d'alimenter les méthodes dans le fichier class.cpp. Si j'y vois un avantage certains, à savoir l'utilisation d'un seul fichier pour tout décrire, en revanche, ma faible expérience en C++ ne me permet pas d'en voir les inconvénients. Est-ce possible de faire cela ou doit-on respecter rigoureusement le contenu d'un fichier .h ?
-- « Always look at the bright side of the life... »
Bonjour,
Il est d'usage de separer declaration et implementation comme on le faisait
en C (.h et .c) pour des raisons fonctionnelles (modules, librairies) et
esthétiques.
Cependant il y avait un bug dans les versions precedentes de VC obligeant
les class "template" a être declarées et implementées dans le même fichier
.h. D'où peut-etre les claas que tu as vu.
Xpost+fu2 fclc++
Nicolas ROBERT a écrit :
Bonjour,
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une
classe en C++, déclaraient tout dans leur fichier class.h.
ex:
class.h:
class MaClass{
public:
//constructeur
MaClass();
//methode lambda
int methode();
....
};
MaClass:MaClass(){
....
}
int MaClass::methode(){
...
}
//****************
Ceci, au lieu de déclarer la class dans le fichier class.h et
d'alimenter les méthodes dans le fichier class.cpp.
Si j'y vois un avantage certains, à savoir l'utilisation d'un seul
fichier pour tout décrire, en revanche, ma faible expérience en C++ ne
me permet pas d'en voir
les inconvénients.
Est-ce possible de faire cela ou doit-on respecter rigoureusement le
contenu d'un fichier .h ?
--
« Always look at the bright side of the life... »
Il est d'usage de separer declaration et implementation comme on le faisait en C (.h et .c) pour des raisons fonctionnelles (modules, librairies) et esthétiques. Cependant il y avait un bug dans les versions precedentes de VC obligeant les class "template" a être declarées et implementées dans le même fichier .h. D'où peut-etre les claas que tu as vu.
Xpost+fu2 fclc++
Nicolas ROBERT a écrit :
Bonjour,
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une classe en C++, déclaraient tout dans leur fichier class.h. ex:
class.h:
class MaClass{ public: //constructeur MaClass(); //methode lambda int methode();
.... };
MaClass:MaClass(){ .... }
int MaClass::methode(){ ... } //**************** Ceci, au lieu de déclarer la class dans le fichier class.h et d'alimenter les méthodes dans le fichier class.cpp. Si j'y vois un avantage certains, à savoir l'utilisation d'un seul fichier pour tout décrire, en revanche, ma faible expérience en C++ ne me permet pas d'en voir les inconvénients. Est-ce possible de faire cela ou doit-on respecter rigoureusement le contenu d'un fichier .h ?
-- « Always look at the bright side of the life... »
Arnaud Debaene
Nicolas ROBERT wrote:
Bonjour,
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une classe en C++, déclaraient tout dans leur fichier class.h.
<snip>
Ceci, au lieu de déclarer la class dans le fichier class.h et d'alimenter les méthodes dans le fichier class.cpp. Si j'y vois un avantage certains, à savoir l'utilisation d'un seul fichier pour tout décrire, en revanche, ma faible expérience en C++ ne me permet pas d'en voir les inconvénients.
L'inconvénient tient en un mot : l'encapsulation (ou plutôt l'absence d'encapsulation ;-). L'un des principes de base de la POO, c'est que l'utilisateur d'une classe n'a pas à connaitre les détails d'implémentation de cette classe, juste l'interface pour la manipuler. Cette abstraction est absolument indispensable sue de gros projets afin de pouvoir réutiliser des "briques logicelles" opaques sans se soucier de comment elles sont écrites. Dans ce cadre, on considère que c'est mieux de laisser le moins de choses possible dans l'interface de la classe (le header).
Quelques remarques: - la POO n'est pas indispensable pour réaliser cette abstraction et cette sépration interface/implémentation, mais elle aide bien.
- Le C++ "classique" laisse déjà voir trop de choses dans le header de la classe : tous les membres (données et fonctions) privées ne devraient pas y apparaiter puisque ce sont par définition des détails d'implémentation. Il est possible de contourner cela avec l'idiome du "compilateur firewall" ou pimpl, mais c'est un peu lourd à mettre en oeuvre.
- Placer ton implémentation dans un .cpp qui n'est pas livré au client, c'est une façon (qui vaut ce qu'elle vaut, mais c'est déjà pas trop mal) de protéger tes algorithmes à la fois de la concurrence et, dans une certaine mesure, du piratage.
Est-ce possible de faire cela ou doit-on respecter rigoureusement le contenu d'un fichier .h ?
C'est possible bien sur, mais pas recommandé. C'est même obligatoire pour les classes templates, sauf si tu utilises un compilateur qui implémente le mot clé "export" (un seul le fait aujourd'hui à ma connaissance : Comeau).
Arnaud
Nicolas ROBERT wrote:
Bonjour,
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une
classe en C++, déclaraient tout dans leur fichier class.h.
<snip>
Ceci, au lieu de déclarer la class dans le fichier class.h et
d'alimenter les méthodes dans le fichier class.cpp.
Si j'y vois un avantage certains, à savoir l'utilisation d'un seul
fichier pour tout décrire, en revanche, ma faible expérience en C++
ne me permet pas d'en voir
les inconvénients.
L'inconvénient tient en un mot : l'encapsulation (ou plutôt l'absence
d'encapsulation ;-). L'un des principes de base de la POO, c'est que
l'utilisateur d'une classe n'a pas à connaitre les détails d'implémentation
de cette classe, juste l'interface pour la manipuler. Cette abstraction est
absolument indispensable sue de gros projets afin de pouvoir réutiliser des
"briques logicelles" opaques sans se soucier de comment elles sont écrites.
Dans ce cadre, on considère que c'est mieux de laisser le moins de choses
possible dans l'interface de la classe (le header).
Quelques remarques:
- la POO n'est pas indispensable pour réaliser cette abstraction et cette
sépration interface/implémentation, mais elle aide bien.
- Le C++ "classique" laisse déjà voir trop de choses dans le header de la
classe : tous les membres (données et fonctions) privées ne devraient pas y
apparaiter puisque ce sont par définition des détails d'implémentation. Il
est possible de contourner cela avec l'idiome du "compilateur firewall" ou
pimpl, mais c'est un peu lourd à mettre en oeuvre.
- Placer ton implémentation dans un .cpp qui n'est pas livré au client,
c'est une façon (qui vaut ce qu'elle vaut, mais c'est déjà pas trop mal) de
protéger tes algorithmes à la fois de la concurrence et, dans une certaine
mesure, du piratage.
Est-ce possible de faire cela ou doit-on respecter rigoureusement le
contenu d'un fichier .h ?
C'est possible bien sur, mais pas recommandé. C'est même obligatoire pour
les classes templates, sauf si tu utilises un compilateur qui implémente le
mot clé "export" (un seul le fait aujourd'hui à ma connaissance : Comeau).
J'ai remarqué que certains programmeurs, lorsqu'ils créaient une classe en C++, déclaraient tout dans leur fichier class.h.
<snip>
Ceci, au lieu de déclarer la class dans le fichier class.h et d'alimenter les méthodes dans le fichier class.cpp. Si j'y vois un avantage certains, à savoir l'utilisation d'un seul fichier pour tout décrire, en revanche, ma faible expérience en C++ ne me permet pas d'en voir les inconvénients.
L'inconvénient tient en un mot : l'encapsulation (ou plutôt l'absence d'encapsulation ;-). L'un des principes de base de la POO, c'est que l'utilisateur d'une classe n'a pas à connaitre les détails d'implémentation de cette classe, juste l'interface pour la manipuler. Cette abstraction est absolument indispensable sue de gros projets afin de pouvoir réutiliser des "briques logicelles" opaques sans se soucier de comment elles sont écrites. Dans ce cadre, on considère que c'est mieux de laisser le moins de choses possible dans l'interface de la classe (le header).
Quelques remarques: - la POO n'est pas indispensable pour réaliser cette abstraction et cette sépration interface/implémentation, mais elle aide bien.
- Le C++ "classique" laisse déjà voir trop de choses dans le header de la classe : tous les membres (données et fonctions) privées ne devraient pas y apparaiter puisque ce sont par définition des détails d'implémentation. Il est possible de contourner cela avec l'idiome du "compilateur firewall" ou pimpl, mais c'est un peu lourd à mettre en oeuvre.
- Placer ton implémentation dans un .cpp qui n'est pas livré au client, c'est une façon (qui vaut ce qu'elle vaut, mais c'est déjà pas trop mal) de protéger tes algorithmes à la fois de la concurrence et, dans une certaine mesure, du piratage.
Est-ce possible de faire cela ou doit-on respecter rigoureusement le contenu d'un fichier .h ?
C'est possible bien sur, mais pas recommandé. C'est même obligatoire pour les classes templates, sauf si tu utilises un compilateur qui implémente le mot clé "export" (un seul le fait aujourd'hui à ma connaissance : Comeau).
