Template et compilateurs courants

Bonjour,

Bonjour à tous, au risque d'être HS, j'ai une question qui porte sur le
support des template sur la plupart des compilateurs C++ (Visual,
CodeWarrior, Gnu, ...).

Avez vous eu des problèmes dans le code généré qui seraient liés à
l'usage de template dans votre code?

Oui, avec Visual C++ 6.

Je n'en ai pas personnelement(sur MS Visual .Net 2003) mais "on m'a dit
que" certains compilateurs de la famille GNU les supporteraient mal.

A ma connaissance, il n'existe qu'un seul compilateur C++ de la famille
"GNU" et c'est celui de gcc, non ?

Je n'ai pas eu de soucis à ce niveau avec ce dernier jusqu'à présent.




--
http://david.marec.free.fr

On Mon, 12 Dec 2005 14:58:08 +0100, David MAREC
<dmarec.spam@free.invalid>:

A ma connaissance, il n'existe qu'un seul compilateur C++ de la famille
"GNU" et c'est celui de gcc, non ?

Mais il y a eu un paquet de versions très différentes en relativement
peu de temps.

Raskalito des ouabes <Ben_j_ai_pas_envie_qu_on_m_ecrive@chaispas.fr> writes:

Je n'en ai pas personnelement(sur MS Visual .Net 2003) mais "on m'a dit
que" certains compilateurs de la famille GNU les supporteraient mal.

Le support des templates de g++ a plutot bonne reputation. Je n'ai
jamais eu de problemes avec, mais ecrivant du code devant passer avec
SparcWorks ce n'est guere surprenant...

Est-ce que par hasard "on" ne confondrait pas support de la recherche
des noms en 2 phases (disponibles avec g++ depuis 3.4 me semble-t'il)
et probleme dans le compilateur. Si c'est le cas, c'est dans le code
qu'il y a un probleme; le message d'erreur de g++ est
relativement clair:

test2phase.cc:4: error: there are no arguments to `g' that depend on a template parameter, so a declaration of `g' must be available
test2phase.cc:4: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)

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

A ma connaissance, il n'existe qu'un seul compilateur C++ de la famille
"GNU" et c'est celui de gcc, non ?

Mais il y a eu un paquet de versions très différentes en relativement
peu de temps.

En effet, j'utilise la version 3.4.4. sous Windows et
je n'ai pas eu la curiosité de regarder quelle version est embarquée
dans les FreeBSD 6-Stable que j'ai mis à jour récemment;
mais je doute que ce soit la branche 4 de GCC.


Je n'ai rien lu décrivant un problème concernant les templates sur ces
versions, pour répondre à l'initiateur du fil.

Jean-Marc Bourguet wrote:

Raskalito des ouabes
<Ben_j_ai_pas_envie_qu_on_m_ecrive@chaispas.fr> writes:

Je n'en ai pas personnelement(sur MS Visual .Net 2003) mais
"on m'a dit que" certains compilateurs de la famille GNU les
supporteraient mal.

Le support des templates de g++ a plutot bonne reputation.

Ça dépend de ce qu'on entend par « support ». Ils ont une bonne
réputation en ce qui concerne la conformance à la norme (sauf,
évidemment, en ce qui concerne export). Son support du code
existant, qui marchait avec la version précédante, n'est pas
toujours aussi bien qu'on pourrait vouloir.

Je n'ai jamais eu de problemes avec, mais ecrivant du code
devant passer avec SparcWorks ce n'est guere surprenant...

Cependant... C'est assez simple d'écrire du code qui marche avec
SparcWorks, et non avec g++. La version de SparcWorks que j'ai,
au moins, ne supporte pas la récherche à deux phases. Selon la
norme, c'est g++ qui a raison, et SparcWorks qui a tort. Mais si
tu as développé sous SparcWorks (ou même sur une version
précédante de g++), c'est sous g++ que ton code ne va pas
marcher.

Est-ce que par hasard "on" ne confondrait pas support de la
recherche des noms en 2 phases (disponibles avec g++ depuis
3.4 me semble-t'il) et probleme dans le compilateur. Si c'est
le cas, c'est dans le code qu'il y a un probleme; le message
d'erreur de g++ est relativement clair:

test2phase.cc:4: error: there are no arguments to `g' that depend on a te mplate parameter, so a declaration of `g' must be available
test2phase.cc:4: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)

Note aussi que dans ce cas précis, ils avaient aussi ménagé une
voie de migration. Il y a eu des versions où ce n'était qu'un
avertissement, même sans l'option (au moins dans certains cas).

--
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" <kanze@gabi-soft.fr> writes:

Jean-Marc Bourguet wrote:

Raskalito des ouabes
<Ben_j_ai_pas_envie_qu_on_m_ecrive@chaispas.fr> writes:

Je n'en ai pas personnelement(sur MS Visual .Net 2003) mais
"on m'a dit que" certains compilateurs de la famille GNU les
supporteraient mal.

Le support des templates de g++ a plutot bonne reputation.

Ça dépend de ce qu'on entend par « support ». Ils ont une bonne
réputation en ce qui concerne la conformance à la norme (sauf,
évidemment, en ce qui concerne export). Son support du code
existant, qui marchait avec la version précédante, n'est pas
toujours aussi bien qu'on pourrait vouloir.

Tu es parfois schizophrene :-) tu reproches a SparcWorks sa mauvais
bibliotheque (due pour une bonne partie a son souci de compatibilite
avec les versions precedantes) et a g++ son manque de compatibilite.

(Et si ton reproche concerne 3.4 par rapport a ce qu'il y a avait
avant, c'est tres severe quand on sait que le parseur C++ a totalement
ete reecrit; c'aurait merite un changement du premier chiffre si le
numero de version de gcc n'etait pas global pour l'ensemble des
compilateurs de la collection)

Je n'ai jamais eu de problemes avec, mais ecrivant du code
devant passer avec SparcWorks ce n'est guere surprenant...

Cependant... C'est assez simple d'écrire du code qui marche avec
SparcWorks, et non avec g++. La version de SparcWorks que j'ai,
au moins, ne supporte pas la récherche à deux phases. Selon la
norme, c'est g++ qui a raison, et SparcWorks qui a tort. Mais si
tu as développé sous SparcWorks (ou même sur une version
précédante de g++), c'est sous g++ que ton code ne va pas
marcher.

Avec aCC d'HP dans la boucle, le code a risque a ete identifie depuis
longtemps :-) (pour ceux que ca interesse, il y a un 4ieme compilateur
utilise, xlC d'IBM ce qui fait 11 cibles en considerant 32 et 64 bits
comme des cibles differentes).

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 Bourguet wrote:

"kanze" <kanze@gabi-soft.fr> writes:

Jean-Marc Bourguet wrote:

Raskalito des ouabes
<Ben_j_ai_pas_envie_qu_on_m_ecrive@chaispas.fr> writes:

Je n'en ai pas personnelement(sur MS Visual .Net 2003)
mais "on m'a dit que" certains compilateurs de la
famille GNU les supporteraient mal.

Le support des templates de g++ a plutot bonne reputation.

Ça dépend de ce qu'on entend par « support ». Ils ont une
bonne réputation en ce qui concerne la conformance à la
norme (sauf, évidemment, en ce qui concerne export). Son
support du code existant, qui marchait avec la version
précédante, n'est pas toujours aussi bien qu'on pourrait
vouloir.

Tu es parfois schizophrene :-)

Je prends en compte les problèmes que je rencontre dans ma vie
professionnelle. Et c'est vrai qu'il y a souvent des exigeances
contradictoires.

Ici, en revanche, mon seul but, c'était de rappeler qu'on peut
entendre des choses différentes sous le même vocable. Et si
c'est vrai qu'ici (dans ce forum), j'imagine que quand on parle
de « support des templates », la plupart des gens entendent un
implicit « selon la norme », dans la plupart des organisations,
ce qu'on entend, c'est « support du code déjà écrit ».

Je reconnais que c'est un problème extrèmement difficile pour un
implémenteur. Dans l'ensemble, personnellement, je crois que g++
l'a fait assez bien. Mais je ne dirais pas que c'est ça
réputation. Sans doute parce qu'il était le premier à aborder le
problème, beaucoup de gens ont l'impression qu'il fait mal --
après tout, un compilateur qui ignore la recherche à deux phases
aurait bien moins de problèmes avec l'ancien code qu'un qui
l'implémente, quelque soit le chemin de migration qu'il a
choisi. Mais le fait reste qu'ici, il y a un certain nombre de
gens qui pestent contre g++ parce qu'il n'accepte pas notre code
existant. Développé sous Sun CC 4.2 ou VC++ 6.0... pour ce qui
est le plus récent -- certains composants ont quinze ans d'age
ou plus.

D'autre côté, il y en a plusieurs qui pestent contre Sun CC,
parce qu'ils ne peuvent pas utiliser toutes les nouvelles
techniques dont il ont lu. Pire : certaines techniques
marcherait avec Sun CC, à condition de lui donner de bonnes
options. Seulement, l'ancien code (y compris les en-têtes
qu'utilise le nouveau code) ne se compile pas avec ces options.

En somme, si tu es implémenteur, quoique tu fasses, c'est faux.

tu reproches a SparcWorks sa mauvais bibliotheque (due pour
une bonne partie a son souci de compatibilite avec les
versions precedantes) et a g++ son manque de compatibilite.

(Et si ton reproche concerne 3.4 par rapport a ce qu'il y a
avait avant, c'est tres severe quand on sait que le parseur
C++ a totalement ete reecrit; c'aurait merite un changement du
premier chiffre si le numero de version de gcc n'etait pas
global pour l'ensemble des compilateurs de la collection)

Au fond, j'ai assez peu de reproches à faire de g++, et rien en
ce qui concerne les templates (à part l'absence d'export). Je ne
parlais pas d'un problème du compilateur, en tant que tel, mais
de la perception d'une certaine communauté. (Il me semblait
d'ailleurs l'avoir clarifié par la suite. Mais c'était peut-être
dans un autre thread.)

Je n'ai jamais eu de problemes avec, mais ecrivant du code
devant passer avec SparcWorks ce n'est guere surprenant...

Cependant... C'est assez simple d'écrire du code qui marche
avec SparcWorks, et non avec g++. La version de SparcWorks
que j'ai, au moins, ne supporte pas la récherche à deux
phases. Selon la norme, c'est g++ qui a raison, et
SparcWorks qui a tort. Mais si tu as développé sous
SparcWorks (ou même sur une version précédante de g++),
c'est sous g++ que ton code ne va pas marcher.

Avec aCC d'HP dans la boucle, le code a risque a ete identifie
depuis longtemps :-) (pour ceux que ca interesse, il y a un
4ieme compilateur utilise, xlC d'IBM ce qui fait 11 cibles en
considerant 32 et 64 bits comme des cibles differentes).

C'est la portabilité vecue. La seule vraie. N'empèche que je
parie que vous avez eu des problèmes lorsque les compilateurs
ont commencé à implémenter la récherche en deux phases.

Le problème que nous sommes en train de vivre, c'est que
jusqu'il y a peu ici, la portabilité n'était pas vraiment un
thème, et quand on y pensait, c'était entre Sun CC 4.2 et VC++
6.0, et les problèmes dus aux compilateurs étaient moins que les
problèmes dus aux différences du système. Depuis peu, on a d'un
côté une démande d'une migration éventuelle d'une partie de
l'application à Linux (et donc g++), et de l'autre, un groupe de
développement qui a migré à g++ parce qu'il voulait utiliser les
nouveautés du langages. Le résultat est une certaine tension
chez ceux qui doivent maintenir l'ancien code.

--
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" <kanze@gabi-soft.fr> writes:

Jean-Marc Bourguet wrote:
[...]

En somme, si tu es implémenteur, quoique tu fasses, c'est faux.

Je sais. C'est un peu notre situation (on a un langage d'extension
avec environ 5000 fonctions documentees -- estimation rapide basees
sur la taille de l'index du Quick Reference Guide de la version d'il y
a 3 ans --, et on a de la chance en ce qu'on maitrise tout: il n'y a
pas un comite exterieur ni n'implementation concurrente). Je
comprends tres bien les deux tensions contradictoires et c'est pour ca
que je defendais les implementeurs.

Avec aCC d'HP dans la boucle, le code a risque a ete identifie
depuis longtemps :-) (pour ceux que ca interesse, il y a un
4ieme compilateur utilise, xlC d'IBM ce qui fait 11 cibles en
considerant 32 et 64 bits comme des cibles differentes).

C'est la portabilité vecue.

Bof, c'est tout du Unix, ca simplifie quand meme pas mal. On a bien
quelques librairies partagees avec d'autres produits qui sont aussi
disponibles sous Windows. Les choses les plus anciennes ont encore
des traces de VMS et de Unix maintenant disparus. Rien de plus
exotique.

La seule vraie. N'empèche que je parie que vous avez eu des
problèmes lorsque les compilateurs ont commencé à implémenter la
récherche en deux phases.

Je doute qu'on avait beaucoup de template a l'epoque; aCC implemente
depuis longtemps la recherche en deux phases et nous sommes tres
conservateurs. On n'en a d'ailleurs toujours pas tant que ca qui ne
soit pas des infrastructures informatiques. La moitie de notre code
est toujours en C compile par un compilateur C, et une bonne partie du
reste n'est que du C compile par un compilateur C++.

Le problème que nous sommes en train de vivre, c'est que jusqu'il y
a peu ici, la portabilité n'était pas vraiment un thème, et quand on
y pensait, c'était entre Sun CC 4.2 et VC++ 6.0,

Je retire ce que j'ai ecrit: nous ne sommes pas conservateurs :-) Je
me souviens qu'on a abandonne Sun CC 4.2 avant 2000 (si j'ai bonne
memoire, la raison qui nous avait ete donnee etait la fin du support
par Sun et le manque de qualification pour l'an 2000; il y avait de
l'opposition parce que la migration n'etait pas aussi simple que ca et
que le moment n'etait pas particulierement bien choisi: en fin d'un
cycle et on trouvait qu'attendre le debut du cycle suivant etait plus
sense).

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 Bourguet wrote:

"kanze" <kanze@gabi-soft.fr> writes:

Jean-Marc Bourguet wrote:
[...]

La seule vraie. N'empèche que je parie que vous avez eu des
problèmes lorsque les compilateurs ont commencé à
implémenter la récherche en deux phases.

Je doute qu'on avait beaucoup de template a l'epoque; aCC
implemente depuis longtemps la recherche en deux phases et
nous sommes tres conservateurs. On n'en a d'ailleurs toujours
pas tant que ca qui ne soit pas des infrastructures
informatiques.

Ça correspond un peu à mon expérience. Au niveau applicatif, les
templates servent assez peu, et l'héritage beaucoup ; au niveau
infrastructure, c'est prèsque l'opposé.

La moitie de notre code est toujours en C compile par un
compilateur C, et une bonne partie du reste n'est que du C
compile par un compilateur C++.

Le problème que nous sommes en train de vivre, c'est que
jusqu'il y a peu ici, la portabilité n'était pas vraiment un
thème, et quand on y pensait, c'était entre Sun CC 4.2 et
VC++ 6.0,

Je retire ce que j'ai ecrit: nous ne sommes pas conservateurs :-)

Je crois qu'on est comme beaucoup de boîtes : d'une part, on
veut avancer, mais de l'autre, on a pas mal de code existant
qu'il faut prendre en compte, et quelles résistances chez
certains programmeurs.

Je me souviens qu'on a abandonne Sun CC 4.2 avant 2000 (si
j'ai bonne memoire, la raison qui nous avait ete donnee etait
la fin du support par Sun et le manque de qualification pour
l'an 2000; il y avait de l'opposition parce que la migration
n'etait pas aussi simple que ca et que le moment n'etait pas
particulierement bien choisi: en fin d'un cycle et on trouvait
qu'attendre le debut du cycle suivant etait plus sense).

À vrai dire, je ne sais pas pourquoi ça a trainé autant. Mais
d'après ce que comprend, il y a encore des projets qui se sert
du 4.2. Et il y en a certainement avec g++ 2.95.2. D'autre côté,
il y en a certains avec la dernière version de g++, qui
expérimente pas mal.

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