kanze@gabi-soft.fr wrote:
> (En passant, ce sont des .hh et des .cc.)
Je me permet de rebondir la dessus :
Le deux compilateurs sous Windows que je connais (Borland et Microsoft)
font par défaut des .h et .cpp
Boost utilise des .hpp et des .cpp
On m'avait sorti a une epoque (je sais plus qui) que le .hpp etait
inutile, du fait que c'etait uniquement un fichier d'inclusion, et qu'il
n'etait donc pas necessaire de faire la difference avec un header de C,
etant donné que la difference etait detectée par le .cpp.
que le "p" signifiait "Plus", qui allait bien
Donc que dit (si elle dit quelque chose) la norme? qu'est qui permet a
Gabi de dire .cc et .hh? pourquoi ces extensions?
(pas tres parlant comme extension d'ailleurs...)
Le fait de nommer differement un fichier d'inclusion est-il necessaire?
(En passant, ce sont des .hh et des .cc.) Donc que dit (si elle dit quelque chose) la norme? qu'est qui permet a
Gabi de dire .cc et .hh? pourquoi ces extensions? (pas tres parlant comme extension d'ailleurs...)
Attention à ne pas confondre le Gabi que tu peux lire dans la signature avec le Gaby de Gabriel Dos Reis. Heureusement pour nous, ces deux-là sont assez souvent en désaccord pour limiter la confusion ;)
Le fait de nommer differement un fichier d'inclusion est-il necessaire?
Du reste, sans savoir ce que dit la norme, je suis bien certain qu'elle n'impose pas une extension de fichier particulier (en dehors de ce que C impose). Mais quelqu'un confirmera (ou infirmera) le cas échéant...
Chris
Martinez Jerome wrote:
kanze@gabi-soft.fr wrote:
(En passant, ce sont des .hh et des .cc.)
Donc que dit (si elle dit quelque chose) la norme? qu'est qui permet a
Gabi de dire .cc et .hh? pourquoi ces extensions?
(pas tres parlant comme extension d'ailleurs...)
Attention à ne pas confondre le Gabi que tu peux lire dans la signature avec
le Gaby de Gabriel Dos Reis. Heureusement pour nous, ces deux-là sont assez
souvent en désaccord pour limiter la confusion ;)
Le fait de nommer differement un fichier d'inclusion est-il
necessaire?
Du reste, sans savoir ce que dit la norme, je suis bien certain qu'elle
n'impose pas une extension de fichier particulier (en dehors de ce que C
impose). Mais quelqu'un confirmera (ou infirmera) le cas échéant...
(En passant, ce sont des .hh et des .cc.) Donc que dit (si elle dit quelque chose) la norme? qu'est qui permet a
Gabi de dire .cc et .hh? pourquoi ces extensions? (pas tres parlant comme extension d'ailleurs...)
Attention à ne pas confondre le Gabi que tu peux lire dans la signature avec le Gaby de Gabriel Dos Reis. Heureusement pour nous, ces deux-là sont assez souvent en désaccord pour limiter la confusion ;)
Le fait de nommer differement un fichier d'inclusion est-il necessaire?
Du reste, sans savoir ce que dit la norme, je suis bien certain qu'elle n'impose pas une extension de fichier particulier (en dehors de ce que C impose). Mais quelqu'un confirmera (ou infirmera) le cas échéant...
Chris
Fonzy
"Martinez Jerome" a écrit dans le message de news:bo61j5$
wrote:
(En passant, ce sont des .hh et des .cc.)
Je me permet de rebondir la dessus : Le deux compilateurs sous Windows que je connais (Borland et Microsoft) font par défaut des .h et .cpp
et tu connais pas des compilateurs sous unix par hasard?
Tu auras la réponse... :)
Fonzy
"Martinez Jerome" <jerome.martinez@aenlever-orangefrance.com> a écrit dans
le message de news:bo61j5$rcl7@news.rd.francetelecom.fr...
kanze@gabi-soft.fr wrote:
(En passant, ce sont des .hh et des .cc.)
Je me permet de rebondir la dessus :
Le deux compilateurs sous Windows que je connais (Borland et Microsoft)
font par défaut des .h et .cpp
et tu connais pas des compilateurs sous unix par hasard?
"Martinez Jerome" a écrit dans le message de news:bo61j5$
wrote:
(En passant, ce sont des .hh et des .cc.)
Je me permet de rebondir la dessus : Le deux compilateurs sous Windows que je connais (Borland et Microsoft) font par défaut des .h et .cpp
et tu connais pas des compilateurs sous unix par hasard?
Tu auras la réponse... :)
Fonzy
Jean-Marc Bourguet
Martinez Jerome writes:
wrote:
(En passant, ce sont des .hh et des .cc.)
Je me permet de rebondir la dessus : Le deux compilateurs sous Windows que je connais (Borland et Microsoft) font par défaut des .h et .cpp
Boost utilise des .hpp et des .cpp
On m'avait sorti a une epoque (je sais plus qui) que le .hpp etait inutile, du fait que c'etait uniquement un fichier d'inclusion, et qu'il n'etait donc pas necessaire de faire la difference avec un header de C, etant donné que la difference etait detectée par le .cpp. que le "p" signifiait "Plus", qui allait bien
Si tu travailles dans un projet ou le C et le C++ sont melanges, c'est utile de savoir si un fichier include contient du C ou du C++. Ca nous arrive meme d'avoir un .h, un .hpp et un .cpp.
Donc que dit (si elle dit quelque chose) la norme?
Rien.
qu'est qui permet a Gabi de dire .cc et .hh? pourquoi ces extensions? (pas tres parlant comme extension d'ailleurs...)
C'est une des autres conventions. J'ai aussi vu .C, .cxx et meme .c pour le code, .H, .hxx pour les en-tetes. L'important est d'avoir une convention et de s'y tenir.
Il parait que certains compilateurs ont une forte preference pour .cpp; mais chaque fois que j'ai voulu verifier n'importe quel systeme fonctionnait apres une configuration adequate.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je me permet de rebondir la dessus : Le deux compilateurs sous
Windows que je connais (Borland et Microsoft) font par défaut des .h
et .cpp
Boost utilise des .hpp et des .cpp
On m'avait sorti a une epoque (je sais plus qui) que le .hpp etait
inutile, du fait que c'etait uniquement un fichier d'inclusion, et
qu'il n'etait donc pas necessaire de faire la difference avec un
header de C, etant donné que la difference etait detectée par le
.cpp. que le "p" signifiait "Plus", qui allait bien
Si tu travailles dans un projet ou le C et le C++ sont melanges, c'est
utile de savoir si un fichier include contient du C ou du C++. Ca
nous arrive meme d'avoir un .h, un .hpp et un .cpp.
Donc que dit (si elle dit quelque chose) la norme?
Rien.
qu'est qui permet a Gabi de dire .cc et .hh? pourquoi ces
extensions? (pas tres parlant comme extension d'ailleurs...)
C'est une des autres conventions. J'ai aussi vu .C, .cxx et meme .c
pour le code, .H, .hxx pour les en-tetes. L'important est d'avoir une
convention et de s'y tenir.
Il parait que certains compilateurs ont une forte preference pour
.cpp; mais chaque fois que j'ai voulu verifier n'importe quel systeme
fonctionnait apres une configuration adequate.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je me permet de rebondir la dessus : Le deux compilateurs sous Windows que je connais (Borland et Microsoft) font par défaut des .h et .cpp
Boost utilise des .hpp et des .cpp
On m'avait sorti a une epoque (je sais plus qui) que le .hpp etait inutile, du fait que c'etait uniquement un fichier d'inclusion, et qu'il n'etait donc pas necessaire de faire la difference avec un header de C, etant donné que la difference etait detectée par le .cpp. que le "p" signifiait "Plus", qui allait bien
Si tu travailles dans un projet ou le C et le C++ sont melanges, c'est utile de savoir si un fichier include contient du C ou du C++. Ca nous arrive meme d'avoir un .h, un .hpp et un .cpp.
Donc que dit (si elle dit quelque chose) la norme?
Rien.
qu'est qui permet a Gabi de dire .cc et .hh? pourquoi ces extensions? (pas tres parlant comme extension d'ailleurs...)
C'est une des autres conventions. J'ai aussi vu .C, .cxx et meme .c pour le code, .H, .hxx pour les en-tetes. L'important est d'avoir une convention et de s'y tenir.
Il parait que certains compilateurs ont une forte preference pour .cpp; mais chaque fois que j'ai voulu verifier n'importe quel systeme fonctionnait apres une configuration adequate.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Molina
Si ça peut aider j'ai toujours utilisé .cpp et .h, de DOS à Windows en passant par Unix et quelques consoles de jeux. Donc à vous de voir ce qui est le plus logique. Si je devais choisir aujourd'hui j'opterai pour .cpp et .hpp, qui ont le mérite d'être explicites, surtout pour le .h. Peut-être même que .c++ et .h++ fonctionnent ! À essayer pour le fun :p
JM
-- Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
Si ça peut aider j'ai toujours utilisé .cpp et .h, de DOS à Windows en
passant par Unix et quelques consoles de jeux.
Donc à vous de voir ce qui est le plus logique.
Si je devais choisir aujourd'hui j'opterai pour .cpp et .hpp, qui ont le
mérite d'être explicites, surtout pour le .h.
Peut-être même que .c++ et .h++ fonctionnent ! À essayer pour le fun :p
JM
--
Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
Si ça peut aider j'ai toujours utilisé .cpp et .h, de DOS à Windows en passant par Unix et quelques consoles de jeux. Donc à vous de voir ce qui est le plus logique. Si je devais choisir aujourd'hui j'opterai pour .cpp et .hpp, qui ont le mérite d'être explicites, surtout pour le .h. Peut-être même que .c++ et .h++ fonctionnent ! À essayer pour le fun :p
JM
-- Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
kanze
Martinez Jerome wrote in message news:<bo61j5$...
wrote:
(En passant, ce sont des .hh et des .cc.)
J'aurais dû mettre un :-), mais ça me semblait tellement évident. C'est tellement évident qu'il s'agit des conventions plus ou moins arbitraires.
Je me permet de rebondir la dessus :
Le deux compilateurs sous Windows que je connais (Borland et Microsoft) font par défaut des .h et .cpp
Les compilateurs que je connais (y compris VC++ sous Windows) ne font pas de « défaut » -- je choisis le nom que je veux dans l'éditeur. Le seul « défaut », éventuellement, ce sont les noms des fichiers d'en-tête fournis avec le compilateur.
Tous les projets sur lesquels j'ai travaillé se sont servi de .cc et de .hh. Sans problèmes, y compris avec VC++ sous Windows.
Boost utilise des .hpp et des .cpp
C'est une autre convention.
Je crois que dans le monde de Windows, .hpp et .cpp est la convention la plus répandue, et que dans le monde de Unix, .hh et .cc. Mais c'est largement de la spéculation de ma part -- je ne connais aucune statistique réele.
On m'avait sorti a une epoque (je sais plus qui) que le .hpp etait inutile, du fait que c'etait uniquement un fichier d'inclusion, et qu'il n'etait donc pas necessaire de faire la difference avec un header de C, etant donné que la difference etait detectée par le .cpp. que le "p" signifiait "Plus", qui allait bien
Formellement, les implémentations ont beaucoup de liberté dans l'interprétation de ce qui est écrit dans le #include. Dans la pratique, toutes les implémentations que je connais le traite simplement comme un nom d'un fichier, et le passe tel quel au système d'exploitation. Les seules variations que je connais, c'est en ce qui concerne l'interprétation des caractères échappés ('', etc.). Alors, tu *peux* faire n'importe quoi que comprend ton système d'exploitation.
D'après mon expérience, il me semble préférable à distinguer les en-têtes par le nom, et en plus, de distinguer les en-têtes C++ de ceux qui pourraient servir aussi en C. Donc, .h pour C, .hh (ou .hpp, ou .hxx, ou .H) pour C++. Mais la nécessité de la distinction entre C et C++ n'est pas universellement reconnu, et il y a bien des endroits qui se sert de .h pour les deux.
Donc que dit (si elle dit quelque chose) la norme? qu'est qui permet a Gabi de dire .cc et .hh? pourquoi ces extensions? (pas tres parlant comme extension d'ailleurs...)
D'abord, Gabi Software c'est le nom de ma société (et aussi le nom de ma femme) -- moi, c'est James.
Ensuite, je n'ai jamais vu une convention « parlante » : qui veut avoir à écrire "main.sourceC++" ou #include "xyz.header-C++". La convention initiale (avec le premier compilateur C++), c'était .h et .C. Seulement, certains (dont moi-même) préfère distinguer les en-têtes purement C++ des en-têtes pouvant servir aussi à C, et évidemment, la distinction .c/.C est perdue dans la plupart des systèmes d'exploitation. Du coup, beaucoup de gens sont sentis motivé à adopter une autre convention. Et quand beaucoup de gens créent de façon indépendante des conventions, on finit par avoir beaucoup de conventions.
Le fait de nommer differement un fichier d'inclusion est-il necessaire?
Le fait d'avoir une bonne convention, dont tu te sers systèmatiquement, est important. Non pour le compilateur, mais pour les gens qui travaillent sur le code. Aussi, aujourd'hui, je n'inventerais pas une nouvelle convention ; si je travaillais surtout dans le monde des Windows, c'est probable que j'utiliserais .hpp et .cpp (bien que mon premier compilateur Windows, le Zortech, utilisait .hxx et .cxx dans ces exemples). Je travaille en fait surtout dans le monde des Unix ; je me sers donc de .hh et de .cc.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Martinez Jerome <jerome.martinez@aenlever-orangefrance.com> wrote in
message news:<bo61j5$rcl7@news.rd.francetelecom.fr>...
kanze@gabi-soft.fr wrote:
(En passant, ce sont des .hh et des .cc.)
J'aurais dû mettre un :-), mais ça me semblait tellement évident. C'est
tellement évident qu'il s'agit des conventions plus ou moins
arbitraires.
Je me permet de rebondir la dessus :
Le deux compilateurs sous Windows que je connais (Borland et
Microsoft) font par défaut des .h et .cpp
Les compilateurs que je connais (y compris VC++ sous Windows) ne font
pas de « défaut » -- je choisis le nom que je veux dans l'éditeur. Le
seul « défaut », éventuellement, ce sont les noms des fichiers d'en-tête
fournis avec le compilateur.
Tous les projets sur lesquels j'ai travaillé se sont servi de .cc et de
.hh. Sans problèmes, y compris avec VC++ sous Windows.
Boost utilise des .hpp et des .cpp
C'est une autre convention.
Je crois que dans le monde de Windows, .hpp et .cpp est la convention la
plus répandue, et que dans le monde de Unix, .hh et .cc. Mais c'est
largement de la spéculation de ma part -- je ne connais aucune
statistique réele.
On m'avait sorti a une epoque (je sais plus qui) que le .hpp etait
inutile, du fait que c'etait uniquement un fichier d'inclusion, et
qu'il n'etait donc pas necessaire de faire la difference avec un
header de C, etant donné que la difference etait detectée par le .cpp.
que le "p" signifiait "Plus", qui allait bien
Formellement, les implémentations ont beaucoup de liberté dans
l'interprétation de ce qui est écrit dans le #include. Dans la pratique,
toutes les implémentations que je connais le traite simplement comme un
nom d'un fichier, et le passe tel quel au système d'exploitation. Les
seules variations que je connais, c'est en ce qui concerne
l'interprétation des caractères échappés ('\', etc.). Alors, tu *peux*
faire n'importe quoi que comprend ton système d'exploitation.
D'après mon expérience, il me semble préférable à distinguer les
en-têtes par le nom, et en plus, de distinguer les en-têtes C++ de ceux
qui pourraient servir aussi en C. Donc, .h pour C, .hh (ou .hpp, ou
.hxx, ou .H) pour C++. Mais la nécessité de la distinction entre C et
C++ n'est pas universellement reconnu, et il y a bien des endroits qui
se sert de .h pour les deux.
Donc que dit (si elle dit quelque chose) la norme? qu'est qui permet a
Gabi de dire .cc et .hh? pourquoi ces extensions? (pas tres parlant
comme extension d'ailleurs...)
D'abord, Gabi Software c'est le nom de ma société (et aussi le nom de ma
femme) -- moi, c'est James.
Ensuite, je n'ai jamais vu une convention « parlante » : qui veut avoir
à écrire "main.sourceC++" ou #include "xyz.header-C++". La convention
initiale (avec le premier compilateur C++), c'était .h et .C. Seulement,
certains (dont moi-même) préfère distinguer les en-têtes purement C++
des en-têtes pouvant servir aussi à C, et évidemment, la distinction
.c/.C est perdue dans la plupart des systèmes d'exploitation. Du coup,
beaucoup de gens sont sentis motivé à adopter une autre convention. Et
quand beaucoup de gens créent de façon indépendante des conventions, on
finit par avoir beaucoup de conventions.
Le fait de nommer differement un fichier d'inclusion est-il
necessaire?
Le fait d'avoir une bonne convention, dont tu te sers systèmatiquement,
est important. Non pour le compilateur, mais pour les gens qui
travaillent sur le code. Aussi, aujourd'hui, je n'inventerais pas une
nouvelle convention ; si je travaillais surtout dans le monde des
Windows, c'est probable que j'utiliserais .hpp et .cpp (bien que mon
premier compilateur Windows, le Zortech, utilisait .hxx et .cxx dans ces
exemples). Je travaille en fait surtout dans le monde des Unix ; je me
sers donc de .hh et de .cc.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
J'aurais dû mettre un :-), mais ça me semblait tellement évident. C'est tellement évident qu'il s'agit des conventions plus ou moins arbitraires.
Je me permet de rebondir la dessus :
Le deux compilateurs sous Windows que je connais (Borland et Microsoft) font par défaut des .h et .cpp
Les compilateurs que je connais (y compris VC++ sous Windows) ne font pas de « défaut » -- je choisis le nom que je veux dans l'éditeur. Le seul « défaut », éventuellement, ce sont les noms des fichiers d'en-tête fournis avec le compilateur.
Tous les projets sur lesquels j'ai travaillé se sont servi de .cc et de .hh. Sans problèmes, y compris avec VC++ sous Windows.
Boost utilise des .hpp et des .cpp
C'est une autre convention.
Je crois que dans le monde de Windows, .hpp et .cpp est la convention la plus répandue, et que dans le monde de Unix, .hh et .cc. Mais c'est largement de la spéculation de ma part -- je ne connais aucune statistique réele.
On m'avait sorti a une epoque (je sais plus qui) que le .hpp etait inutile, du fait que c'etait uniquement un fichier d'inclusion, et qu'il n'etait donc pas necessaire de faire la difference avec un header de C, etant donné que la difference etait detectée par le .cpp. que le "p" signifiait "Plus", qui allait bien
Formellement, les implémentations ont beaucoup de liberté dans l'interprétation de ce qui est écrit dans le #include. Dans la pratique, toutes les implémentations que je connais le traite simplement comme un nom d'un fichier, et le passe tel quel au système d'exploitation. Les seules variations que je connais, c'est en ce qui concerne l'interprétation des caractères échappés ('', etc.). Alors, tu *peux* faire n'importe quoi que comprend ton système d'exploitation.
D'après mon expérience, il me semble préférable à distinguer les en-têtes par le nom, et en plus, de distinguer les en-têtes C++ de ceux qui pourraient servir aussi en C. Donc, .h pour C, .hh (ou .hpp, ou .hxx, ou .H) pour C++. Mais la nécessité de la distinction entre C et C++ n'est pas universellement reconnu, et il y a bien des endroits qui se sert de .h pour les deux.
Donc que dit (si elle dit quelque chose) la norme? qu'est qui permet a Gabi de dire .cc et .hh? pourquoi ces extensions? (pas tres parlant comme extension d'ailleurs...)
D'abord, Gabi Software c'est le nom de ma société (et aussi le nom de ma femme) -- moi, c'est James.
Ensuite, je n'ai jamais vu une convention « parlante » : qui veut avoir à écrire "main.sourceC++" ou #include "xyz.header-C++". La convention initiale (avec le premier compilateur C++), c'était .h et .C. Seulement, certains (dont moi-même) préfère distinguer les en-têtes purement C++ des en-têtes pouvant servir aussi à C, et évidemment, la distinction .c/.C est perdue dans la plupart des systèmes d'exploitation. Du coup, beaucoup de gens sont sentis motivé à adopter une autre convention. Et quand beaucoup de gens créent de façon indépendante des conventions, on finit par avoir beaucoup de conventions.
Le fait de nommer differement un fichier d'inclusion est-il necessaire?
Le fait d'avoir une bonne convention, dont tu te sers systèmatiquement, est important. Non pour le compilateur, mais pour les gens qui travaillent sur le code. Aussi, aujourd'hui, je n'inventerais pas une nouvelle convention ; si je travaillais surtout dans le monde des Windows, c'est probable que j'utiliserais .hpp et .cpp (bien que mon premier compilateur Windows, le Zortech, utilisait .hxx et .cxx dans ces exemples). Je travaille en fait surtout dans le monde des Unix ; je me sers donc de .hh et de .cc.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
kanze
"Christophe Lephay" wrote in message news:<bo6ap0$8aq$...
Martinez Jerome wrote:
[...]
Le fait de nommer differement un fichier d'inclusion est-il necessaire?
Du reste, sans savoir ce que dit la norme, je suis bien certain qu'elle n'impose pas une extension de fichier particulier (en dehors de ce que C impose). Mais quelqu'un confirmera (ou infirmera) le cas échéant...
La norme (C) dit que l'instruction #include est remplacée par « the entire contents of the source file identified » (en cas de "...") ou par « the entire contents of the header » (cas de <...>). En ce qui concerne comment le fichier est identifié, il dit :
The implementation shall provide unique mappings for sequences consisting of one or more letters or digits followed by a period (.) and a single letter. The first character shall be a letter. The implementation may ignore the distinctions of alphabetical case and restrict the mapping to eight significant characters before the period.
Toutes les implémentations que je connais vont bien au delà.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Christophe Lephay" <christophe-lephay@wanadoo.fr> wrote in message
news:<bo6ap0$8aq$1@news-reader2.wanadoo.fr>...
Martinez Jerome wrote:
[...]
Le fait de nommer differement un fichier d'inclusion est-il
necessaire?
Du reste, sans savoir ce que dit la norme, je suis bien certain
qu'elle n'impose pas une extension de fichier particulier (en dehors
de ce que C impose). Mais quelqu'un confirmera (ou infirmera) le cas
échéant...
La norme (C) dit que l'instruction #include est remplacée par « the
entire contents of the source file identified » (en cas de "...") ou par
« the entire contents of the header » (cas de <...>). En ce qui concerne
comment le fichier est identifié, il dit :
The implementation shall provide unique mappings for sequences
consisting of one or more letters or digits followed by a period (.)
and a single letter. The first character shall be a letter. The
implementation may ignore the distinctions of alphabetical case and
restrict the mapping to eight significant characters before the
period.
Toutes les implémentations que je connais vont bien au delà.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Christophe Lephay" wrote in message news:<bo6ap0$8aq$...
Martinez Jerome wrote:
[...]
Le fait de nommer differement un fichier d'inclusion est-il necessaire?
Du reste, sans savoir ce que dit la norme, je suis bien certain qu'elle n'impose pas une extension de fichier particulier (en dehors de ce que C impose). Mais quelqu'un confirmera (ou infirmera) le cas échéant...
La norme (C) dit que l'instruction #include est remplacée par « the entire contents of the source file identified » (en cas de "...") ou par « the entire contents of the header » (cas de <...>). En ce qui concerne comment le fichier est identifié, il dit :
The implementation shall provide unique mappings for sequences consisting of one or more letters or digits followed by a period (.) and a single letter. The first character shall be a letter. The implementation may ignore the distinctions of alphabetical case and restrict the mapping to eight significant characters before the period.
Toutes les implémentations que je connais vont bien au delà.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Christophe Lephay
wrote:
"Christophe Lephay" wrote in message news:<bo6ap0$8aq$...
Du reste, sans savoir ce que dit la norme, je suis bien certain qu'elle n'impose pas une extension de fichier particulier (en dehors de ce que C impose). Mais quelqu'un confirmera (ou infirmera) le cas échéant...
La norme (C) dit que l'instruction #include est remplacée par « the entire contents of the source file identified » (en cas de "...") ou par « the entire contents of the header » (cas de <...>).
Et laisse-t-elle la même liberté aux autres fichiers (je parle des fichiers contenant les implémentations, les .c typiquement) ?
personnellement, je n'en vois pas vraiment l'intérêt, mais on sait jamais, et ma curiosité me pousse à savoir :)
Chris
kanze@gabi-soft.fr wrote:
"Christophe Lephay" <christophe-lephay@wanadoo.fr> wrote in message
news:<bo6ap0$8aq$1@news-reader2.wanadoo.fr>...
Du reste, sans savoir ce que dit la norme, je suis bien certain
qu'elle n'impose pas une extension de fichier particulier (en dehors
de ce que C impose). Mais quelqu'un confirmera (ou infirmera) le cas
échéant...
La norme (C) dit que l'instruction #include est remplacée par « the
entire contents of the source file identified » (en cas de "...") ou
par « the entire contents of the header » (cas de <...>).
Et laisse-t-elle la même liberté aux autres fichiers (je parle des fichiers
contenant les implémentations, les .c typiquement) ?
personnellement, je n'en vois pas vraiment l'intérêt, mais on sait jamais,
et ma curiosité me pousse à savoir :)
"Christophe Lephay" wrote in message news:<bo6ap0$8aq$...
Du reste, sans savoir ce que dit la norme, je suis bien certain qu'elle n'impose pas une extension de fichier particulier (en dehors de ce que C impose). Mais quelqu'un confirmera (ou infirmera) le cas échéant...
La norme (C) dit que l'instruction #include est remplacée par « the entire contents of the source file identified » (en cas de "...") ou par « the entire contents of the header » (cas de <...>).
Et laisse-t-elle la même liberté aux autres fichiers (je parle des fichiers contenant les implémentations, les .c typiquement) ?
personnellement, je n'en vois pas vraiment l'intérêt, mais on sait jamais, et ma curiosité me pousse à savoir :)
Chris
Fabien LE LEZ
On Tue, 4 Nov 2003 12:33:35 +0100, "Christophe Lephay" wrote:
La norme (C) dit que l'instruction #include est remplacée par « the entire contents of the source file identified » (en cas de "...") ou par « the entire contents of the header » (cas de <...>).
Et laisse-t-elle la même liberté aux autres fichiers (je parle des fichiers contenant les implémentations, les .c typiquement) ?
Il me semble normal que la norme parle du fonctionnement de #include, puisqu'il s'agit d'une fonctionnalité du langage (si on admet que le préprocesseur fait partie du langage ;-) ). Pour les noms des fichiers .cpp, à partir du moment où ils ne sont pas "#inclus" dans d'autres fichiers, la norme n'a AMHA pas de raison d'en parler.
-- ;-)
On Tue, 4 Nov 2003 12:33:35 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
La norme (C) dit que l'instruction #include est remplacée par « the
entire contents of the source file identified » (en cas de "...") ou
par « the entire contents of the header » (cas de <...>).
Et laisse-t-elle la même liberté aux autres fichiers (je parle des fichiers
contenant les implémentations, les .c typiquement) ?
Il me semble normal que la norme parle du fonctionnement de #include,
puisqu'il s'agit d'une fonctionnalité du langage (si on admet que le
préprocesseur fait partie du langage ;-) ). Pour les noms des fichiers
.cpp, à partir du moment où ils ne sont pas "#inclus" dans d'autres
fichiers, la norme n'a AMHA pas de raison d'en parler.
On Tue, 4 Nov 2003 12:33:35 +0100, "Christophe Lephay" wrote:
La norme (C) dit que l'instruction #include est remplacée par « the entire contents of the source file identified » (en cas de "...") ou par « the entire contents of the header » (cas de <...>).
Et laisse-t-elle la même liberté aux autres fichiers (je parle des fichiers contenant les implémentations, les .c typiquement) ?
Il me semble normal que la norme parle du fonctionnement de #include, puisqu'il s'agit d'une fonctionnalité du langage (si on admet que le préprocesseur fait partie du langage ;-) ). Pour les noms des fichiers .cpp, à partir du moment où ils ne sont pas "#inclus" dans d'autres fichiers, la norme n'a AMHA pas de raison d'en parler.
-- ;-)
Fabien LE LEZ
On 4 Nov 2003 03:07:30 -0800, wrote:
Les seules variations que je connais, c'est en ce qui concerne l'interprétation des caractères échappés ('', etc.).
Sans oublier le fait que Windows accepte la convention Unix pour les chemins (avec le /) en plus de sa propre convention ()/
-- ;-)
On 4 Nov 2003 03:07:30 -0800, kanze@gabi-soft.fr wrote:
Les
seules variations que je connais, c'est en ce qui concerne
l'interprétation des caractères échappés ('\', etc.).
Sans oublier le fait que Windows accepte la convention Unix pour les
chemins (avec le /) en plus de sa propre convention ()/
Les seules variations que je connais, c'est en ce qui concerne l'interprétation des caractères échappés ('', etc.).
Sans oublier le fait que Windows accepte la convention Unix pour les chemins (avec le /) en plus de sa propre convention ()/
-- ;-)
delta
a écrit dans le message de news:
Les compilateurs que je connais (y compris VC++ sous Windows) ne font pas de « défaut » -- je choisis le nom que je veux dans l'éditeur. Le seul « défaut », éventuellement, ce sont les noms des fichiers d'en-tête fournis avec le compilateur.
Tous les projets sur lesquels j'ai travaillé se sont servi de .cc et de .hh. Sans problèmes, y compris avec VC++ sous Windows.
Mince alors. Lorsque je batis un projet, sous .net 7.1 compose uniquement de sources d extension .cc tout se passe comme si VS ne reconnaissait pas le fichier comme une source c++ (j avoue que je ne me souviens pas du comportement des editions precedentes). D ailleurs j ai pose la question sur microsoft.public.fr.dotnet.c ; a ce jour, elle est restee sans reponse. En tout cas, je n ai toujours pas trouve l option qui va bien. En passant, si vous avez une suggestion ...
Je travaille en fait surtout dans le monde des Unix ; je me sers donc de .hh et de .cc.
Ceci explique peut-etre cela.
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0311040307.6bfd86cb@posting.google.com...
Les compilateurs que je connais (y compris VC++ sous Windows) ne font
pas de « défaut » -- je choisis le nom que je veux dans l'éditeur. Le
seul « défaut », éventuellement, ce sont les noms des fichiers d'en-tête
fournis avec le compilateur.
Tous les projets sur lesquels j'ai travaillé se sont servi de .cc et de
.hh. Sans problèmes, y compris avec VC++ sous Windows.
Mince alors. Lorsque je batis un projet, sous .net 7.1
compose uniquement de sources d extension .cc tout
se passe comme si VS ne reconnaissait pas le fichier
comme une source c++ (j avoue que je ne me souviens pas
du comportement des editions precedentes).
D ailleurs j ai pose la question sur microsoft.public.fr.dotnet.c ;
a ce jour, elle est restee sans reponse. En tout cas, je n ai
toujours pas trouve l option qui va bien. En passant, si vous
avez une suggestion ...
Je travaille en fait surtout dans le monde des Unix ; je me
sers donc de .hh et de .cc.
Les compilateurs que je connais (y compris VC++ sous Windows) ne font pas de « défaut » -- je choisis le nom que je veux dans l'éditeur. Le seul « défaut », éventuellement, ce sont les noms des fichiers d'en-tête fournis avec le compilateur.
Tous les projets sur lesquels j'ai travaillé se sont servi de .cc et de .hh. Sans problèmes, y compris avec VC++ sous Windows.
Mince alors. Lorsque je batis un projet, sous .net 7.1 compose uniquement de sources d extension .cc tout se passe comme si VS ne reconnaissait pas le fichier comme une source c++ (j avoue que je ne me souviens pas du comportement des editions precedentes). D ailleurs j ai pose la question sur microsoft.public.fr.dotnet.c ; a ce jour, elle est restee sans reponse. En tout cas, je n ai toujours pas trouve l option qui va bien. En passant, si vous avez une suggestion ...
Je travaille en fait surtout dans le monde des Unix ; je me sers donc de .hh et de .cc.
