Classe et visual c++

Sylvain wrote:

kanze wrote on 27/04/2006 09:50:

En C++, la façon de faire ces répétions, c'est avec
l'inclusion d'un fichier d'en-tête (typiquement un .hpp sous
Windows).

.h suffit - les headers utilisateurs utilisent cette extension
que les fichiers sources sont générés par l'IDE .hpp est
"reconnu" par l'IDE (signifiant qu'il les ignore comme les .h)

Au niveau du compilateur, tu peux faire ce que tu veux --
toto.titi marche aussi (sans parler de string ou vector:-)).
Dans la plupart d'endroits où j'ai travaillé, en revanche, on a
gardé .h pour les en-têtes acceptables et en C et en C++. Je
croyais que c'était aussi l'habitude du monde Windows : j'avoue
ne pas connaître beaucoup ce monde, mais je constate que
l'utilisation du .hpp est très répandue.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze wrote on 27/04/2006 18:29:

Dans la plupart d'endroits où j'ai travaillé, en revanche, on a
gardé .h pour les en-têtes acceptables et en C et en C++. Je
croyais que c'était aussi l'habitude du monde Windows : j'avoue
ne pas connaître beaucoup ce monde, mais je constate que
l'utilisation du .hpp est très répandue.

répandu chez ? un IDE particulier d'un éditeur particulier ?

microsoft les utilise très peu et semble en réserver l'usage à des
fichiers de déclaration et définition (des classes où toutes les
méthodes sont inline) .hpp serait alors le condensat de .h et .cpp car
un seul fichier est fourni -- est-ce la bonne explication historique??

Sylvain.

Sylvain wrote:

kanze wrote on 27/04/2006 18:29:

Dans la plupart d'endroits où j'ai travaillé, en revanche,
on a gardé .h pour les en-têtes acceptables et en C et en
C++. Je croyais que c'était aussi l'habitude du monde
Windows : j'avoue ne pas connaître beaucoup ce monde, mais
je constate que l'utilisation du .hpp est très répandue.

répandu chez ? un IDE particulier d'un éditeur particulier ?

Les bibliothèques disponibles sur la toile : Boost, par exemple.
Mais en régardant, c'est vrai qu'il y en a beaucoup aussi qui se
sert d'un .h, tout simplement. En fait, Boost c'est la seule
exception que je trouve rapidement. (En revanche, c'est la seule
bibliothèque tièrce que j'utilise régulièrement.)

Il me semble aussi que Borland utilisait .hpp pour ses en-têtes
C++. Je sais que quand la question du nommage des en-têtes
standard a été discuté dans le comité, on a dit qu'il n'y avait
pas de "standard" de facto, que selon l'implémentation, on avait
.h, .hpp, .hxx et peut-être aussi .hh.

Personellement, je n'aime pas .h -- je vois bien une utilité
dans la distinction entre les en-têtes C et les en-têtes C++.
Mais il semble que c'est bien encrusté.

microsoft les utilise très peu et semble en réserver l'usage à
des fichiers de déclaration et définition (des classes où
toutes les méthodes sont inline) .hpp serait alors le
condensat de .h et .cpp car un seul fichier est fourni --
est-ce la bonne explication historique??

Je ne sais pas. D'après mes souvenirs, CFront utilisait .C et
.h. Le désir de distinguer entre les en-têtes C ou C/C++ et les
en-têtes pûrement C++ s'est fait sentir assez tôt chez certains,
et on a logiquement adopté .H. Puis, Walter a écrit son
compilateur MS-DOS, où la case n'était pas signifiant, et .C et
.c nommait le même fichier:-). Alors, une nouvelle convention
qui ne se basait pas sur la case s'est développée -- plusieurs
fois, de façon indépendante. Je sais que le compilateur de
Walter acceptait .cc, .cpp, .cxx, et je crois .c++ -- si je me
souviens bien, Walter lui-même utilisait .cxx, mais je ne suis
plus sûr. Et évidemment, ceux qui utilisaient .H avant
adoptaient la forme .hh, hpp ou .hxx.

Et quand j'y pense, je ne sais pas pourquoi .cc s'est tellement
répandu en milieu Unix. A priori, si on restait sous Unix, il
n'y avait pas de raison de changer de .C, et si on voulait
supporter aussi MS-DOS, je l'aurais imaginer plus logique
d'adopter les conventions du compilateur MS-DOS dont on se
servait : .cpp pour Borland, ou .cxx pour Zortech -- Microsoft
n'avait pas encore de compilateur C++ à l'époque. Mais je
constate que parmi mes clients, .cc est la règle ; pour les
en-têtes, on trouve surtout .hh, mais aussi .h. Et que .cc est
assez répandu pour que Microsoft se mette à le supporter aussi.
Avec VC++ 6.0, il fallait /Tp pour que le compilateur (ou
proprement parlant, le pilote du compilateur) reconnaisse que le
fichier était une source C++ ; avec la version 2005, il le
reconnaît d'office.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze wrote on 28/04/2006 09:02:

Personellement, je n'aime pas .h -- je vois bien une utilité
dans la distinction entre les en-têtes C et les en-têtes C++.

les gouts et les suffixes ...

D'après mes souvenirs, CFront utilisait .C et .h

CFront de Apple utilisait .cpp (en input), on ne pense peut être pas au
même (peut être parce que le file system de MacOS n'était pas case
sensitive).

je ne sais pas pourquoi .cc s'est tellement
répandu en milieu Unix.

ne serait-ce pas du au nom des compilos eux-même ? ("cc" de Sun, par
exemple, bien avant que "gcc" ne soit répandu).

j'aurais imaginer plus logique d'adopter les
conventions du compilateur MS-DOS dont on se
servait : .cpp pour Borland, ou .cxx pour Zortech --
Microsoft n'avait pas encore de compilateur C++ à l'époque

j'ai commencé le C/C++ avec Turbo C 2.0 en 1989, MS n'avait pas de role
d'éditeur de compilateur C à cette date (préférant le basic), mais ils
avaient quand même des compilos C internes, la (vraie) première version
commerciale date de 1993 avec VC 1.5 targetant Windows 1.0 et elle a
repris la convention .h/.cpp déjà utilisée par Borland en effet.

Sylvain.

Sylvain wrote on 28/04/2006 19:49:

la (vraie) première version commerciale date de 1993
avec VC 1.5 targetant Windows 1.0

oups, windows 3 évidemment !

(il y avait donc bien des outils sous Win 1 et 2, ils ont du rester
aussi confidentiels et durer aussi longtemps que ces "GUI").

Sylvain.

Sylvain wrote:

kanze wrote on 28/04/2006 09:02:

Personellement, je n'aime pas .h -- je vois bien une utilité
dans la distinction entre les en-têtes C et les en-têtes C++.

les gouts et les suffixes ...

:-).

Est-ce qu'une partie de la différence pourrait venir du fait
qu'au moins au départ, j'avais à maintenir des fichiers
d'en-tête de C, aussi ? D'où le désir de les distinguer dans les
noms.

D'après mes souvenirs, CFront utilisait .C et .h

CFront de Apple utilisait .cpp (en input), on ne pense peut
être pas au même (peut être parce que le file system de MacOS
n'était pas case sensitive).

CFront de MS-DOS aussi, sans doute. J'aurais probablement dû
dire « les premiers implémentations C++ » (qui était évidemment
sous Unix, vue où elles étaient développées).

Je viens de régarder dans la première édition du Stroustrup : il
utilisait .c et .h ! C'est à croire qu'il voyait le langage alors
comme une nouvelle version de C, et non comme un nouveau
langage.

je ne sais pas pourquoi .cc s'est tellement répandu en milieu
Unix.

ne serait-ce pas du au nom des compilos eux-même ? ("cc" de
Sun, par exemple, bien avant que "gcc" ne soit répandu).

« cc », c'est le nom du compilateur C ; le compilateur C++
s'appelait, et s'appelle toujours CC (et pour compiler et linker
correctement du C++, gcc s'invoque avec g++). Je crois (mais
j'avoue que c'est un peu de la spéculation de ma part) que c'est
simplement une façon de renforcer le c -- qu'on le voyait en
quelque sort « analogue » à l'utilisation du majuscule.

j'aurais imaginer plus logique d'adopter les conventions du
compilateur MS-DOS dont on se servait : .cpp pour Borland, ou
.cxx pour Zortech -- Microsoft n'avait pas encore de
compilateur C++ à l'époque

j'ai commencé le C/C++ avec Turbo C 2.0 en 1989, MS n'avait
pas de role d'éditeur de compilateur C à cette date (préférant
le basic), mais ils avaient quand même des compilos C
internes, la (vraie) première version commerciale date de 1993
avec VC 1.5 targetant Windows 1.0 et elle a repris la
convention .h/.cpp déjà utilisée par Borland en effet.

En 1989, c'était encore Turbo C, pas C++. En 1989, il y avait
exactement trois compilateurs C++ : celui de Stroustrup
(CFront), celui de Mike Tiemann (les premiers g++), et celui de
Walter Bright (Zortech). Mais Borland, Taumet et Lucid n'ont pas
tardé à suivre. (J'ai commencé le C++ en 1989, avec le Zortech.)

J'ai acheté un compilateur Microsoft C en 1983 ou 1984. C'est
vrai que c'était la version 1.0, et qu'il provenait en fait de
Lattice -- Microsoft s'est contenté de mettre leur nom sur
l'emballage. Je ne sais pas quand Microsoft l'a laissé tomber
pour un qu'ils ont écrit eux-même ; mon prochain contact avec un
compilateur Microsoft était en 1998.

--
James Kanze kanze.james@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Daniel wrote:

Merci pour la réponse, Vous avez mis le doigt sur le problème.
En effet je n'arrive pas meme avec une fonction.h à faire reconnaitre
dans l'environnement c++ une fonction crée autrement que l'outils visual.

Je ne suis pas certain que ce soit la solution, mais ce pourrait être le
cas.

Si vous voulez que plusieurs fichiers puisse utiliser votre classe, il
faut la déclarer dans un .h :

myclass.h

#if !defined(MyClass_H_)
#define MyClass_H_

class MyClass {
public: // sinon, vous ne pourrez pas appeler le constructeur
MyClass(char *fileName);
~MyClass();
};
// la définition de la classe est dans le .cpp
#endif

Ensuite, dans le fichier où vous voulez utiliser la classe, il faut
inclure de .h :

#include "myclass.h"

Et c'est là que Visual ne vous aide pas : le compilateur, par défaut, ne
va pas chercher les fichiers .h dans le répertoire qui contient les .h
créés dans le projet. Il faut donc aller dans les paramètres du projet,
dans l'onglet compilation C++ et ajouter le répertoire (habituellement,
".") contenant les fichiers .h créés dans le projet.

J'espère que cela vous aidera.

--
Arnaud