Je reçois actuellement des avertissements de compilation qui ressemblent à l'avertissement que j'ai donné dans le titre de la question. Des avertissements tels que ....
Autant que je sache, le programme n'est pas affecté de quelque manière que ce soit. Cependant, je n'aime pas les avertissements suspendus, mais je n'ai aucune idée de ce que ces avertissements tentent de me dire en plus que quelque chose de défini et lié à Boost est suspendu à quelque part de ne pas être utilisé. Cependant, tout ce que j'ai défini, j'ai utilisé. Les bibliothèques d'augmentation que j'utilise sont la bibliothèque aléatoire et la bibliothèque de systèmes de fichiers.
Lorsque je vérifie la source de l'avertissement, cela apporte le fichier ERROR_CATATEGORY.HPP de Boost et met en évidence certains Quelqu'un peut-il donner une idée de la raison pour laquelle ces avertissements apparaissent? Est-ce que je manque complètement quelque chose?
P.s. Les avertissements sont au niveau maximum. Avertissement: 'Boost :: System :: generic_category' défini mais non utilisé
AVERTISSEMENT: 'Boost :: System :: Posix_Category' défini mais non utilisé
Avertissement: 'Boost :: System :: errno_ecat' défini mais non utilisé
AVERTISSEMENT: 'Boost :: System :: natif_ecat' défini mais non utilisé
statique const S: "Catégories d'erreur prédéfinies" ou "Synonymes de dépréciation". Peut-être que le problème a quelque chose à voir avec mon manutention d'erreur (ou mon manque de manquement) lors de l'utilisation de la bibliothèque?
3 Réponses :
Ceci concerne la bibliothèque error_code dans la bibliothèque Boost.System. Boost Error_codes contient deux attributs: valeurs et catégories. Afin de faire des erreurs_codes extensibles afin que les utilisateurs de la bibliothèque puissent concevoir leurs propres catégories d'erreur, les concepteurs de boost ont besoin d'une certaine manière pour représenter une catégorie de code d'erreur unique. Un numéro d'identification simple ne suffirait pas, car cela pourrait entraîner deux projets utilisant des numéros d'identification contradictoires pour des catégories d'erreur personnalisées.
En gros, ce qu'ils ont fait était d'utiliser des adresses de mémoire, sous la forme d'objets statiques qui héritent de la classe de base Je suppose que ce que vous voyez est un effet secondaire de cette décision de conception. Étant donné que ces variables ne sont jamais réellement utilisées dans votre programme, le compilateur génère des avertissements. Il suffit de dire que je ne pense pas que vous faites quelque chose de mal. error_category . Ces variables ne font rien, sauf pour servir d'identifiants uniques d'une certaine catégorie d'erreur. Parce qu'ils sont essentiellement des objets factices statiques avec des adresses uniques en mémoire, vous pouvez facilement créer vos propres catégories d'erreur personnalisées qui n'interféreront pas avec d'autres identifiants d'erreur "IDS". Voir ici pour plus d'informations .
J'ai le même problème, mais mon lieur ne termine pas le travail, alors il ressemble vraiment à un gros problème aussi loin que je peux voir.
Je suis d'accord avec @chardles Salvia, mais je voulais ajouter qu'au moins à Boost 1.44.0, ces définitions sont maintenant enveloppées - d'être exclues comme obsolètes. Donc, si vous ne les utilisez pas, incluez simplement les lignes suivantes avant d'inclure le fichier d'en-tête:
Je définit cela, mais cela ne manque pas d'avertissements.
IMO Cela devrait être la réponse ou utiliser le drapeau du compilateur -D pour spécifier cette définition.
J'ai essayé le Cependant, en utilisant suggéré par expliqué (obliquement) par GNU GCC: http: //gcc.gnu .org / onlineDocs / gcc / répertoire-options.html boost_system_no_depecated suggéré par @ m.tibbits, et il semblait supprimer des instances des avertissements (dans un grand système construit sous Linux), mais pas tous.
-Isystem au lieu de -i pour inclure les en-têtes de boost (et ignorer leurs problèmes) a fonctionné pour moi.