Problème d'avertissement de compilation Eclipse C ++

Question

Voici un code pour illustrer un problème gênant:

class A {
public:
    A():
        m_b(1),
        m_a(2)
        {}
private:
    int m_a;
    int m_b;
};

Il s'agit d'une sortie dans la vue Console :

make all 
Building file: ../test.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"test.d" -MT"test.d" -o"test.o" "../test.cpp"
../test.cpp: In constructor 'A::A()':
../test.cpp:9: warning: 'A::m_b' will be initialized after
../test.cpp:8: warning:   'int A::m_a'
../test.cpp:3: warning:   when initialized here
Finished building: ../test.cpp

Le problème est que, dans la vue Problèmes , 3 avertissements distincts (lignes contenant le mot d'avertissement) s'affichent, alors qu'en réalité, il y a 4 lignes décrivant un problème.

Y a-t-il quelque chose qui me manque?

Question supplémentaire. C’est peut-être un esprit Eclipse, mais existe-t-il un moyen de rendre la vue Console cliquable comme le fait la plupart des environnements de développement (ex: Visual Studio, emacs, etc.)

Merci Dima

Answer 1

Selon le dernier commentaire sur ce rapport de bogue que vous devriez pouvoir cliquer sur la vue de la console pour accéder au code dans CDT 7.0.

Il peut être intéressant de consulter les versions de jalon pour voir si le regroupement des messages d'erreur est meilleur. Si ce n'est pas le cas, essayez de regrouper les messages liés.

Answer 2

L'avertissement comporte plusieurs lignes car chaque ligne fait référence à une ligne de code différente. Le problème qui nous est signalé est ce qui se produit dans le m_b déclaré à la ligne 9, il s'agit de car du fait que m_a de la ligne 8 est déclaré avant m_b , mais en est la cause en raison de ce qui se passe dans votre liste d'initialisation, qui commence à la ligne 3.

Avec gcc, il est possible que des avertissements qui ne sont pas liés apparaissent l'un après l'autre (par exemple, un tas d'éléments inconnus tous faux dans main ), ce qui empêche Eclipse de le savoir. à partir de la sortie, qu'il s'agisse d'avertissements distincts ou liés tous au même problème.

Answer 3

Les champs sont initialisés dans l'ordre dans lequel ils sont déclarés dans la classe. Le compilateur vous aide en vous indiquant que le constructeur est en cours d'initialisation dans le mauvais ordre. Cela peut entraîner des erreurs étranges, si l’ordre d’initialisation est important.

Answer 4

Je suppose que c'est parce que CDT est encore un peu immature et qu'il ne peut probablement pas analyser la sortie g ++ de la meilleure façon possible. Ligne ../ test.cpp: dans le constructeur 'A :: A ()': ne contient pas de numéro de ligne, CDT ne peut donc pas placer de marqueur d'erreur dans test.cpp editor et ce problème affecte probablement Problems .

La vue Problems pose davantage de problèmes. Par exemple, vous ne pouvez supprimer que les erreurs visibles de la vue. Par conséquent, si vous obtenez plus de 100 éléments par défaut, vous devez les supprimer séquentiellement, cent par cent. De plus, les erreurs ne sont pas automatiquement supprimées après le nettoyage, si une erreur survient dans un fichier d'en-tête indépendant. Soyez simplement indulgent, ils améliorent la TCC de publication en publication.

Question supplémentaire: qu'entendez-vous par "rendre la vue Console cliquable"?

Answer 5

Merci David, mais je pense que vous m'avez mal compris. Je faisais référence au fait que la vue "Problèmes" dans eclipse trie les erreurs du compilateur par ordre alphabétique. Comme le disait Dima, cela pose un problème avec les messages d’erreur gcc répartis sur deux lignes, tels que

.

1. erreur: "tel ou tel" est protégé
2. dans ce contexte

car toutes les lignes "dans ce contexte" sont séparées de la variable à laquelle elles font référence.

CEPENDANT, je viens de trouver la possibilité de modifier l’ordre de tri des erreurs du compilateur, le petit triangle pointant vers le bas en haut de la vue (cela ne fait que préciser que c’est ici que vous définissez les options de la vue, car je suis nouvelle. éclipse). Si vous jouez avec cela, cela vous aidera mais ne pourrez toujours pas empêcher les erreurs dans le même fichier d'être mélangées (pourquoi n'y a-t-il pas une option, laissez-les simplement comme elles étaient?)