Le C++ expressif n° 3 : pourquoi les erreurs de templates posent problèmes
Un article d'Eric Niebler traduit par Guillaume Belz
Le 2012-11-26 09:57:35, par gbdivers, Inactif
Bienvenue dans le troisième article de la série « le C++ expressif », une série d'articles consacrés aux Domain-Specific Embedded Language (DSEL) et à Boost.Proto, une bibliothèque pour les implémenter en C++.
Dans cet article, Eric Niebler aborde le problème délicat des messages d'erreurs générés par les templates et surtout le fait que ce n'est pas une fatalité. Il insiste en particulier sur le fait qu'il est de la responsabilités des concepteurs de bibliothèques de faire en sorte que les messages d'erreurs soient compréhensibles par les utilisateurs.
Le C++ expressif n° 3 : pourquoi les erreurs des templates posent des problèmes et qu'est-ce que vous pouvez faire pour ça ?
Retrouvez l'ensemble des articles de la série « Le C++ expressif » sur la page d'index.
Dans cet article, Eric Niebler aborde le problème délicat des messages d'erreurs générés par les templates et surtout le fait que ce n'est pas une fatalité. Il insiste en particulier sur le fait qu'il est de la responsabilités des concepteurs de bibliothèques de faire en sorte que les messages d'erreurs soient compréhensibles par les utilisateurs.
Le C++ expressif n° 3 : pourquoi les erreurs des templates posent des problèmes et qu'est-ce que vous pouvez faire pour ça ?
Retrouvez l'ensemble des articles de la série « Le C++ expressif » sur la page d'index.
-
FreemMembre émérite
Pensez-vous que la compléxité de message d'erreurs générés par les templates sont un frein à leurs utilisation ?
100 fois OUI.
Une erreur dans l'usage d'un template avec G++ va générer des dizaines de lignes d'erreurs, qui dépassent largement les 80 caractères. Comprendre: il faut scroller, et pas qu'un peu.
Sachant que la plus grosse partie de ces fameuses erreurs résulte dans le fait d'afficher les paramètres de chaque template. Y compris ceux par défaut (qu'on à donc pas changé et donc dont on se cogne).
Exemple concret:
std::unique_ptr prends 2 paramètres: le type, et la fonction de nettoyage. La fonction de nettoyage par défaut utilisant elle-même un type template utilisant le 1er template, on se retrouve vite avec un truc immonde et illisible.
Idem pour les implémentations, elles sont généralement proprement imbuvables, même si à force je commence à comprendre vaguement comment ça marche.
Bon, c'est sûr, une fois que c'est compilé, ça marche bien...Quelles techniques utilisez-vous pour générer des messages d'erreurs compréhensibles ?
A la main malheureusement: je copie le message d'erreur et je vire tous les paramètres auxquels je n'ai pas touchés dans le code. Ca divise la taille du message par 3 minimum et c'est directement plus lisible.
Mais je vais lire cet article et voir si le résultat est bon. Si c'est le cas, je me ferais un plaisir d'oublier ma vieille "méthode"...
[edit]ça s'appelle une tilde.C'est le petit tiret [...]
Suggestions:
Remplacer les occurrences de C++0x par C++11même si vu que c'est une traduction d'un article pré-C++11, il est logique de conserver C++0x.
Le lien vers "l'article précédent" renvoie à la description de l'article. Boucle infinie neuronale? Bon, certes, cette description contiens un lien vers une sorte de sommaire, mais bon, tant qu'a faire, autant faire un vrai lien, ou ne pas mettre de lien à ce moment la.le 30/11/2012 à 11:26 -
gbdiversInactifAttention, le propos n'est pas trouver une méthode pour comprendre un message d'erreur abscons, mais de modifier les messages d'erreurs générés.
Un exemple, pour être plus clair (provenant de Boost.Concept)
Si on prend un tableau de complexe et que l'on essaie de le trier :
On va avoir le message d'erreur suivant dans gcc :Code : 1
2std::vector<std::complex<float> > v; std::stable_sort(v.begin(), v.end());
Ce qui n'aide pas./usr/include/c++/4.1.2/bits/stl_algo.h: In function ‘void std::
__insertion_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator
/usr/include/c++/4.1.2/bits/stl_algo.h:3066: instantiated from ‘void
std::__inplace_stable_sort(_RandomAccessIterator,
_RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx:: __normal_iterator
/usr/include/c++/4.1.2/bits/stl_algo.h:3776: instantiated from ‘void
std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator
bad_error_eg.cpp:8: instantiated from here
/usr/include/c++/4.1.2/bits/stl_algo.h:2277: error: no match for
‘operator<’ in ‘__val < __first. __gnu_cxx::__normal_iterator<
_Iterator, _Container>::operator* [with _Iterator = std::complex*, _Container = std::vector > >]()’
Alors qu'il suffit d'ajouter un assert adéquate pour générer un message compréhensible. Par exemple (pas sur du tout de mon code...) :
Et il serait ainsi possible de tester les différentes conditions d'utilisation de stable_sort pour générer des messages d'erreurs compréhensibles.Code : static_assert(Less<T>, "T must be Less comparable");
le 30/11/2012 à 11:49 -
koala01Expert éminent séniorSalut,Un grand merci pour cette traduction qui m'a ouvert les yeux sur un océan de possibilités
C'est une véritable horreur, même si, à la longue, on finit par arriver à les décrypter, cela nécessite le plus souvent un copier coller dans un éditeur de texte "correct" et une bonne mise en forme.Pensez-vous que la compléxité de message d'erreurs générés par les templates sont un frein à leurs utilisation ?
Si les implémenteurs de la STL pouvaient s'organiser pour les rendre moins complexes, j'en serais ravi
Dans un projet preso qui est clairement orienté C++11, j'use et j'abuse de static_assert, et ca devient un véritable plaisir.Quelles techniques utilisez-vous pour générer des messages d'erreurs compréhensibles ?
Dans des projets plus anciens, je fais "avec", en fonction de ce que le projet permetle 30/11/2012 à 14:01 -
ternelExpert éminent séniorJ'avais un script pour reformater ces messages d'erreurs, que je pipais aux compilations. Sauf que je l'ai perdule 30/11/2012 à 14:26