Je dois utiliser un code C++ tiers, qui compile sous VC6, mais
que j'ai pour l'instant du mal à faire compiler sous g++ 3.4.2
sur windows2000.
g++ -c truc.cpp -o truc.o
error: call of overloaded ... is ambiguous
candidates are: bla bla
D'où ma question : est-ce qu'il y aurait des options de
compilation permettant d'éviter ce message d'erreur ?
Je crois que le code source C++ n'est pas parfait, mais je
préférerais ne pas y toucher, et plutôt employer un mode
de compilation "laxiste" si g++ le propose.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michael DOUBEZ
Bonjour,
Je dois utiliser un code C++ tiers, qui compile sous VC6, mais que j'ai pour l'instant du mal à faire compiler sous g++ 3.4.2 sur windows2000.
g++ -c truc.cpp -o truc.o error: call of overloaded ... is ambiguous candidates are: bla bla
D'où ma question : est-ce qu'il y aurait des options de compilation permettant d'éviter ce message d'erreur ? Je crois que le code source C++ n'est pas parfait, mais je préférerais ne pas y toucher, et plutôt employer un mode de compilation "laxiste" si g++ le propose.
Si l'appel est ambigu, le compilateur ne pourra pas choisir. Ce n'est pas juste un problème de typage et de correction ici.
Si tu donnes l'erreur en entier, on pourra voir pourquoi ça compile sur un compilateur et pas sur un autre.
Michael
Bonjour,
Je dois utiliser un code C++ tiers, qui compile sous VC6, mais
que j'ai pour l'instant du mal à faire compiler sous g++ 3.4.2
sur windows2000.
g++ -c truc.cpp -o truc.o
error: call of overloaded ... is ambiguous
candidates are: bla bla
D'où ma question : est-ce qu'il y aurait des options de
compilation permettant d'éviter ce message d'erreur ?
Je crois que le code source C++ n'est pas parfait, mais je
préférerais ne pas y toucher, et plutôt employer un mode
de compilation "laxiste" si g++ le propose.
Si l'appel est ambigu, le compilateur ne pourra pas choisir. Ce n'est
pas juste un problème de typage et de correction ici.
Si tu donnes l'erreur en entier, on pourra voir pourquoi ça compile sur
un compilateur et pas sur un autre.
Je dois utiliser un code C++ tiers, qui compile sous VC6, mais que j'ai pour l'instant du mal à faire compiler sous g++ 3.4.2 sur windows2000.
g++ -c truc.cpp -o truc.o error: call of overloaded ... is ambiguous candidates are: bla bla
D'où ma question : est-ce qu'il y aurait des options de compilation permettant d'éviter ce message d'erreur ? Je crois que le code source C++ n'est pas parfait, mais je préférerais ne pas y toucher, et plutôt employer un mode de compilation "laxiste" si g++ le propose.
Si l'appel est ambigu, le compilateur ne pourra pas choisir. Ce n'est pas juste un problème de typage et de correction ici.
Si tu donnes l'erreur en entier, on pourra voir pourquoi ça compile sur un compilateur et pas sur un autre.
Michael
Sylvain
Arcturus wrote on 06/03/2007 13:22:
Bonjour,
Je dois utiliser un code C++ tiers, qui compile sous VC6, mais que j'ai pour l'instant du mal à faire compiler sous g++ 3.4.2 sur windows2000.
g++ -c truc.cpp -o truc.o error: call of overloaded ... is ambiguous candidates are: bla bla
D'où ma question : est-ce qu'il y aurait des options de compilation permettant d'éviter ce message d'erreur ? Je crois que le code source C++ n'est pas parfait, mais je préférerais ne pas y toucher, et plutôt employer un mode de compilation "laxiste" si g++ le propose.
c'est une erreur (pas un warning), je doute donc qu'une option quelconque lève l'ambiguïté ... sauf à masquer certaines résolutions / coercions implicites ou recours à temporaire: VC98 est parfois assez peu imaginatif pour les chemins qu'il pourrait utiliser et il peut donc ne pas déceler certaines ambiguïtés.
Sylvain.
Arcturus wrote on 06/03/2007 13:22:
Bonjour,
Je dois utiliser un code C++ tiers, qui compile sous VC6, mais
que j'ai pour l'instant du mal à faire compiler sous g++ 3.4.2
sur windows2000.
g++ -c truc.cpp -o truc.o
error: call of overloaded ... is ambiguous
candidates are: bla bla
D'où ma question : est-ce qu'il y aurait des options de
compilation permettant d'éviter ce message d'erreur ?
Je crois que le code source C++ n'est pas parfait, mais je
préférerais ne pas y toucher, et plutôt employer un mode
de compilation "laxiste" si g++ le propose.
c'est une erreur (pas un warning), je doute donc qu'une option
quelconque lève l'ambiguïté ... sauf à masquer certaines résolutions /
coercions implicites ou recours à temporaire: VC98 est parfois assez peu
imaginatif pour les chemins qu'il pourrait utiliser et il peut donc ne
pas déceler certaines ambiguïtés.
Je dois utiliser un code C++ tiers, qui compile sous VC6, mais que j'ai pour l'instant du mal à faire compiler sous g++ 3.4.2 sur windows2000.
g++ -c truc.cpp -o truc.o error: call of overloaded ... is ambiguous candidates are: bla bla
D'où ma question : est-ce qu'il y aurait des options de compilation permettant d'éviter ce message d'erreur ? Je crois que le code source C++ n'est pas parfait, mais je préférerais ne pas y toucher, et plutôt employer un mode de compilation "laxiste" si g++ le propose.
c'est une erreur (pas un warning), je doute donc qu'une option quelconque lève l'ambiguïté ... sauf à masquer certaines résolutions / coercions implicites ou recours à temporaire: VC98 est parfois assez peu imaginatif pour les chemins qu'il pourrait utiliser et il peut donc ne pas déceler certaines ambiguïtés.
Sylvain.
Arcturus
Si tu donnes l'erreur en entier, on pourra voir pourquoi ça compile sur un compilateur et pas sur un autre.
ok. Je ne voulais pas balancer tout le code + message d'erreur. J'essaie d'isoler la partie incriminée puis je reviens ici.
(PS: Que ça passe chez un compilo, et qu'il y ait des warnings chez un autre, ça ne me choque pas. Mais que ça compile/compile pas selon la crémerie ...)
Si tu donnes l'erreur en entier, on pourra voir pourquoi ça compile sur
un compilateur et pas sur un autre.
ok. Je ne voulais pas balancer tout le code + message d'erreur.
J'essaie d'isoler la partie incriminée puis je reviens ici.
(PS: Que ça passe chez un compilo, et qu'il y ait des warnings chez
un autre, ça ne me choque pas. Mais que ça compile/compile pas selon
la crémerie ...)
Si tu donnes l'erreur en entier, on pourra voir pourquoi ça compile sur un compilateur et pas sur un autre.
ok. Je ne voulais pas balancer tout le code + message d'erreur. J'essaie d'isoler la partie incriminée puis je reviens ici.
(PS: Que ça passe chez un compilo, et qu'il y ait des warnings chez un autre, ça ne me choque pas. Mais que ça compile/compile pas selon la crémerie ...)
James Kanze
On Mar 6, 3:02 pm, Arcturus wrote:
(PS: Que ça passe chez un compilo, et qu'il y ait des warnings chez un autre, ça ne me choque pas. Mais que ça compile/compile pas selon la crémerie ...)
Ça arrive souvent. En ce qui te concerne ici, ça arrive très souvent dans la résolution du surcharge, qui a changé des les détails sur le temps, et qui est assez subtile pour qu'on ne soit pas toujours d'accord sur son interprétation, et que les petites erreurs dans les implémentations soient fréquentes.
Dans le cas de VC++, les soucis de ne pas casser du code ancien font qu'elle prend en compte aussi certaines fonctions que g++ écarte, et ne considère pas du tout. (En général, j'ai beaucoup de compréhension pour ce genre d'écart. Dans ce cas précis, en revanche, la règel a changé 1987 ou 1988. À une époque donc où il y avait fort peu du code C++ existant, et pas de code VC++ du tout.)
-- James Kanze (GABI Software) email: 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
On Mar 6, 3:02 pm, Arcturus <ng.u...@tld.invalid> wrote:
(PS: Que ça passe chez un compilo, et qu'il y ait des warnings chez
un autre, ça ne me choque pas. Mais que ça compile/compile pas selon
la crémerie ...)
Ça arrive souvent. En ce qui te concerne ici, ça arrive très
souvent dans la résolution du surcharge, qui a changé des les
détails sur le temps, et qui est assez subtile pour qu'on ne
soit pas toujours d'accord sur son interprétation, et que les
petites erreurs dans les implémentations soient fréquentes.
Dans le cas de VC++, les soucis de ne pas casser du code ancien
font qu'elle prend en compte aussi certaines fonctions que g++
écarte, et ne considère pas du tout. (En général, j'ai beaucoup
de compréhension pour ce genre d'écart. Dans ce cas précis, en
revanche, la règel a changé 1987 ou 1988. À une époque donc où
il y avait fort peu du code C++ existant, et pas de code VC++ du
tout.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
(PS: Que ça passe chez un compilo, et qu'il y ait des warnings chez un autre, ça ne me choque pas. Mais que ça compile/compile pas selon la crémerie ...)
Ça arrive souvent. En ce qui te concerne ici, ça arrive très souvent dans la résolution du surcharge, qui a changé des les détails sur le temps, et qui est assez subtile pour qu'on ne soit pas toujours d'accord sur son interprétation, et que les petites erreurs dans les implémentations soient fréquentes.
Dans le cas de VC++, les soucis de ne pas casser du code ancien font qu'elle prend en compte aussi certaines fonctions que g++ écarte, et ne considère pas du tout. (En général, j'ai beaucoup de compréhension pour ce genre d'écart. Dans ce cas précis, en revanche, la règel a changé 1987 ou 1988. À une époque donc où il y avait fort peu du code C++ existant, et pas de code VC++ du tout.)
-- James Kanze (GABI Software) email: 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
