Bonjour mon cher journal.
Bon essayant de recompiler le module de test C++ que j'ai construit pour évaluer la bibliothèque que j'ai écrite dans le même langage, j'obtiens ce message lorsque j'utilise G++ 3:
choosing 'Malib::operator == ' over 'operator ==' because worst conversion for the former is better than worst conversion for the latter
L'opérateur == étant un exemple. J'obtiens ce message une trentaine de fois car je fais un usage intensif de ces opérateurs. Bon, il semble selon Google que ce problème soit largement répandu, et dù précisement aux filouteries utilisés dans la surcharge des opérateurs.
Le problème est que j'ai trouvé beaucoup de forums où les gens se plaignent, mais peu de réponses.
Ma question est donc la suivante: Peut-être quelqu'un connaît-il la solution ou le flag magique à donner à GCC pour déclencher la compilation, mais surtout, existe-t-il une documentation avancée sur G++, voire, peut-on rêver, une une liste détaillée des erreurs que le compilateur est susceptible de retourner, avec un brin d'explication ?
Merci à tous les hackers de DLFP !
Journal Problème avec G++ 3 .
24
fév.
2004
# Re: Problème avec G++ 3 .
Posté par kesako . Évalué à 2.
Maître corbeau sur un arbre perché ...
[^] # Re: Problème avec G++ 3 .
Posté par cassecou . Évalué à 1.
Vieux souvenirs... c'est tout flou dans ma mémoire.
# Re: Problème avec G++ 3 .
Posté par Troy McClure (site web personnel) . Évalué à 2.
Non. Passer des heures à interpreter les messages abscons des compilos fait partie du c++ :) Et g++ est plutot au-dessus de la moyenne (il raconte un peu sa vie, mais il donne generalement plus d'infos que les autres)
Ton message d'erreur je l'ai dejà eu (c'est un des meilleurs, surtout en V.F. ;), mais j'ai oublié ce qui lui posait problème. Sans doute un probleme de conversions implicites quand tu fais a == b avec a et b de type differents ?
[^] # Re: Problème avec G++ 3 .
Posté par Obsidian . Évalué à 1.
Oh oui. En fait, la bibliothèque elle-même compile bien (et c'est heureux, mais c'est un peu la récompense pour avoir passé des mois à la nettoyer pour la rendre extrêmement propre, au moins dans la limite de mes capacités), mais le module lui-même compile mal, car il est écrit, lui, dans un style, qui correspond un peu plus à ce que les gens qui utiliseront les fonctions de la lib risquent de produire.
En fait, en gros je fait un:
cout << (A == B) << endl;
avec les parenthèses dûes à la priorité des opérateurs. L'expression entre parenthèses est censée retourner un booléen, qui se traduit ensuite par un « 0 » ou un « 1 » renvoyé sur la sortie standard.
Le meilleur, c'est que cela fonctionne très bien avec gcc (g++) 2.95. Malheureusement, je ne compile pas cette bibliothèque sur ma machine personnelle mais sur deux gros serveurs SUN SPARC SunOS, l'un équipé de gcc 2.95.3 et l'autre de gcc 3.1. Je me suis déjà dépatouillé avec les options spécifiques à SPARC. Il ne me manque plus grand chose je crois.
[^] # Re: Problème avec G++ 3 .
Posté par inz . Évalué à 1.
Vu la gueule du message, effectivement, le compilo trouve une ambiguité dans l'interpretation de l'opérateur à l'utilisation. Mais bon vu l'énoncé, il pourrait faire un choix par lui-même, ca ressemble plus a un warning qu'à un error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8316(...)
Y'a ambiguité entre ton operateur et celui fourni par g++. Ca serait intéressant de voir la signature de ton(tes) opérateur(s) surchargé(s). Apparemment, ce genre d'ambiguité n'est pas ISO C++ compliant.
Maintenant pourquoi ca pète pas en 2.95, ... je suppose qu'il fait un choix arbitraire (genre le premier à être déclarer).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.