Extensions de fichiers

Fabien LE LEZ

06/11/2003 à 04:41

On Wed, 5 Nov 2003 21:52:33 -0500, "Michel Michaud"
wrote:

Tu connais l'expression « s'enfarger dans les fleurs du tapis » ? :-)

C'est une expression québéquoise ? Je n'ai pas trouvé le mot
"enfarger" dans mon dico...

--
;-)

Michel Michaud

06/11/2003 à 05:06

Dans news:, Fabien LE

On Wed, 5 Nov 2003 21:52:33 -0500, "Michel Michaud"
wrote:

Tu connais l'expression « s'enfarger dans les fleurs du tapis » ?
:-)

C'est une expression québéquoise ? Je n'ai pas trouvé le mot
"enfarger" dans mon dico...

Oui et non. C'est encore utilisé au Québec, mais c'est un vieux
verbe français. Mauvais dico, changer de dico ? (je n'ai que
deux dictionnaires qui en parlent, c'est peu quand même).

Disons qu'on peut remplacer par « s'accrocher les pieds ».
J'avais mis enfarger intentionnellement pour donner un peu
de culture internationale à ceux qui lisent ici :-).

L'expression sous une forme ou une autre est-elle connue ?

Mon Robert Dictionnaire québécois d'aujourd'hui indique :
« Rencontrer de faux obstacles, de faux problèmes, de fausses
difficultés. ». En ce sens, s'enfarger est un peu comme
s'empêtrer (mais ce n'est pas un « beau » mot).

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Fabien LE LEZ

06/11/2003 à 05:24

On Wed, 5 Nov 2003 23:06:51 -0500, "Michel Michaud"
wrote:

mais c'est un vieux
verbe français. Mauvais dico, changer de dico ?

Yep, le Petit Larousse n'est pas génial pour le vieux françois. Et
pour le récent non plus, d'ailleurs, puisque le mien date de 1995 ;-)

L'expression sous une forme ou une autre est-elle connue ?

Maintenant que tu me l'as expliquée, je crois avoir entendu quelque
chose d'approchant. Mais pour la culture littéraire, c'est pas à moi
qu'il faut s'adresser -- surtout si ça date d'avant le XXè siècle ;-/

--
;-)

delta

06/11/2003 à 08:42

"Michel Michaud" a écrit dans le message de
news:SHiqb.6401$

Dans news:,
Ben non, je n ai pas l icone C++ sur le fichier ds l explorateur de
solution

Bof... (j'imagine qu'on peut changer ça)

Ben certainement, ce serait mieux mais je peux vivre sans :-)
Evidemment, si tu sais, dis moi, je modifierai cette configuration.
Ceci me rappelle la phrase de Bellamy : en informatique, tout
est possible ... mais ce n est pas toujours evident :-)
Par contre, une reponse definitive a la question intiale
m interesse tjs. Bref.

(cependant, il apparait ds l explorateur windows) et pas
de dossier C/C++ ds les proprietes du projet (?!). Evidemment, des

Tu peux créer tous les dossiers que tu veux...

Je ne vois pas le rapport. Parle t on bien du "dossier" C/C++
cree par defaut dans lequel on configure les proprietes "C/C++"
du projet ? Si tu sais alors n hesites pas, et j espere bien
que l on peut changer cela (c est ce que je me suis dit ...
avant d essayer :-) mais je n ai pas trouve ou.

que j ai un .cpp, ce dossier
apparait. Du coup, je suis oblige de renommer l un des .cc en .cpp.

Plus facile de créer un dossier et d'y mettre ce que tu veux...

J avoue que je n ai pas ton experience. De sorte que je ne
comprends pas tes conseils.

Et effectivement, il compile le projet ds son integralite, et l on
peut manipuler les fichiers a son gre.

C est bete mais ca me gene.

Tu connais l'expression « s'enfarger dans les fleurs du tapis » ? :-)

Non je ne connais pas. Neanmoins, sans etre mechante, j imagine que
cette expression n est pas particulierement flatteuse a mon egard.

Enfin, j avais prevenu pour le HS (precisant par ailleurs le groupe
microsoft sur lequel j avais pose la question, au cas ou des experts
auraient souhaite me repondre ds un groupe dedie ;-)
Cependant, de mon petit point de vue, le compilateur c++ de VS2003
a fait bcp de progres en terme d adhesion a la norme, il supporte
par exemple les specialisations partielles de modele (que ne supportait
pas la version 2002). Que l interface me cause des soucis avec des
extensions .cc m etonne quelque peu.

"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:SHiqb.6401$Pg1.347500@news20.bellglobal.com...

Dans news:bobblg03036@enews2.newsguy.com,

Ben non, je n ai pas l icone C++ sur le fichier ds l explorateur de
solution

Bof... (j'imagine qu'on peut changer ça)

Ben certainement, ce serait mieux mais je peux vivre sans :-)
Evidemment, si tu sais, dis moi, je modifierai cette configuration.
Ceci me rappelle la phrase de Bellamy : en informatique, tout
est possible ... mais ce n est pas toujours evident :-)
Par contre, une reponse definitive a la question intiale
m interesse tjs. Bref.

(cependant, il apparait ds l explorateur windows) et pas
de dossier C/C++ ds les proprietes du projet (?!). Evidemment, des

Tu peux créer tous les dossiers que tu veux...

Je ne vois pas le rapport. Parle t on bien du "dossier" C/C++
cree par defaut dans lequel on configure les proprietes "C/C++"
du projet ? Si tu sais alors n hesites pas, et j espere bien
que l on peut changer cela (c est ce que je me suis dit ...
avant d essayer :-) mais je n ai pas trouve ou.

que j ai un .cpp, ce dossier
apparait. Du coup, je suis oblige de renommer l un des .cc en .cpp.

Plus facile de créer un dossier et d'y mettre ce que tu veux...

J avoue que je n ai pas ton experience. De sorte que je ne
comprends pas tes conseils.

Et effectivement, il compile le projet ds son integralite, et l on
peut manipuler les fichiers a son gre.

C est bete mais ca me gene.

Tu connais l'expression « s'enfarger dans les fleurs du tapis » ? :-)

Non je ne connais pas. Neanmoins, sans etre mechante, j imagine que
cette expression n est pas particulierement flatteuse a mon egard.

Enfin, j avais prevenu pour le HS (precisant par ailleurs le groupe
microsoft sur lequel j avais pose la question, au cas ou des experts
auraient souhaite me repondre ds un groupe dedie ;-)
Cependant, de mon petit point de vue, le compilateur c++ de VS2003
a fait bcp de progres en terme d adhesion a la norme, il supporte
par exemple les specialisations partielles de modele (que ne supportait
pas la version 2002). Que l interface me cause des soucis avec des
extensions .cc m etonne quelque peu.

Vous avez filtré cet utilisateur ! Consultez son message

"Michel Michaud" a écrit dans le message de
news:SHiqb.6401$

Dans news:,
Ben non, je n ai pas l icone C++ sur le fichier ds l explorateur de
solution

Bof... (j'imagine qu'on peut changer ça)

Ben certainement, ce serait mieux mais je peux vivre sans :-)
Evidemment, si tu sais, dis moi, je modifierai cette configuration.
Ceci me rappelle la phrase de Bellamy : en informatique, tout
est possible ... mais ce n est pas toujours evident :-)
Par contre, une reponse definitive a la question intiale
m interesse tjs. Bref.

(cependant, il apparait ds l explorateur windows) et pas
de dossier C/C++ ds les proprietes du projet (?!). Evidemment, des

Tu peux créer tous les dossiers que tu veux...

Je ne vois pas le rapport. Parle t on bien du "dossier" C/C++
cree par defaut dans lequel on configure les proprietes "C/C++"
du projet ? Si tu sais alors n hesites pas, et j espere bien
que l on peut changer cela (c est ce que je me suis dit ...
avant d essayer :-) mais je n ai pas trouve ou.

que j ai un .cpp, ce dossier
apparait. Du coup, je suis oblige de renommer l un des .cc en .cpp.

Plus facile de créer un dossier et d'y mettre ce que tu veux...

J avoue que je n ai pas ton experience. De sorte que je ne
comprends pas tes conseils.

Et effectivement, il compile le projet ds son integralite, et l on
peut manipuler les fichiers a son gre.

C est bete mais ca me gene.

Tu connais l'expression « s'enfarger dans les fleurs du tapis » ? :-)

Non je ne connais pas. Neanmoins, sans etre mechante, j imagine que
cette expression n est pas particulierement flatteuse a mon egard.

Enfin, j avais prevenu pour le HS (precisant par ailleurs le groupe
microsoft sur lequel j avais pose la question, au cas ou des experts
auraient souhaite me repondre ds un groupe dedie ;-)
Cependant, de mon petit point de vue, le compilateur c++ de VS2003
a fait bcp de progres en terme d adhesion a la norme, il supporte
par exemple les specialisations partielles de modele (que ne supportait
pas la version 2002). Que l interface me cause des soucis avec des
extensions .cc m etonne quelque peu.

kanze

06/11/2003 à 09:19

Fabien LE LEZ wrote in message
news:...

On 5 Nov 2003 02:10:35 -0800, wrote:

Un include avec exactement la même chaîne de caractère donne :
"m2.cc", line 2: Error: Could not open include file "xnynz".

Que donne un ls ?

Gabi (45): ls
a.out m2.cc main.cc x
y
z
Gabi (50): ls | xd
xd: cannot do binary input on standard in
000000: 61 2E 6F 75 74 0A 6D 32 2E 63 63 0A 6D 61 69 6E |a.out m2.cc main|
000010: 2E 63 63 0A 78 0A 79 0A 7A 0A |.cc x y z |

(Pour xd, voir à ma site. J'en trouve la sortie bien plus lisible que
tout ce que j'arrive à faire avec od.)

Les 'n' y sont bien.

Et en passant (mais la question convient plutôt à fr.comp.os.unix),
quand est-ce que ls a cessé de convertir des caractères non imprimable
en '?' quand la sortie était un tty ?

--
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

06/11/2003 à 09:26

"delta" wrote in message
news:...

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 ?

Aucune idée, mais je le doute.

En passant, je n'utilise pas l'IDE de MS. Ma plateforme principale reste
une machine Unix (Sun Sparc sous Solaris) -- l'utilisation de VC++ est
une porte. Et sous Windows, j'utilise le même environement que sous
Solaris : emacs avec CygWin. C'est aussi une espèce de portabilité : je
n'ai pas besoin de tout réapprendre chaque fois que je change de
machine.

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).

C'est un boulot en plus, c'est sûr. Mais ce n'est pas un boulot
énorme. Le temps que je passe à écrire des fichiers make n'est pas
mésurable devant la reste. Et la portabilité que je gagne en vaut la
peine.

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.

Comme j'ai dit, je ne connais pas l'IDE. Je ne m'en suis jamais servi.
(C'est plutôt une question d'habitude, je crois. Je ne me sers pas de
Forte sous Solaris non plus, bien qu'il soit installé ici.)

--
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:<boaagd02344@enews3.newsguy.com>...

<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 ?

Aucune idée, mais je le doute.

En passant, je n'utilise pas l'IDE de MS. Ma plateforme principale reste
une machine Unix (Sun Sparc sous Solaris) -- l'utilisation de VC++ est
une porte. Et sous Windows, j'utilise le même environement que sous
Solaris : emacs avec CygWin. C'est aussi une espèce de portabilité : je
n'ai pas besoin de tout réapprendre chaque fois que je change de
machine.

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).

C'est un boulot en plus, c'est sûr. Mais ce n'est pas un boulot
énorme. Le temps que je passe à écrire des fichiers make n'est pas
mésurable devant la reste. Et la portabilité que je gagne en vaut la
peine.

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.

Comme j'ai dit, je ne connais pas l'IDE. Je ne m'en suis jamais servi.
(C'est plutôt une question d'habitude, je crois. Je ne me sers pas de
Forte sous Solaris non plus, bien qu'il soit installé ici.)

--
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

Vous avez filtré cet utilisateur ! Consultez son message

"delta" wrote in message
news:...

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 ?

Aucune idée, mais je le doute.

En passant, je n'utilise pas l'IDE de MS. Ma plateforme principale reste
une machine Unix (Sun Sparc sous Solaris) -- l'utilisation de VC++ est
une porte. Et sous Windows, j'utilise le même environement que sous
Solaris : emacs avec CygWin. C'est aussi une espèce de portabilité : je
n'ai pas besoin de tout réapprendre chaque fois que je change de
machine.

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).

C'est un boulot en plus, c'est sûr. Mais ce n'est pas un boulot
énorme. Le temps que je passe à écrire des fichiers make n'est pas
mésurable devant la reste. Et la portabilité que je gagne en vaut la
peine.

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.

Comme j'ai dit, je ne connais pas l'IDE. Je ne m'en suis jamais servi.
(C'est plutôt une question d'habitude, je crois. Je ne me sers pas de
Forte sous Solaris non plus, bien qu'il soit installé ici.)

--
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

06/11/2003 à 09:33

"delta" wrote in message
news:...

"Christophe Lephay" a écrit dans le message
de news:boapav$u9i$

La manip devrait ressembler à un truc du style Projet - Ajouter
Fichier (je n'ai pas de VC++ 7 sous la main)...

Ce n est pas l operation ajouter qui me pose probleme ni mm la
compilation qui s effectue correctement, a priori. Par contre, lorsque
je construits un projet qui possede uniquement des sources .cc (les
entetes etaient soient sans extension, soit en .h) avec VS 7.1, il me
manque un dossier C/C++ ds l explorateur de solution, clic droit
proprietes du projet.

Mais si tu travailles dans l'environement complètement Microsoft, avec
l'IDE et tout, pourquoi s'emmerdait. Moi, j'utilise .cc parce que c'est
ce qu'a toujours fait mes clients. Et ça marche bien pour moi parce que
ma plateforme principale a toujours été une variante d'Unix : Solaris,
HP/UX ou AIX. Quand je travaille sous Windows, c'est que je porte des
logiciels déjà écrits sous Unix, et je ne me sers pas de l'IDE.
J'installe CygWin et Emacs -- dans mon cas, je ne travaille pas
suffisamment sous Windows pour que ça vaut la peine d'apprendre
l'environnement propre, ni même de m'y adapter, dans la mésure que je
peux avoir l'environnement Unix complet.

Si Windows est une de tes plateformes principales, en revanche,
conforme-toi aux conventions qui y règnent. Tu ne gagneras jamais à
lutter contre l'environnement.

--
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

06/11/2003 à 09:59

"Michel Michaud" wrote in message
news:<aP8qb.6990$...

Dans news:,
"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.

Je voulais simplement dire malchanceux ou original, parce que sous
VC++ (surtout ancien) tout est mis en place pour que ce soit .cpp qui
soit le choix par défaut. C'est plus compliqué avec .cc, tu es donc
malchanceux d'avoir toujours eu à utiliser cc ! (d'accord, ce n'est
pas si compliqué que ça...)

Je crois que si j'étais réelement amené à développer sous Windows,
j'adopterai aussi .cpp. En fait, les seules fois que j'ai dû travailler
en C++ sous Windows, on développait sous Unix, puis on portait. Du coup,
on ne se servait pas de l'IDE de MS, ni des projets, ni de quoique ce
soit autre que cl, link et lib -- quand on a un projet qui marche sous
Unix, c'est beaucoup plus facile à installer CygWin et Emacs sous
Windows, et d'ajouter des options qu'il faut dans le fichier make. En
général, on a même pas converti les fins de lignes dans les fichiers --
cl, CygWin et Emacs acceptent très bien la convention Unix aussi.

En fait, ici c'est la première fois qu'on n'a pas simplement monté les
disques Unix sous Windows -- normalement, et les machines Unix et les
machines Windows voient exactement les mêmes fichiers. Dans les deux
cas, je travaille avec bash et emacs, et j'invoque make depuis la ligne
de commande. Dans les deux cas, j'ai des variables d'environnement que
make prend en compte :

arch=sparcv9 arch=i80x86
syst=solaris syst=win32
comp=suncc comp=vc60

Le résultat, c'est que je passe d'une plateforme à l'autre, sans
vraiment me rendre compte, et les modifications que je fais sous Windows
sont immédiatement répercutées sous Unix et vice-versa. (J'avais
toujours un serveur X sous Windows aussi. Ainsi, même quand je
travaillais sur la machine Windows, j'avais une ou deux fenêtres
ouvertes sur la machine Unix.)

Dans le cas des développements multi-plateforme, c'est la solution que
je préconciserai -- Windows a encore quelques années de rétard par
rapport aux systèmes Open Desktop en ce qui concerne la convivialité
pour un développeur (au moins pour un qui travaille dans une équipe).

Si je développais uniquement pour Windows, en revanche, je ne serais pas
aussi bête que de ne pas apprendre la façon Windows de faire des chose.
Et j'adoperais certainement .cpp et .hpp.

--
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:<aP8qb.6990$fg4.260435@news20.bellglobal.com>...

Dans news:d6652001.0311050220.6bdc9355@posting.google.com,

"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.

Je voulais simplement dire malchanceux ou original, parce que sous
VC++ (surtout ancien) tout est mis en place pour que ce soit .cpp qui
soit le choix par défaut. C'est plus compliqué avec .cc, tu es donc
malchanceux d'avoir toujours eu à utiliser cc ! (d'accord, ce n'est
pas si compliqué que ça...)

Je crois que si j'étais réelement amené à développer sous Windows,
j'adopterai aussi .cpp. En fait, les seules fois que j'ai dû travailler
en C++ sous Windows, on développait sous Unix, puis on portait. Du coup,
on ne se servait pas de l'IDE de MS, ni des projets, ni de quoique ce
soit autre que cl, link et lib -- quand on a un projet qui marche sous
Unix, c'est beaucoup plus facile à installer CygWin et Emacs sous
Windows, et d'ajouter des options qu'il faut dans le fichier make. En
général, on a même pas converti les fins de lignes dans les fichiers --
cl, CygWin et Emacs acceptent très bien la convention Unix aussi.

En fait, ici c'est la première fois qu'on n'a pas simplement monté les
disques Unix sous Windows -- normalement, et les machines Unix et les
machines Windows voient exactement les mêmes fichiers. Dans les deux
cas, je travaille avec bash et emacs, et j'invoque make depuis la ligne
de commande. Dans les deux cas, j'ai des variables d'environnement que
make prend en compte :

arch=sparcv9 arch=i80x86
syst=solaris syst=win32
comp=suncc comp=vc60

Le résultat, c'est que je passe d'une plateforme à l'autre, sans
vraiment me rendre compte, et les modifications que je fais sous Windows
sont immédiatement répercutées sous Unix et vice-versa. (J'avais
toujours un serveur X sous Windows aussi. Ainsi, même quand je
travaillais sur la machine Windows, j'avais une ou deux fenêtres
ouvertes sur la machine Unix.)

Dans le cas des développements multi-plateforme, c'est la solution que
je préconciserai -- Windows a encore quelques années de rétard par
rapport aux systèmes Open Desktop en ce qui concerne la convivialité
pour un développeur (au moins pour un qui travaille dans une équipe).

Si je développais uniquement pour Windows, en revanche, je ne serais pas
aussi bête que de ne pas apprendre la façon Windows de faire des chose.
Et j'adoperais certainement .cpp et .hpp.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

"Michel Michaud" wrote in message
news:<aP8qb.6990$...

Dans news:,
"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.

Je voulais simplement dire malchanceux ou original, parce que sous
VC++ (surtout ancien) tout est mis en place pour que ce soit .cpp qui
soit le choix par défaut. C'est plus compliqué avec .cc, tu es donc
malchanceux d'avoir toujours eu à utiliser cc ! (d'accord, ce n'est
pas si compliqué que ça...)

Je crois que si j'étais réelement amené à développer sous Windows,
j'adopterai aussi .cpp. En fait, les seules fois que j'ai dû travailler
en C++ sous Windows, on développait sous Unix, puis on portait. Du coup,
on ne se servait pas de l'IDE de MS, ni des projets, ni de quoique ce
soit autre que cl, link et lib -- quand on a un projet qui marche sous
Unix, c'est beaucoup plus facile à installer CygWin et Emacs sous
Windows, et d'ajouter des options qu'il faut dans le fichier make. En
général, on a même pas converti les fins de lignes dans les fichiers --
cl, CygWin et Emacs acceptent très bien la convention Unix aussi.

En fait, ici c'est la première fois qu'on n'a pas simplement monté les
disques Unix sous Windows -- normalement, et les machines Unix et les
machines Windows voient exactement les mêmes fichiers. Dans les deux
cas, je travaille avec bash et emacs, et j'invoque make depuis la ligne
de commande. Dans les deux cas, j'ai des variables d'environnement que
make prend en compte :

arch=sparcv9 arch=i80x86
syst=solaris syst=win32
comp=suncc comp=vc60

Le résultat, c'est que je passe d'une plateforme à l'autre, sans
vraiment me rendre compte, et les modifications que je fais sous Windows
sont immédiatement répercutées sous Unix et vice-versa. (J'avais
toujours un serveur X sous Windows aussi. Ainsi, même quand je
travaillais sur la machine Windows, j'avais une ou deux fenêtres
ouvertes sur la machine Unix.)

Dans le cas des développements multi-plateforme, c'est la solution que
je préconciserai -- Windows a encore quelques années de rétard par
rapport aux systèmes Open Desktop en ce qui concerne la convivialité
pour un développeur (au moins pour un qui travaille dans une équipe).

Si je développais uniquement pour Windows, en revanche, je ne serais pas
aussi bête que de ne pas apprendre la façon Windows de faire des chose.
Et j'adoperais certainement .cpp et .hpp.

--
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

06/11/2003 à 10:35

a écrit dans le message de
news:

Mais si tu travailles dans l'environement complètement Microsoft, avec
l'IDE et tout, pourquoi s'emmerdait.

Parce que j avais prevu de porter un code GNU/Linux sous windows
de telle sorte qu il compile avec vc++. Sur l une des listes de discussion
que je frequente, vc++ (6, 7 et 7.1) semble encore pas mal utilise.
Le projet est pourtant multiplateforme.

Moi, j'utilise .cc parce que c'est
ce qu'a toujours fait mes clients. Et ça marche bien pour moi parce que
ma plateforme principale a toujours été une variante d'Unix : Solaris,
HP/UX ou AIX. Quand je travaille sous Windows, c'est que je porte des
logiciels déjà écrits sous Unix, et je ne me sers pas de l'IDE.
J'installe CygWin et Emacs -- dans mon cas, je ne travaille pas
suffisamment sous Windows pour que ça vaut la peine d'apprendre
l'environnement propre, ni même de m'y adapter, dans la mésure que je
peux avoir l'environnement Unix complet.

Du peu que j en connaisse, c est une situation presqu ideale :-)

Si Windows est une de tes plateformes principales, en revanche,
conforme-toi aux conventions qui y règnent. Tu ne gagneras jamais à
lutter contre l'environnement.

C est l unique plateforme que je frequente un tout petit peu :-)
Je ne lutte pas, mes sources sont en .cpp systematiquement,
mais je ne p/veux pas contraindre les developpeurs d autres
plateformes a s interdire l usage des .cc.

Michel Michaud

06/11/2003 à 15:16

Dans news:,

"Michel Michaud" a écrit dans le message de
news:SHiqb.6401$
Tu connais l'expression « s'enfarger dans les fleurs du tapis » ?
:-)

Non je ne connais pas. Neanmoins, sans etre mechante, j imagine que
cette expression n est pas particulierement flatteuse a mon egard.

Non non, ce n'est pas spécialement méchant. C'était juste pour dire
qu'il y a des choses plus graves que celles dont tu parles.

Enfin, j avais prevenu pour le HS (precisant par ailleurs le groupe

Oui et là, on y est trop pour que je continue. Je vais t'écrire
directement d'ici peu.

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Extensions de fichiers

10 réponses

Veuillez sélectionner un problème