Classe "implicite" d'un itérateur

[Dominique MICOLLET]

Bonjour

J'ai un doute dans ma compréhension de la déclaration d'un itérateur dans la
situation suivante :

class A : public vector <B>
{
......
void C();
}

void A:C()
{
....
const_iterator I=begin(); //cbegin() en C++11
.....
}

Suis-je dans l'erreur en considérant que I est implicitement déclaré comme
A::const_iterator I et qu'il équivaut à un vector<B>::const_iterator ?

Cordialement
Dominique

[Lucas Levrel]

Post by Dominique MICOLLET
class A : public vector <B>
{
......
void C();
}
void A:C()
{
....
const_iterator I=begin(); //cbegin() en C++11
.....
}
Suis-je dans l'erreur en considérant que I est implicitement déclaré comme
A::const_iterator I et qu'il équivaut à un vector<B>::const_iterator ?

Vive « auto » !

[Dominique MICOLLET]

Bonjour,

Vive « auto » !

Argh.... Moi qui enseigne à mes étudiants qu'il ne faut jamais laisser la
machine décider à votre place, je ne peux m'autoriser à user de ce mot-clef
dont j'ignorais jusqu'à l'existence. Pourquoi ne pas utiliser Windows tant
qu'à faire. :-)

Plus sérieusement, merci pour cette suggestion. Mais je cherche surtout à
comprendre ce que j'écris. Je suis phase d'apprentissage du C++.

Cordialement

Dominique.

[Marc Espie]

Post by Dominique MICOLLET
Bonjour,

Vive « auto » !

Argh.... Moi qui enseigne à mes étudiants qu'il ne faut jamais laisser la
machine décider à votre place, je ne peux m'autoriser à user de ce mot-clef

La machine ne decide rien a ta place, hein. C'est bien toi qui a ecrit
la valeur d'initialisation. Elle se coltine juste un calcul (de type) a
ta place. C'est son boulot, non ?

Perso, je considere qu'il faut mettre auto presque partout ou c'est
possible. Deja parce que std::vector<int>::const_iterator, c'est de
nature a faire fuir le debutant (et le moins debutant), mais surtout
parce que ca evite de faire des coercions de valeur sans faire expres.

Genre, je prefere infiniment

auto d = 5.2;
a
float d = 5.2;

[Dominique MICOLLET]

Bonjour,

Post by Marc Espie
Genre, je prefere infiniment
auto d = 5.2;
a
float d = 5.2;

Certes. Mais si je veux un double ? ou un long double ? ou un long long
double ?
Je débute en C++, mais j'ai une longue expérience tant en production qu'en
pédagogie des loufoqueries induites par les "valeurs par défaut" en
informatique.

Je considère que se poser la question "quel est le type de cette variable"
est un moyen d'éviter des pièges.

Mais on est là dans le débat d'opinion et je conçois que d'autres aient une
perception et une expérience différentes.

Cordialement

Dominique

[Lucas Levrel]

Post by Dominique MICOLLET

Vive « auto » !

Argh.... Moi qui enseigne à mes étudiants qu'il ne faut jamais laisser la
machine décider à votre place, je ne peux m'autoriser à user de ce mot-clef
dont j'ignorais jusqu'à l'existence.

C'est du C++11.

Post by Dominique MICOLLET
Plus sérieusement, merci pour cette suggestion. Mais je cherche surtout à
comprendre ce que j'écris. Je suis phase d'apprentissage du C++.

Je l'utilise uniquement pour des itérateurs ou des trucs similaires
(valeur de retour d'une fonction membre d'une classe de la STL), parce que
je trouve leur type très indigeste, et faire un typedef juste pour un
itérateur...

Dans ce cas précis je trouve que ça clarifie le code et ne risque pas
d'introduire des erreurs.

Note que je ne suis pas informaticien. J'utilise le C++ un peu comme du «
C with classes », et j'apprends sur le tas (donc sans doute un peu de
travers). Du coup j'ai un point de vue plutôt pragmatique !

Un site que je trouve très utile, notamment pour sa « Standard C++ Library
reference » : www.cplusplus.com

[Dominique MICOLLET]

Bonjour,

Post by Lucas Levrel
Note que je ne suis pas informaticien. J'utilise le C++ un peu comme du «
C with classes », et j'apprends sur le tas (donc sans doute un peu de
travers). Du coup j'ai un point de vue plutôt pragmatique !

Yo Brother :-)

Je suis dans la même situation. Toutefois je percois de plus en plus que je
passe à coté de fonctionnalités puissantes du C++ et qu'il faut que je
comprenne mieux comment tout cela s'articule. Quelque part, je n'apprécie
pas que ce soit la machine qui me domine :-).

Post by Lucas Levrel
Un site que je trouve très utile, notamment pour sa « Standard C++ Library
reference » : www.cplusplus.com

Je m'en sert effectivement très souvent.

Par ailleurs, je "potasse" en ce moment :
http://www.icce.rug.nl/documents/cplusplus/
C'est un cours dont le début est très prometteur.

Cordialement

Dominique

[Lucas Levrel]

Post by Dominique MICOLLET
http://www.icce.rug.nl/documents/cplusplus/
C'est un cours dont le début est très prometteur.

Merci pour cette référence.

[Jean-Marc Bourguet]

Post by Dominique MICOLLET
Bonjour,

Vive « auto » !

Argh.... Moi qui enseigne à mes étudiants qu'il ne faut jamais laisser la
machine décider à votre place, je ne peux m'autoriser à user de ce mot-clef
dont j'ignorais jusqu'à l'existence.

Entre auto et hériter publiquement d'une classe comme vector<> qui n'a
pas été conçue pour, je sais ce que je préfèrerais qu'on enseigne à ceux
qui voudraient devenir mes collègues. ;-)

Craindre auto me fait penser aux programmeurs C qui craignent les
paramètres références non constantes.

A+

[Dominique MICOLLET]

Bonjour,

Post by Jean-Marc Bourguet
Entre auto et hériter publiquement d'une classe comme vector<> qui n'a
pas été conçue pour, je sais ce que je préfèrerais qu'on enseigne à ceux
qui voudraient devenir mes collègues. ;-)

Rassurez-vous, je n'enseigne pas le C++ :-).

Plus sérieusement, pourriez-vous développer votre réticence quant à
l'héritage public de vector ?

Post by Jean-Marc Bourguet
Craindre auto me fait penser aux programmeurs C qui craignent les
paramètres références non constantes.

Je n'ai pas compris.

Cordialement

Dominique.

[Jean-Marc Bourguet]

Post by Dominique MICOLLET
Bonjour,

Post by Jean-Marc Bourguet
Entre auto et hériter publiquement d'une classe comme vector<> qui n'a
pas été conçue pour, je sais ce que je préfèrerais qu'on enseigne à ceux
qui voudraient devenir mes collègues. ;-)

Rassurez-vous, je n'enseigne pas le C++ :-).
Plus sérieusement, pourriez-vous développer votre réticence quant à
l'héritage public de vector ?

Les cas où c'est sensé sont l'exception plutôt que la règle. En
général, l'héritage public concerne les classes entité (pas copiable,
présence de fonctions virtuelles) et pas les classes valeur (copiable,
absence de fonctions virtuelles). vector est clairement dans la seconde
catégorie.

L'héritage public de classes valeur est généralement un héritage de
convenance, de facilité, pas un héritage qui résulte de critères de
conception. La question de fond est de savoir quelles sont les
invariants que la classe peut bien avoir qu'il n'est pas possible de
mettre à mal en la manipulant comme un vecteur? Si des invariants sont
à risque, l'héritage public est clairement une mauvaise idée. Si aucun
invariant est à risque, on se demande ce que la classe apporte
(complèter une API perçue comme incomplète en ignorant le risque de
faire une classe n'a pas une responsabilité claire est la raison la plus
valable).

L'exemple classique de problèmes introduits par l'héritage public de
classes sans destructeur virtuel est bien sûr la possibilité de faire

classe_de_base* p = new classe_derivee;
delete p;

qui est du comportement indéfini. Il convint mal, les classes valeur
n'étant normalement pas gérées comme ça, l'argument perd en poids ce
qu'il a gagné en étant applicable systématiquement. Quand on connait
les classes, construire des cas plus pertinents est généralement
possible, et quand ce n'est pas le cas, on est dans les cas
exceptionnels où l'héritage est sensé.

Post by Dominique MICOLLET

Post by Jean-Marc Bourguet
Craindre auto me fait penser aux programmeurs C qui craignent les
paramètres références non constantes.

Je n'ai pas compris.

Il y a des programmeurs C qui trouvent qu'en C++

void f(int& p) { ... modifie p ... }

n'est pas assez explicite et donc font

void f(int* p) { ... modifie *p ... }

Eviter auto parce que pas assez explicite me rappelle ces programmeurs.

Etre explicite ou pas est une question interessante, et que certains
tranchent un peu vite, dans les deux sens. Condamner d'office quelque
chose sans l'avoir experimente reellement, parce que pas assez explicite
me semble aussi nuisible que condamner d'office quelque chose parce que
trop explicite (j'en connais habitués à d'autres langages).

A+

[Lucas Levrel]

Post by Jean-Marc Bourguet
Les cas où c'est sensé sont l'exception plutôt que la règle. En
général, l'héritage public concerne les classes entité (pas copiable,
présence de fonctions virtuelles) et pas les classes valeur (copiable,
absence de fonctions virtuelles). vector est clairement dans la seconde
catégorie.

Peux-tu donner un exemple de classe entité ?

Post by Jean-Marc Bourguet
La question de fond est de savoir quelles sont les
invariants que la classe peut bien avoir qu'il n'est pas possible de
mettre à mal en la manipulant comme un vecteur?

Pas compris. Peux-tu détailler ?

Post by Jean-Marc Bourguet
(complèter une API perçue comme incomplète en ignorant le risque de
faire une classe n'a pas une responsabilité claire est la raison la plus
valable).

Syntax error :-)

[Jean-Marc Bourguet]

Post by Lucas Levrel

Post by Jean-Marc Bourguet
Les cas où c'est sensé sont l'exception plutôt que la règle. En
général, l'héritage public concerne les classes entité (pas copiable,
présence de fonctions virtuelles) et pas les classes valeur (copiable,
absence de fonctions virtuelles). vector est clairement dans la seconde
catégorie.

Peux-tu donner un exemple de classe entité ?

std::streambuf

Post by Lucas Levrel

Post by Jean-Marc Bourguet
La question de fond est de savoir quelles sont les invariants que la
classe peut bien avoir qu'il n'est pas possible de mettre à mal en la
manipulant comme un vecteur?

Pas compris. Peux-tu détailler ?

Si tu fais une classe vecteur_trie qui herite publiquement de vector et
qui essaie de faire en sorte de garder le vecteur trie, le fait que tu
peux acceder a la classe de base va te permettre de casser l'invariant
(le fait que le vecteur est trie)

Post by Lucas Levrel

Post by Jean-Marc Bourguet
(complèter une API perçue comme incomplète en ignorant le risque de
faire une classe n'a pas une responsabilité claire est la raison la plus
valable).

Syntax error :-)

Un principe de conception est qu'une classe doit avoir une
responsabilité claire et restreinte (certains disent meme unique --
personnellement j'ai un probleme de savoir ce qui est unique et ne l'est
pas). Completer l'API obscurcit souvent la responsabilite n'est pas
claire l'elargit (exemple de chose à ne pas faire, les classes string de
la SL ou de Qt font beaucoup trop de choses qui a mon avis ne relevent
pas de la responsabilite d'une classe mais devraient etre faites par des
fonctions libres).

A+

[Marc Espie]

En complement, et de facon bien moins technique: l'heritage public est LA
relation la plus forte qui peut exister entre deux classes. Il faut se
poser la question: si la classe de base change, est-ce qu'on veut heriter
de tout le nouveau comportement ? Si ce n'est pas le cas, c'est que
l'heritage public est une mauvaise idee, et qu'il faudrait utiliser un
autre schema (composition ou delegation le plus souvent).

Je sais que ca peut paraitre bizarre, pour vector, qui est dans la norme
et qui donc "change" peu (meme si il y a plein de trucs cools en C++2011)
mais c'est la vraie question a se poser...

A la base, l'objet c'est surtout cense permettre d'isoler l'utilisateur
final de changements intempestifs dans l'implementation. Et l'heritage
public "garantit" que l'utilisateur final va se palucher les changements
ET dans la classe derivee, ET dans la classe de base... c'est en meme temps
tres puissant et tres intrusif.

Perso, je n'herite plus guere que d'interfaces au sens java, des classes
qui ne contiennent que le comportement que je veux, et rien cote
implementation...

[Jean-Marc Bourguet]

Post by Marc Espie
Perso, je n'herite plus guere que d'interfaces au sens java, des classes
qui ne contiennent que le comportement que je veux, et rien cote
implementation...

Ça peut être difficile si on n'a pas écrit toutes les libs qu'ont
utilise. (Je pense à Qt p.e.)

A+

[Marc Espie]

Post by Marc Espie
Perso, je n'herite plus guere que d'interfaces au sens java, des classes
qui ne contiennent que le comportement que je veux, et rien cote
implementation...

Ça peut être difficile si on n'a pas écrit toutes les libs qu'ont
utilise. (Je pense à Qt p.e.)

Ouaip. Bien sur sur mon propre design.

Je trouve que Qt s'en sort pas trop mal, ils ont un design qu'est quand meme
un poil date ces jours-ci, mais qui marche encore relativement bien avec
du C++14...

[Jean-Marc Bourguet]

Post by Marc Espie

Post by Jean-Marc Bourguet

Post by Marc Espie
Perso, je n'herite plus guere que d'interfaces au sens java, des classes
qui ne contiennent que le comportement que je veux, et rien cote
implementation...

Ça peut être difficile si on n'a pas écrit toutes les libs qu'ont
utilise. (Je pense à Qt p.e.)

Ouaip. Bien sur sur mon propre design.
Je trouve que Qt s'en sort pas trop mal, ils ont un design qu'est quand meme
un poil date ces jours-ci, mais qui marche encore relativement bien avec
du C++14...

C'est daté, mais pas insupportable. Le pire, c'est moc et l'idée d'une
classe dont (presque) tout hérite, et le fait qu'ils ont une approche
framework plutôt que lib et donc une certaine tendance à tout lier.

A+

[Marc Espie]

Post by Jean-Marc Bourguet
C'est daté, mais pas insupportable. Le pire, c'est moc et l'idée d'une
classe dont (presque) tout hérite, et le fait qu'ils ont une approche
framework plutôt que lib et donc une certaine tendance à tout lier.

C'est clair que les classes de Qt qui reprennent toutes les classes de la STL, c'est
penible... je crains qu'on soit encore coince avec du C++98 pour un certain temps, alors
que pourtant QVariant, signal slots et consorts gagneraient beaucoup a etre reecrits sans
moc en 2011/2014...

[Lucas Levrel]

Post by Jean-Marc Bourguet
Completer l'API obscurcit souvent la responsabilite n'est pas
claire l'elargit

Trois verbes à la suite, j'ai un problème d'analyse syntaxique de cette
phrase :-)

Post by Jean-Marc Bourguet
(exemple de chose à ne pas faire, les classes string de la SL [...] font
beaucoup trop de choses qui a mon avis ne relevent pas de la
responsabilite d'une classe mais devraient etre faites par des fonctions
libres).

Est-ce que tu fais allusion aux fonctions copy, find, compare, substr de
la STL ?

[Jean-Marc Bourguet]

Post by Lucas Levrel

Post by Jean-Marc Bourguet
Completer l'API obscurcit souvent la responsabilite n'est pas
claire l'elargit

Trois verbes à la suite, j'ai un problème d'analyse syntaxique de cette
phrase :-)

C'est surtout qu'il y a quelque chose qui a dû rester dans mon esprit à
moins qu'une reformulation ait laissé un bout de phrase qui aurait dû être
virée. Réessayons:

Complèter une API obscurcit souvent la responsabilité de la classe en
élargissant la responsabilité au delà de ce qu'elle était à l'origine.

Post by Lucas Levrel

Post by Jean-Marc Bourguet
(exemple de chose à ne pas faire, les classes string de la SL [...] font
beaucoup trop de choses qui a mon avis ne relevent pas de la
responsabilite d'une classe mais devraient etre faites par des fonctions
libres).

Est-ce que tu fais allusion aux fonctions copy, find, compare, substr de la
STL ?

Oui. Et QString fait encore plus.

A+

[Jean-Marc Bourguet]

Post by Dominique MICOLLET
Bonjour
J'ai un doute dans ma compréhension de la déclaration d'un itérateur dans la
class A : public vector <B>
{
......
void C();
}
void A:C()
{
....
const_iterator I=begin(); //cbegin() en C++11
.....
}
Suis-je dans l'erreur en considérant que I est implicitement déclaré comme
A::const_iterator I et qu'il équivaut à un vector<B>::const_iterator ?

Plus précisément I est explicitement déclaré comme étant du type const_iterator trouvé
par une recherche dans le contexte courant. On va chercher dans A::C(),
il n'y a probablement rien, on va chercher dans A, il n'y a probablement
rien, on va chercher dans vector<B>, il y a probablement quelque chose.

Considérer qu'il y a un const_iterator déclaré implicitement déclaré
dans A fonctionne assez bien, mais décrit aussi peu la réalité
que de considérer qu'il y en a un implicitement déclaré dans A::C. Ça
fonctionne jusqu'au moment où on se trouve dans un cas où la recherche
s'arrête plus tôt (dans les templates par exemple), et celui qui a ce
modèle dans la tête ne comprend plus ce qui se passe.

A+

[Dominique MICOLLET]

Bonjour,

Post by Jean-Marc Bourguet
Plus précisément I est explicitement déclaré comme étant du type
const_iterator trouvé
par une recherche dans le contexte courant. On va chercher dans A::C(),
il n'y a probablement rien, on va chercher dans A, il n'y a probablement
rien, on va chercher dans vector<B>, il y a probablement quelque chose.

C'est bien comme cela que je le préssentais.

Post by Jean-Marc Bourguet
Considérer qu'il y a un const_iterator déclaré implicitement déclaré
dans A fonctionne assez bien, mais décrit aussi peu la réalité
que de considérer qu'il y en a un implicitement déclaré dans A::C. Ça
fonctionne jusqu'au moment où on se trouve dans un cas où la recherche
s'arrête plus tôt (dans les templates par exemple), et celui qui a ce
modèle dans la tête ne comprend plus ce qui se passe.

Je ne comprends pas votre remarque.

Le type const_iterator n'est pas défini dans A::C : le compilateur est bien
obligé de remonter la hierarchie jusqu'à en trouver un, et il me semble que
la norme en propose un dans "vector". J'ignore bien sûr s'il est dans
"vector" ou encore plus loin dans la hiérarchie, mais il me semble que ce
n'est pas important, puisque je veux un itérateur capable de parcourir le
"vector".

Cordialement

Dominique

[Jean-Marc Bourguet]

Post by Dominique MICOLLET
Bonjour,

Post by Jean-Marc Bourguet
Plus précisément I est explicitement déclaré comme étant du type
const_iterator trouvé
par une recherche dans le contexte courant. On va chercher dans A::C(),
il n'y a probablement rien, on va chercher dans A, il n'y a probablement
rien, on va chercher dans vector<B>, il y a probablement quelque chose.

C'est bien comme cela que je le préssentais.

Post by Jean-Marc Bourguet
Considérer qu'il y a un const_iterator déclaré implicitement déclaré
dans A fonctionne assez bien, mais décrit aussi peu la réalité
que de considérer qu'il y en a un implicitement déclaré dans A::C. Ça
fonctionne jusqu'au moment où on se trouve dans un cas où la recherche
s'arrête plus tôt (dans les templates par exemple), et celui qui a ce
modèle dans la tête ne comprend plus ce qui se passe.

Je ne comprends pas votre remarque.

Je chipote sur la nuance entre "I est implicitement déclaré comme
A::const_iterator I et équivaut à un vector<B>::const_iterator" et
"const_iterator est trouvé en effectuant une recherche dans le contexte
courant, recherche qui elle même remonte dans la hiérarchie".

Post by Dominique MICOLLET
J'ignore bien sûr s'il est dans "vector" ou encore plus loin dans la
hiérarchie

Il est des cas où la recherche ne remonte pas dans la hiérarchie et donc
ne peut pas trouver le const_iterator de vector. Les templates par
exemple. Ou bien dans le cas des fonctions, en trouver une à un niveau
va masquer les autres, même si elles conviendraient mieux.

Exemple avec un namespace (on peut faire avec deux classes A et B
héritant de A, je le montre avec des namespaces parce qu'on montre
généralement le problème avec des classes et que certains en concluent
incorrectement qu'il est lié aux classes)

namespace A {
void f(int) { std::cout << "A::f(int)\n"; }
namespace B {
void f(double) { std::cout << "A::B::f(double)\n"; }
void g() { f(42); }
}
}
int main() {
A::B::g();
}

affiche

A::B::f(double)

tandis qu'ajouter un

using A::f;

dans B permet d'afficher

A::f(int)

A+

[Dominique MICOLLET]

Bonjour,

Post by Dominique MICOLLET
J'ai un doute dans ma compréhension de la déclaration d'un itérateur dans

...

Post by Dominique MICOLLET
A::const_iterator I et qu'il équivaut à un vector<B>::const_iterator ?

À la lecture des différentes réponses, dont certaines très techniques, je me
rends compte que je manque cruellement de compétence en POO au niveau
théorique.

Quelqu'un aurait-il une référence à suggérer, au niveau débutant ou juste au
dessus, indépendante du langage de programmation mise en oeuvre pour
j'appronfondisse le paradigme ?

Cordialement

Dominique

[chuoiit14]

Post by Dominique MICOLLET
Bonjour
J'ai un doute dans ma compréhension de la déclaration d'un
itérateur dans la
class A : public vector <B>
{
......
void C();
}
void A:C()
{
....
const_iterator I=begin(); //cbegin() en C++11
.....
}
Suis-je dans l'erreur en considérant que I est implicitement
déclaré comme
A::const_iterator I et qu'il équivaut à un
vector<B>::const_iterator ?
Cordialement
Dominique

, This is a great article. It gave me a lot of useful information. thank yo
very much.