Question

Je reçois actuellement des avertissements du compilateur qui ressemblent à l'avertissement que j'ai donné dans le titre de la question. Des avertissements tels que ....

warning: 'boost :: system :: generic_category' défini mais non utilisé

warning: 'boost :: system :: posix_category' défini mais non utilisé

warning: 'boost :: system :: errno_ecat' défini mais non utilisé

warning: 'boost :: system :: native_ecat' défini mais non utilisé

Pour autant que je sache, le programme n’est affecté en aucune façon. Cependant, je n'aime pas les avertissements qui traînent, mais je n'ai aucune idée de ce que ces avertissements essaient de me dire, à part que quelque chose qui est défini et lié au boost, c'est quelque part qui n'est pas utilisé. Cependant, tout ce que j'ai défini, je l'ai utilisé. Les bibliothèques boost que j'utilise sont la bibliothèque aléatoire et la bibliothèque du système de fichiers.

Lorsque je vérifie la source de l'avertissement, il affiche le fichier error_category.hpp de Boost et met en évidence certains const const qui sont commentés en tant que "catégories d'erreur prédéfinies". ou "synonymes déconseillés". Peut-être que le problème a quelque chose à voir avec ma gestion des erreurs (ou mon manque d’erreur) lors de l’utilisation de la bibliothèque?

Quelqu'un peut-il expliquer pourquoi ces avertissements apparaissent? Est-ce que je manque complètement quelque chose?

P.S. Les avertissements sont au niveau maximum.

Était-ce utile?

La solution

Cela concerne la bibliothèque error_code de la bibliothèque Boost.System. Les codes d'erreur Boost contiennent deux attributs: les valeurs et les catégories. Afin de rendre les codes d'erreur plus extensibles et de permettre aux utilisateurs de bibliothèques de définir leurs propres catégories d'erreur, les concepteurs de boost avaient besoin d'un moyen de représenter une catégorie de code d'erreur unique. Un simple numéro d'identification ne suffirait pas, car deux projets pourraient alors utiliser des numéros d'identification en conflit pour les catégories d'erreur personnalisées.

Ils ont donc essentiellement utilisé des adresses de mémoire, sous la forme d'objets statiques qui héritent de la classe de base catégorie_erreur . En réalité, ces variables ne font rien, sauf pour servir d'identificateurs uniques d'une certaine catégorie d'erreur. Comme il s’agit essentiellement d’objets factices statiques avec des adresses uniques en mémoire, vous pouvez facilement créer vos propres catégories d’erreurs personnalisées qui n’interféreront pas avec les "ID" des autres catégories d’erreurs. Voir ici pour plus d'informations. .

Je suppose que ce que vous constatez est un effet secondaire de cette décision de conception. Comme ces variables ne sont jamais réellement utilisées dans votre programme, le compilateur génère des avertissements. Disons simplement que je ne pense pas que vous faites quelque chose de mal.

Autres conseils

Je suis d'accord avec @Charles Salvia, mais je voulais ajouter qu'au moins à compter de Boost 1.44.0, ces définitions sont maintenant encapsulées - pour être exclues car elles sont déconseillées. Donc, si vous ne les utilisez pas, incluez simplement les lignes suivantes avant d'inclure le fichier d'en-tête:

#ifndef BOOST_SYSTEM_NO_DEPRECATED
#define BOOST_SYSTEM_NO_DEPRECATED 1
#endif

J'ai essayé le BOOST_SYSTEM_NO_DEPRECATED suggéré par @ M.Tibbits, et il a semblé supprimer certaines occurrences des avertissements (dans un grand système construit sous Linux), mais pas toutes.

Cependant, utiliser -isystem au lieu de -I pour inclure les en-têtes de boost (et ignorer leurs problèmes) a fonctionné pour moi.

Proposé par https://exceptionshub.com/how-do-you-disable-the-unun-variable-warnings-coming-out-of-gcc.html

Expliqué (en oblique) par GNU GCC: http: //gcc.gnu .org / onlinedocs / gcc / Directory-Options.html

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top