Discussion :

[Matthieu Brucher]

J'ai constaté que les classes d'itérateurs telles que random_access_iterator n'étaient apparemment pas dans le standard, même si elles sont sur le site de la STL chez SGI. Apparemment, on utilise des tag à la place. La question à 0€ est comment changer un code qui utilisait ces classes, et pourquoi ont-elles été supprimées ?

[Médinoc]

[pas une réponse, j'en sais rien]
Que veux-tu dire par des tag ?

[Matthieu Brucher]

on utilise des random_access_iterator_tag à la place des random_access_iterator

[Charlemagne]

J'ai toujours vu que des implémentations avec des iterator_tag. Mes propres itérateurs utilisent ces tags.
Sans avoir cherché, j'ai jamais rien vu d'autre pour différiencier les types d'itérateurs.
Il me semble que les tags sont dans le standard, et il me semble bien les avoir vu dans le livre de Stroustrup.

Donc je vois pas où est ton problème.

[loufoque]

La documentation de la STL de SGI n'est pas la documentation de la bibliothèque standard.

[Matthieu Brucher]

J'ai toujours vu que des implémentations avec des iterator_tag. Mes propres itérateurs utilisent ces tags.
Sans avoir cherché, j'ai jamais rien vu d'autre pour différiencier les types d'itérateurs.
Il me semble que les tags sont dans le standard, et il me semble bien les avoir vu dans le livre de Stroustrup.

Donc je vois pas où est ton problème.

En fait, j'ai du code où le gars n'utilise pas les tags, même s'il se disait un fervent adhérent au standard... Et ça cause des problème parce qu'il faut faire des macros pour contourner le pb...
Et avec les tag, ça donne quoi comme type de code ? C'est pas de l'héritage, j'imagine, que l'on fait ?

[Charlemagne]

A ma connaissance les tags ne servent qu'à faire des "aiguillages".
C'est comme ça par exemple que la STL applique les algorithmes spécialisés à l'un des 5 types d'itérateur (random, unidirectionnel, bidirectionnel, input, output) comme pour l'algorithme d' "advance", en appelant des fonctions auxiliaires surchargées.

Quelque chose du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
template<class inIt, class Dist,class ItType> void aux_advance(InIt &it, Dist n, ItType             ) {...}
template<class inIt, class Dist             > void aux_advance(InIt &it, Dist n, random_iterator_tag) {...}
 
template<class InIt, class Dist> void advance(InIt &it, Dist n)
{
  aux_advance(it,n,typepename iterator_traits<InIt>::iterator_category());
}

[JolyLoic]

Bin, si....

Extrait du standard (la dernière ligne de l'exemple est la plus importante) :

It is often desirable for a template function to find out what is the most specific category of its iterator argument, so that the function can select the most efficient algorithm at compile time. To facilitate this, the library introduces category tag classes which are used as compile time tags for algorithm selection. They are: input_iterator_tag, output_iterator_tag, forward_iterator_tag, bidirectional_iterator_tag and random_access_iterator_tag. For every iterator of type Iterator, iterator_traits<Iterator>::iterator_category must be defined to be
the most specific category tag that describes the iterator’s behavior.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
namespace std {
struct input_iterator_tag {};
struct output_iterator_tag {};
struct forward_iterator_tag: public input_iterator_tag {};
struct bidirectional_iterator_tag: public forward_iterator_tag {};
struct random_access_iterator_tag: public bidirectional_iterator_tag {};
}

2 [Example: For a programdefined iterator BinaryTreeIterator, it could be included into the bidirectional iterator category by specializing the iterator_traits template:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
template<class T> struct iterator_traits<BinaryTreeIterator<T> > {
typedef ptrdiff_t difference_type;
typedef T value_type;
typedef T* pointer;
typedef T& reference;
typedef bidirectional_iterator_tag iterator_category;

};
Typically, however, it would be easier to derive BinaryTreeIterator<T> from
iterator<bidirectional_iterator_tag,T,ptrdiff_t,T*,T&>. —end example]

[Charlemagne]

Typically, however, it would be easier to derive BinaryTreeIterator<T> from iterator<bidirectional_iterator_tag,T,ptrdiff_t,T*,T&>

Sauf que, contre toute attente, les types issus d'un template ne sont pas dérivés. Enfin d'après le standard que GCC suit malheureusement aveuglément et à la lettre. Nombreux sont les compilos qui n'en tiennnent pas compte. C'est l'un des plus grand grief que j'ai contre le standard C++. J'ai jamais su la raison.

En toute rigueur il faut écrire qqch du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
template<class T>
class BinaryTreeIterator<T> : public iterator<bidirectional_iterator_tag,T,ptrdiff_t,T*,T&>
{
  typedef iterator<bidirectional_iterator_tag,T,ptrdiff_t,T*,T&> base;
 
  typedef typename base::ptrdiff_t difference_type;
  typedef typename base::value_type value_type;
  typedef typename base::pointer pointer;
  typedef typename base::reference reference;
  typedef typename base::iterator_category iterator_category;
...
};

[Matthieu Brucher]

OK, merci pour ces infos, je vais tenter d'utiliser ça... Pas gagné

[Matthieu Brucher]

Je me suis replongé dans ce code, et en fait, c'est assez facile à corrigé, donc merci pour l'aide que vous m'avez apporté !