Avons-nous vraiment besoin de std :: error_category et de std :: error_condition?

Question

Donc, sur mon voyage pour comprendre comment fonctionne std::error_code je commence à me demander si nous avons vraiment besoin std::error_condition et std::error_category. J'essaye de mettre en application ce qui est dans le tutoriel this et this et la quantité de travail est non-trivial avec elle étant assez fragile (je suis actuellement bloqué en essayant de comprendre pourquoi ce code provoque des erreurs de liaison avec des symboles en double

est-il pas plus facile de sous-classe std::error_code, ajoutez une méthode message propriété & puis laissez std::error_code être comparable à un ENUM où les codes d'erreur sont définis? Je me bats pour comprendre pourquoi j'ai besoin std::error_category et std::error_condition du tout.

Answer 1

Le principal avantage est que error_code est un type copiable qui peut être remis de la bibliothèque à la bibliothèque wi sans avoir à impliquer une allocation de mémoire dynamique ou un modèle, ce qui le rend très léger et facile à utiliser.

Si vous écrivez un projet entièrement autonome, alors oui, les codes d'erreur et les catégories semblent trop compliqués quand vous pourriez avoir votre propre type. Cependant, les choses changent lors de l'écriture d'une bibliothèque destinée à être utilisée par d'autres personnes (comme ASIO, puisque vous avez lié think-async.com). Vous pouvez faire en sorte qu'une bibliothèque reçoive une instance error_code, et qu'elle soit capable de la transmettre proprement et efficacement sans avoir besoin de connaître le code qui utilise la bibliothèque, ou de faire en sorte que toutes les fonctions de gestion des erreurs soient basées sur l'erreur type.

Dans ce contexte, les catégories d'erreur sont importantes lorsqu'il s'agit de sources d'erreurs multiples, car un code d'erreur donné peut signifier deux choses différentes en fonction de la source de l'erreur.

Modifier: Notez, dans votre premier lien, comment les catégories sont réellement des singletons. Cela se fait au service du maintien de la légèreté, car la copie d'un pointeur vers un objet dont la suppression et la modification ne sont jamais garanties est bon marché, sans danger pour la mémoire et sans danger pour les threads.