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?
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.
Tout à fait. La norme est intentionnellement silent pour tout ce qui concerne comment on compile un programme -- rien sur les options de compilation, l'invocation de l'éditeur de liens, comment spécifier quelles modules font partie du programme, etc.
-- 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
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<nq5fqvslacguh98fptbqo9l7lic8p91t5d@4ax.com>...
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.
Tout à fait. La norme est intentionnellement silent pour tout ce qui
concerne comment on compile un programme -- rien sur les options de
compilation, l'invocation de l'éditeur de liens, comment spécifier
quelles modules font partie du programme, etc.
--
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
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.
Tout à fait. La norme est intentionnellement silent pour tout ce qui concerne comment on compile un programme -- rien sur les options de compilation, l'invocation de l'éditeur de liens, comment spécifier quelles modules font partie du programme, etc.
-- 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
Fabien LE LEZ wrote in message news:...
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 ()/
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque chose comme :
#include "xnynz"
-- 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
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<ot8fqvo9kh3090662kplo0qlhfj1j8ut72@4ax.com>...
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 ()/
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque
chose comme :
#include "xnynz"
--
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
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 ()/
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque chose comme :
#include "xnynz"
-- 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
"delta" wrote in message news:...
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).
C'est l'option /Tp qui lui dit que le fichier suivant contient du C++.
D'autres compilateurs ont d'autres options ; « -x c++ » pour g++, par exemple (mais je ne m'en sers pas, parce que g++ fait du C++ implicitement si le nom du fichier termine par .cc).
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 ...
Ce que j'ai donné ci-dessus, c'est pour VC++ 6.0, mais j'imagine que ça n'a pas changé. (Note cependant que c'est du GNU make, et non le nmake du VC++. Faire des fichiers make portable, c'est encore plus difficile que de faire du C++ portable, et puisqu'il est facile à installer GNU make partout...)
Je travaille en fait surtout dans le monde des Unix ; je me sers donc de .hh et de .cc.
Ceci explique peut-etre cela.
Sans doute. J'ai encore une bibliothèque ultra-vieille chez moi que j'ai développé sous Zortech, avant d'utiliser C++ professionnellement. Avec .hpp et .cpp. Ce sont mes clients qui se servaient de .hh et de .cc ; je me conforme aux désirs du client. Maintenant, évidemment, c'est devenu aussi naturel que c'est ce que je fais sous Windows aussi.
-- 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
"delta" <singularcusp@yahoo.fr> wrote in message
news:<bo897c02c1l@enews4.newsguy.com>...
<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).
C'est l'option /Tp qui lui dit que le fichier suivant contient du C++.
D'autres compilateurs ont d'autres options ; « -x c++ » pour g++, par
exemple (mais je ne m'en sers pas, parce que g++ fait du C++
implicitement si le nom du fichier termine par .cc).
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 ...
Ce que j'ai donné ci-dessus, c'est pour VC++ 6.0, mais j'imagine que
ça
n'a pas changé. (Note cependant que c'est du GNU make, et non le nmake
du VC++. Faire des fichiers make portable, c'est encore plus difficile
que de faire du C++ portable, et puisqu'il est facile à installer GNU
make partout...)
Je travaille en fait surtout dans le monde des Unix ; je me sers
donc de .hh et de .cc.
Ceci explique peut-etre cela.
Sans doute. J'ai encore une bibliothèque ultra-vieille chez moi que
j'ai
développé sous Zortech, avant d'utiliser C++ professionnellement. Avec
.hpp et .cpp. Ce sont mes clients qui se servaient de .hh et de .cc ;
je
me conforme aux désirs du client. Maintenant, évidemment, c'est devenu
aussi naturel que c'est ce que je fais sous Windows aussi.
--
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
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).
C'est l'option /Tp qui lui dit que le fichier suivant contient du C++.
D'autres compilateurs ont d'autres options ; « -x c++ » pour g++, par exemple (mais je ne m'en sers pas, parce que g++ fait du C++ implicitement si le nom du fichier termine par .cc).
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 ...
Ce que j'ai donné ci-dessus, c'est pour VC++ 6.0, mais j'imagine que ça n'a pas changé. (Note cependant que c'est du GNU make, et non le nmake du VC++. Faire des fichiers make portable, c'est encore plus difficile que de faire du C++ portable, et puisqu'il est facile à installer GNU make partout...)
Je travaille en fait surtout dans le monde des Unix ; je me sers donc de .hh et de .cc.
Ceci explique peut-etre cela.
Sans doute. J'ai encore une bibliothèque ultra-vieille chez moi que j'ai développé sous Zortech, avant d'utiliser C++ professionnellement. Avec .hpp et .cpp. Ce sont mes clients qui se servaient de .hh et de .cc ; je me conforme aux désirs du client. Maintenant, évidemment, c'est devenu aussi naturel que c'est ce que je fais sous Windows aussi.
-- 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
Fabien LE LEZ
On 4 Nov 2003 10:00:04 -0800, wrote:
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque chose comme :
#include "xnynz"
De quelle façon un compilateur pourrait interpréter ce genre de caractères ?
-- ;-)
On 4 Nov 2003 10:00:04 -0800, kanze@gabi-soft.fr wrote:
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque
chose comme :
#include "xnynz"
De quelle façon un compilateur pourrait interpréter ce genre de
caractères ?
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.
Vraiment James, t'es un original ou un malchanceux :-)
(Par défaut, .cc et .hpp sont reconnus -- en plus de .c, .cpp et .h bien entendu --, mais pas hh...)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Jean-Marc Bourguet
Fabien LE LEZ writes:
On 4 Nov 2003 10:00:04 -0800, wrote:
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque chose comme :
#include "xnynz"
De quelle façon un compilateur pourrait interpréter ce genre de caractères ?
Est-ce que "n" designe deux caracteres ou un seul comme dans les chaines (ce dernier etant generalement un caractere possible, mais peu employe, dans les noms de fichiers sous Unix)?
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
Fabien LE LEZ <gramster@gramster.com> writes:
On 4 Nov 2003 10:00:04 -0800, kanze@gabi-soft.fr wrote:
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque
chose comme :
#include "xnynz"
De quelle façon un compilateur pourrait interpréter ce genre de
caractères ?
Est-ce que "n" designe deux caracteres ou un seul comme dans les
chaines (ce dernier etant generalement un caractere possible, mais peu
employe, dans les noms de fichiers sous Unix)?
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
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque chose comme :
#include "xnynz"
De quelle façon un compilateur pourrait interpréter ce genre de caractères ?
Est-ce que "n" designe deux caracteres ou un seul comme dans les chaines (ce dernier etant generalement un caractere possible, mais peu employe, dans les noms de fichiers sous Unix)?
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
delta
"Michel Michaud" a écrit dans le message de news:MVYpb.18581$
Dans news:,
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.
Vraiment James, t'es un original ou un malchanceux :-)
(Par défaut, .cc et .hpp sont reconnus -- en plus de .c, .cpp et .h bien entendu --, mais pas hh...)
Michel, j insiste ... mais ca m interesse et m intrigue. Les .cc sont ils reconnus dans la version 7.1 (2003) de VS ?
Merci.
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:MVYpb.18581$mB5.618602@news20.bellglobal.com...
Dans news:d6652001.0311040307.6bfd86cb@posting.google.com,
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.
Vraiment James, t'es un original ou un malchanceux :-)
(Par défaut, .cc et .hpp sont reconnus -- en plus de .c, .cpp et .h
bien entendu --, mais pas hh...)
Michel, j insiste ... mais ca m interesse et m intrigue. Les .cc sont ils
reconnus dans la version 7.1 (2003) de VS ?
"Michel Michaud" a écrit dans le message de news:MVYpb.18581$
Dans news:,
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.
Vraiment James, t'es un original ou un malchanceux :-)
(Par défaut, .cc et .hpp sont reconnus -- en plus de .c, .cpp et .h bien entendu --, mais pas hh...)
Michel, j insiste ... mais ca m interesse et m intrigue. Les .cc sont ils reconnus dans la version 7.1 (2003) de VS ?
Merci.
delta
a écrit dans le message de news:
"delta" wrote in message news:...
a écrit dans le message de news:
Il faut lui le dire. Dans mon makefile, j'ai :
Tes efforts de portabilite sont louables et l on en saisit vite la substance lorsque l on a travaille sur un projet multi plateforme. Cependant, cela me parait hallucinant. Ne penses tu pas qu il devrait exister un moyen dans l ide de VS pour parametrer ceci sans avoir recours a un make externe ?
Ce que j'ai donné ci-dessus, c'est pour VC++ 6.0, mais j'imagine que ça n'a pas changé. (Note cependant que c'est du GNU make, et non le nmake du VC++. Faire des fichiers make portable, c'est encore plus difficile que de faire du C++ portable, et puisqu'il est facile à installer GNU make partout...)
Peut-etre je ne sais pas, je n utilise pas de makefile (dans sa signification la plus proche de GNU). L operation d export sous makefile n est plus au menu de VS 2003 par exemple. Il y a peut etre d autres fonctionnalites connexes qui ont elles aussi disparues.
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0311041013.4f343010@posting.google.com...
"delta" <singularcusp@yahoo.fr> wrote in message
news:<bo897c02c1l@enews4.newsguy.com>...
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0311040307.6bfd86cb@posting.google.com...
Il faut lui le dire. Dans mon makefile, j'ai :
Tes efforts de portabilite sont louables et l on en saisit vite la
substance lorsque l on a travaille sur un projet multi plateforme.
Cependant, cela me parait hallucinant. Ne penses tu pas qu il
devrait exister un moyen dans l ide de VS pour parametrer ceci
sans avoir recours a un make externe ?
Ce que j'ai donné ci-dessus, c'est pour VC++ 6.0, mais j'imagine que
ça
n'a pas changé. (Note cependant que c'est du GNU make, et non le nmake
du VC++. Faire des fichiers make portable, c'est encore plus difficile
que de faire du C++ portable, et puisqu'il est facile à installer GNU
make partout...)
Peut-etre je ne sais pas, je n utilise pas de makefile (dans sa
signification
la plus proche de GNU). L operation d export sous makefile n est plus au
menu de VS 2003 par exemple. Il y a peut etre d autres fonctionnalites
connexes qui ont elles aussi disparues.
Tes efforts de portabilite sont louables et l on en saisit vite la substance lorsque l on a travaille sur un projet multi plateforme. Cependant, cela me parait hallucinant. Ne penses tu pas qu il devrait exister un moyen dans l ide de VS pour parametrer ceci sans avoir recours a un make externe ?
Ce que j'ai donné ci-dessus, c'est pour VC++ 6.0, mais j'imagine que ça n'a pas changé. (Note cependant que c'est du GNU make, et non le nmake du VC++. Faire des fichiers make portable, c'est encore plus difficile que de faire du C++ portable, et puisqu'il est facile à installer GNU make partout...)
Peut-etre je ne sais pas, je n utilise pas de makefile (dans sa signification la plus proche de GNU). L operation d export sous makefile n est plus au menu de VS 2003 par exemple. Il y a peut etre d autres fonctionnalites connexes qui ont elles aussi disparues.
kanze
Jean-Marc Bourguet wrote in message news:...
Fabien LE LEZ writes:
On 4 Nov 2003 10:00:04 -0800, wrote:
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque chose comme :
#include "xnynz"
De quelle façon un compilateur pourrait interpréter ce genre de caractères ?
Est-ce que "n" designe deux caracteres ou un seul comme dans les chaines (ce dernier etant generalement un caractere possible, mais peu employe, dans les noms de fichiers sous Unix)?
Que ce soit g++ ou Sun CC, j'avais le message d'erreur : « fichier d'inclusion "xnynz" non trouvé », alors que je venais d'executer le programme suivant :
#include <ostream> #include <fstream>
int main() { std::ofstream o( "xnynz" ) ; o << "int xyz ;n" ; return 0 ; }
Un include avec exactement la même chaîne de caractère donne : "m2.cc", line 2: Error: Could not open include file "xnynz". ou m2.cc:2:19: xnynz: No such file or directory selon le compilateur.
Sous Windows (VC++ 6.0), la création du fichier n'a pas marché.
-- 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
Jean-Marc Bourguet <jm@bourguet.org> wrote in message
news:<pxbad7bcll9.fsf@news.bourguet.org>...
Fabien LE LEZ <gramster@gramster.com> writes:
On 4 Nov 2003 10:00:04 -0800, kanze@gabi-soft.fr wrote:
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque
chose comme :
#include "xnynz"
De quelle façon un compilateur pourrait interpréter ce genre de
caractères ?
Est-ce que "n" designe deux caracteres ou un seul comme dans les
chaines (ce dernier etant generalement un caractere possible, mais peu
employe, dans les noms de fichiers sous Unix)?
Que ce soit g++ ou Sun CC, j'avais le message d'erreur : « fichier
d'inclusion "xnynz" non trouvé », alors que je venais d'executer le
programme suivant :
#include <ostream>
#include <fstream>
int
main()
{
std::ofstream o( "xnynz" ) ;
o << "int xyz ;n" ;
return 0 ;
}
Un include avec exactement la même chaîne de caractère donne :
"m2.cc", line 2: Error: Could not open include file "xnynz".
ou
m2.cc:2:19: xnynz: No such file or directory
selon le compilateur.
Sous Windows (VC++ 6.0), la création du fichier n'a pas marché.
--
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
Et que ni g++ ni Sun CC n'interprète des trucs comme 'n' dans quelque chose comme :
#include "xnynz"
De quelle façon un compilateur pourrait interpréter ce genre de caractères ?
Est-ce que "n" designe deux caracteres ou un seul comme dans les chaines (ce dernier etant generalement un caractere possible, mais peu employe, dans les noms de fichiers sous Unix)?
Que ce soit g++ ou Sun CC, j'avais le message d'erreur : « fichier d'inclusion "xnynz" non trouvé », alors que je venais d'executer le programme suivant :
#include <ostream> #include <fstream>
int main() { std::ofstream o( "xnynz" ) ; o << "int xyz ;n" ; return 0 ; }
Un include avec exactement la même chaîne de caractère donne : "m2.cc", line 2: Error: Could not open include file "xnynz". ou m2.cc:2:19: xnynz: No such file or directory selon le compilateur.
Sous Windows (VC++ 6.0), la création du fichier n'a pas marché.
-- 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
"Michel Michaud" wrote in message news:<MVYpb.18581$...
Dans news:,
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.
Vraiment James, t'es un original ou un malchanceux :-)
Malchanceux, parce que je dois travailler sur une vraie machine plutôt que sur un jouet :-) ? Je ne suis pas tellement d'accord.
(Par défaut, .cc et .hpp sont reconnus -- en plus de .c, .cpp et .h bien entendu --, mais pas hh...)
???
Avec VC++ 6.0, si je ne donne pas l'option /Tp (ou /TP), j'ai l'erreur :
unrecognized source file type 'main.cc', object file assumed
suivi d'une erreur de l'éditeur de liens
invalid or corrupt file
Je n'ai pas l'impression qu'il a reconnu .cc comme une source C++ par défaut. Pareil pour .h et .hpp. Et .c est traité comme une source C, non une source C++ (ce qui me semble normal, mais tu sembles dire le contraire).
Étant donné que .cc est quand même assez répandu, ça serait net qu'il l'ajoute à la liste des extensions C++. Mais enfin, pour avoir un compilateur C++, il faut bien déjà les options /GX et /GR ; ajouter un /Tp en plus ne me gène donc pas outremésure.
-- 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
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<MVYpb.18581$mB5.618602@news20.bellglobal.com>...
Dans news:d6652001.0311040307.6bfd86cb@posting.google.com,
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.
Vraiment James, t'es un original ou un malchanceux :-)
Malchanceux, parce que je dois travailler sur une vraie machine plutôt
que sur un jouet :-) ? Je ne suis pas tellement d'accord.
(Par défaut, .cc et .hpp sont reconnus -- en plus de .c, .cpp et .h
bien entendu --, mais pas hh...)
???
Avec VC++ 6.0, si je ne donne pas l'option /Tp (ou /TP), j'ai l'erreur :
unrecognized source file type 'main.cc', object file assumed
suivi d'une erreur de l'éditeur de liens
invalid or corrupt file
Je n'ai pas l'impression qu'il a reconnu .cc comme une source C++ par
défaut. Pareil pour .h et .hpp. Et .c est traité comme une source C, non
une source C++ (ce qui me semble normal, mais tu sembles dire le
contraire).
Étant donné que .cc est quand même assez répandu, ça serait net qu'il
l'ajoute à la liste des extensions C++. Mais enfin, pour avoir un
compilateur C++, il faut bien déjà les options /GX et /GR ; ajouter un
/Tp en plus ne me gène donc pas outremésure.
--
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
"Michel Michaud" wrote in message news:<MVYpb.18581$...
Dans news:,
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.
Vraiment James, t'es un original ou un malchanceux :-)
Malchanceux, parce que je dois travailler sur une vraie machine plutôt que sur un jouet :-) ? Je ne suis pas tellement d'accord.
(Par défaut, .cc et .hpp sont reconnus -- en plus de .c, .cpp et .h bien entendu --, mais pas hh...)
???
Avec VC++ 6.0, si je ne donne pas l'option /Tp (ou /TP), j'ai l'erreur :
unrecognized source file type 'main.cc', object file assumed
suivi d'une erreur de l'éditeur de liens
invalid or corrupt file
Je n'ai pas l'impression qu'il a reconnu .cc comme une source C++ par défaut. Pareil pour .h et .hpp. Et .c est traité comme une source C, non une source C++ (ce qui me semble normal, mais tu sembles dire le contraire).
Étant donné que .cc est quand même assez répandu, ça serait net qu'il l'ajoute à la liste des extensions C++. Mais enfin, pour avoir un compilateur C++, il faut bien déjà les options /GX et /GR ; ajouter un /Tp en plus ne me gène donc pas outremésure.
-- 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
