La classe de modèles std::iterator
est définie pour être obsolète en C ++17. Pourquoi C’est un moyen pratique de s’assurer que std::iterator_traits
fonctionne, en particulier si vous pouvez utiliser les arguments du modèle par défaut. Existe-t-il un autre moyen de le faire en C ++17?
Réponse
Trop de publicités?À partir de la proposition qui a suggéré son autodérision:
Comme une aide à l'écriture itérateur classes, l'original de la bibliothèque standard fourni la classe iterator modèle pour automatiser la déclaration des cinq typedefs attendus de chaque itérateur par iterator_traits. Ce fut ensuite utilisé dans la bibliothèque elle-même, par exemple dans le cahier des charges de l'
std::ostream_iterator
:template <class T, class charT = char, class traits = char_traits<charT> > class ostream_iterator: public iterator<output_iterator_tag, void, void, void, void>;
La longue séquence de
void
arguments est beaucoup moins clair pour le lecteur que de simplement fournir des attendus typedefs dans la définition de la classe elle-même, qui est l'approche adoptée par l'actuel projet de travail, suivant le modèle défini en C++14, où nous obsolète la dérivation dans la bibliothèque de foncteurs deunary_function
etbinary_function
.En plus de la réduction de la clarté, de l'itérateur modèle met aussi un piège pour les imprudents, comme dans une utilisation normale, il sera dépendant de la classe de base, ce qui signifie qu'il ne sera pas être à la recherche lors de la recherche d'un nom à partir de l'intérieur de la classe ou de ses fonctions de membre. Cela conduit à surpris les utilisateurs à essayer de comprendre pourquoi les suivantes utilisation simple ne fonctionne pas:
#include <iterator> template <typename T> struct MyIterator : std::iterator<std::random_access_iterator_tag, T> { value_type data; // Error: value_type is not found by name lookup // ... implementations details elided ... };
La raison de clarté, seul était suffisant pour convaincre confiées au groupe de travail pour la mise à jour de la bibliothèque standard de spécification de ne plus mandat de la norme itérateur adapators comme dérivant d'
std::iterator
, donc il n'y a aucune autre utilisation de ce modèle dans la norme elle-même. Par conséquent, il ressemble à un candidat solide pour dépréciation.
Vous pouvez également voir STL raisonnement de LWG 2438. (h/t T. C.)
Comme pour une autre manière de faire, pas vraiment. Vous pourriez fondamentalement mettre en place votre propre version de std::iterator
(ce qui n'est pas trop dur) ou manuellement écrire tous ces typedefs (qui n'est pas trop dur non plus, et je préfère pour plus de clarté).