Le C++ expressif n° 3 : pourquoi les erreurs des templates posent des problèmes [Article]

[gbdivers]

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 ?

Pensez-vous que la compléxité de message d'erreurs générés par les templates sont un frein à leurs utilisation ?
Quelles techniques utilisez-vous pour générer des messages d'erreurs compréhensibles ?

Retrouvez l'ensemble des articles de la série « Le C++ expressif » sur la page d'index.

[Freem]

Envoyé par gbdivers

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 ?

Pensez-vous que la compléxité de message d'erreurs générés par les templates sont un frein à leurs utilisation ?
Quelles techniques utilisez-vous pour générer des messages d'erreurs compréhensibles ?

Retrouvez l'ensemble des articles de la série « Le C++ expressif » sur la page d'index.

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]

C'est le petit tiret [...]

ça s'appelle une tilde.

Suggestions:

Remplacer les occurrences de C++0x par C++11 mê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.

[gbdivers]

Attention, 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 :

Code :

1
2
std::vector<std::complex<float> > v;
std::stable_sort(v.begin(), v.end());

On va avoir le message d'erreur suivant dans gcc :

/usr/include/c++/4.1.2/bits/stl_algo.h: In function ‘void std::
__insertion_sort(_RandomAccessIterator, _RandomAccessIterator) [with
_RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float
>*, std::vector<std::complex<float>, std::allocator<std::complex<
float> > > >]’:
/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<std::complex<float>*, std::vector<std::complex<
float>, std::allocator<std::complex<float> > > >]’
/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<std::complex<float
>*, std::vector<std::complex<float>, std::allocator<std::complex<
float> > > >]’
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<float
>*, _Container = std::vector<std::complex<float>, std::allocator<
std::complex<float> > >]()’

Ce qui n'aide pas.

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...) :

Code :

static_assert(Less<T>, "T must be Less comparable");

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.

[koala01]

Salut,

Envoyé par gbdivers

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 ?

Un grand merci pour cette traduction qui m'a ouvert les yeux sur un océan de possibilités

Pensez-vous que la compléxité de message d'erreurs générés par les templates sont un frein à leurs utilisation ?

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.

Si les implémenteurs de la STL pouvaient s'organiser pour les rendre moins complexes, j'en serais ravi

Quelles techniques utilisez-vous pour générer des messages d'erreurs compréhensibles ?

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.

Dans des projets plus anciens, je fais "avec", en fonction de ce que le projet permet

[leternel]

J'avais un script pour reformater ces messages d'erreurs, que je pipais aux compilations. Sauf que je l'ai perdu