Question d'entretien sur les itérateurs

Bonjour

J'ai eu comme question en entretien la question suivante:

considérons un itérateur iter sur un vecteur par exemple.

Quelle est la différence entre iter++ et ++iter?
Que vaut-il mieux faire entre les deux cas ?

Je n'ai pas su répondre. Alors comme c'est une question qui revient souvent, j'aimerais bien savoir quoi dire.



Merci

Bonjour,

la différence est celle qu'il y a entre la pré et la post incrémentation. J'avais lu quelque part que les compilos optimisaient pareil pour les types de base (int, ...) mais avaient plus de mal pour des types plus complexes comme les itérateurs.

Lorsque l'on fait une post-incrémentation, il y a une copie de la variable qui est faite, alors que pas en pré-incrémentation. Donc dans ce cas je pense qu'il faut plutôt faire ++iter.

Voilà, je ne suis pas sûr à 100% de ce que j'avance, je vais essayer de retrouver l'article ...

EDIT : ha ben en fait y'a un article dans la FAQ : http://cpp.developpez.com/faq/cpp/?p...GE_rapidite_pp
La différence ne semble pas énorme ...

Ha oui et ce serait possible d'avoir le nom de la boite où tu as passé l'entretien ?

Bonjour,

A vrai dire un i++ ou ++i sont équivalents si le résultat n'est pas utilisé. Après un ++i va permettre éventuellement d'économiser un peu de mémoire car on n'a plus besoin de stocker la valeur de i (itérateur ou entier même combat).
Apres c'est peut etre un peu HS pour ce thread mais la FAQ m'a fait réagir.. ++i n'est pas toujours supérieur à i++ ! Mais à vrai dire je pense qu'il n'y à qu'un cas où c'est faux : array[++i] et array[i++]. Le premier cas (i++) ne peut etre que plus efficace car le calcul de l'adresse du tableau n'a pas besoin d'attendre celle de i.

Citation:

---

Envoyé par Idwakest

Mais à vrai dire je pense qu'il n'y à qu'un cas où c'est faux : array[++i] et array[i++]. Le premier cas (i++) ne peut etre que plus efficace car le calcul de l'adresse du tableau n'a pas besoin d'attendre celle de i.

---

Dans ce cas, chercher le plus rapide n'a que peu de sens puisque le comportement n'est pas le même dans les deux cas.

Citation:

---

Envoyé par gl

Dans ce cas, chercher le plus rapide n'a que peu de sens puisque le comportement n'est pas le même dans les deux cas.

---

Et en décalant l'indice de 1 dans une boucle par exemple ??

Citation:

---

Envoyé par Idwakest

Et en décalant l'indice de 1 dans une boucle par exemple ??

---

Pardon ? Peux-tu préciser ce que tu entends par là ?

Je sais bien que cela a bien peu d'intérêt au final (voire même aucun) :D mais ce que je voulais dire c'est qu'au lieu de faire

Code:

---

for (int i = -1; i < val;) array[++i] = 42;

---

on peut faire

Code:

---

for (int i = 0; i < val + 1;) array[i++] = 42;

---

Au final ces 2 boucles produisent le même résultat.

Au final, en mode release, avec un bon compilateur, cette boucle sera sauvagement optimisée et il n'y aura aucune différence.

Salut,

Citation:

---

Envoyé par 3DArchi

Au final, en mode release, avec un bon compilateur, cette boucle sera sauvagement optimisée et il n'y aura aucune différence.

---

Tout à fait, mais, suis-je le seul à considérer le fait de ne pas donner la troisième expression (celle du pas) dans une boucle for comme une hérésie :question:

Après tout, il est tout à fait possible de faire

Code:

---

for(int i=0;i<val;++i)array[i]=/*...*/ ;

---

Et Ce n'est pas vraiment pour le temps que prend l'écriture d'un caractère en plus (le i rajouté entre les crochets) qui fera prendre un retard insurmontable au projet :P :question:

Il ne faut pas oublier que le but même de la boucle for est de fournir un "compteur" avec une borne de départ, une borne de fin, et un pas tendant à relier les deux ;)

Je sais que même stroutroup conseille volontiers les boucles proches de

Code:

---

for( ; ; )

---

mais je ne suis vraiment pas de son avis sur ce coup là :aie:

Citation:

---

Envoyé par koala01

suis-je le seul à considérer le fait de ne pas donner la troisième expression (celle du pas) dans une boucle for comme une hérésie :question:

---

Disons, que boucler de [-1;val[ ou de [0;val+1[, je trouve déjà ça discutable ([0;len[ est plus 'usuel'). Idwakest a donné cet exemple maladroit mais je pense qu'il cherchait un exemple où ça aurait eu un intérêt. Et comme dit gl, ou ça n'a pas d'intérêt, ou ça fait la même chose.

pour expliquer mon post, on m'a posé cette question:
vaut il mieux utiliser:

Code:

---

1 2 3 4 5

vector<double> T(3); iterator<double> it;   for(it=T.begin();it<=T.end();it++){...}

---

ou:

Code:

---

1 2 3 4 5

vector<double> T(3); iterator<double> it;   for(it=T.begin();it<=T.end();++it){...}

---

j'avoue je ne sais pas la différence

Bonjour,

un peu comme il a été dit plus haut cela ne change pas grand chose a partir du moment ou le résultât de la pre/post incrémentation n'est pas utilisé

par contre le test <= est très bizarre car lorsque end est atteint on est en dehors du vecteur

Citation:

---

Envoyé par bruno_pages

par contre le test <= est très bizarre car lorsque end est atteint on est en dehors du vecteur

---

Pareil. J'ai plus tendance à utiliser != pour ce test personnellement

Le mec que j'ai eu en entretien m'a dit que si on faisait ++it,
dans la boucle for que j'ai donnée, le risque était donc de louper le premier élément.

Cela m'a un peu embrouillé. C'est ce qu'il se passe d'ailleurs quand on est dans un entretien et que l'on a affaire à un mec qui ne s'y connait pas vraiment en profondeur.

Autre exemple:
Dans cet entretien, je suis tombé sur le code suivant qu'il m' a donné.
J'ai essayé de lui expliquer que faire qqch comme cela:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class A{ private: int a; public: void afficher(){ cout<"...",} };   class B:public A{ private: int b; public: void afficher(){ cout<"...",} };

---

c'était pas bien, car on va redéfinir une fonction non virtuelle, et violer la relation "EST UN".

Citation:

---

Envoyé par myzu69

Ha oui et ce serait possible d'avoir le nom de la boite où tu as passé l'entretien ?

---

Hum, je plussoie la question là. C'est choquant le truc de l'itérateur :o

oui, qu'on y aille pas par erreur.

non mais n'importe quoi, le mec qui pose une question un peu idiote et qui se trompe dans la réponse.. ou alors c'est fait exprès pour savoir ce que tu dis, mais c'est un peu bête dans l'entretient

Citation:

---

Envoyé par deubelte

Le mec que j'ai eu en entretien m'a dit que si on faisait ++it,
dans la boucle for que j'ai donnée, le risque était donc de louper le premier élément.

---

Héhé, il ne te reste qu'à envoyer ton CV au boss du gars qui t'a fait passer l'entretien, en lui expliquant qu'il ferait bien de relever un peu le niveau de son équipe :twisted:

En même temps, le recruteur l'a peut être fait exprès.
Je me mets à sa place : je dis une énorme connerie. Le candidat ne réagit pas. Bon, bah... dehors ! :aie: :lol:

deubelte, j'ai une question pour toi:
T'as pas l'impression de mettre un peu la charrue avant les boeufs parfois ? J'ai reparcouru quelques posts à toi, et j'y ai trouvé des trucs hyper techniques genre :

• Comment se passe réellement l'allocation mémoire ? voir ICI
• Qu'est ce qu'une sémantique ? Pendant un de tes autres entretiens où tu sembles répondre des choses que tu ne comprends pas : voir ICI

Et là, devine quoi, je tombe sur un post où tu demandes spécifiquement quelle est la différence entre la post et la pré incrémentation : voir ICI 8O

Y'a comme un problème, tu ne trouves pas ?

Citation:

---

Y'a comme un problème, tu ne trouves pas ?

---

Je sais, mais étant donné que j'apprends par moi-même le C++, tout vient un peu en même temps tu comprends. Alors c'est pour cela.

L'apprentissage par soi même ne peut pas être linéaire. Surtout qqch comme le C++ qui demande des connaissances en langage mais aussi en informatique plus générale

Citation:

---

Héhé, il ne te reste qu'à envoyer ton CV au boss du gars qui t'a fait passer l'entretien, en lui expliquant qu'il ferait bien de relever un peu le niveau de son équipe

---

Lol, ce sera difficile, c'était justement le boss de la boîte.
Etant donné le nombre de personnes qui doivent coder en C++ sans vraiment avoir le niveau, je n'imagine pas ce que l'on doit trouver comme erreurs/bug dans les dev C++ des entreprises.

Citation:

---

L'apprentissage par soi même ne peut pas être linéaire. Surtout qqch comme le C++ qui demande des connaissances en langage mais aussi en informatique plus générale

---

Je suis autodidacte et ca été (dans l'ensemble) très linéaire même si c'est encore loin d'être fini (et là je reconnais que c'est moins linéaire du coup :p ).

Sinon, il suffit d'avoir les bons livres. Je te conseille en particulier Accelerated C++

Pareil. Entièrement autodidacte de A à Z, grâce à developpez et aux bons livres!

Tu as l'air d'avoir quelques bons bouquins, tu es actif sur DVP, reste une dernière question : tu codes ? Je veux dire tu fais des projets perso sur un thème qui te plait ? Ca aide beaucoup ça aussi, de mettre réellement les mains dans le camboui ! :D

Citation:

---

tu codes ?

---

Pas (encore) de façon professionnelle.

Mais disons, que j'apprends, et en C++, il y a pas mal de choses, et je suis loin d'avoir fait le tour. Je préfère avoir une bonne connaissance de base et couvrir un large domaine, pour éviter d'avoir des surprises par la suite.

Jusqu'à maintenant, j'ai appris le C++ pour mettre cela sur mon CV.

Euh, tu réponds un peu à côté de ma question :

Citation:

---

Envoyé par poukill

Je veux dire tu fais des projets perso sur un thème qui te plait ?

---

Citation:

---

Envoyé par deubelte

c'était pas bien, car on va redéfinir une fonction non virtuelle, et violer la relation "EST UN".

---

Effectivement, c'est pas bien car on aura un comportement qui n'est pas forcément celui attendu. En revanche, je ne dirais pas pour autant qu'on viole pour autant la relation 'EST-UN'.

Citation:

---

Envoyé par poukill

Euh, tu réponds un peu à côté de ma question :

---

Je plussoie : lire des bouquins/cours/articles c'est bien mais ce n'est pas suffisant. A un moment, il faut pratiquer en commençant par de petit projet pas trop ambitieux (pour ne pas se perdre) et ensuite essayer d'aller vers des choses plus évoluées.

Citation:

---

Euh, tu réponds un peu à côté de ma question :

---

Alors, je ne code pas de projet. Juste du programme pour apprendre ce que je lis.

Citation:

---

Envoyé par Idwakest

Je sais bien que cela a bien peu d'intérêt au final (voire même aucun) :D mais ce que je voulais dire c'est qu'au lieu de faire

Code:

---

for (int i = -1; i < val;) array[++i] = 42;

---

on peut faire

Code:

---

for (int i = 0; i < val + 1;) array[i++] = 42;

---

Au final ces 2 boucles produisent le même résultat.

---

En complément des réponses qui t'ont déjà été donné : sur un compilateur récent et correct, il ne devrait pas y avoir de différence en terme de performance entre la pré-incrémentation et la post-incrémentation d'un entier (ni d'ailleurs d'un autre type primitif).

La différence se fait sentir sur des objets dont la copie est couteuse.

Citation:

---

Envoyé par deubelte

Alors, je ne code pas de projet. Juste du programme pour apprendre ce que je lis.

---

Ok c'est bien ce que je pensais. C'est là que la bât blesse. C'est comme le mec qui apprend la technique parfaite de la natation dans les bouquins... pis qui va pas dans l'eau...
Y'a un moment faut y aller.

Plus sérieusement, depuis le début tu apprends des trucs dans un ordre aléatoire sans but à atteindre (si, le CV mais c'est pas un but en soi) et surtout sans les mettre vraiment en pratique. Ça ne m'étonne pas plus que ça que tu les retiennes pas (cf l'exemple sur ++i et i++). En plus, le jour ou tu seras confronté à de gros projets, tu seras tout démuni. Parce qu'il y a quand même une petite différence entre la théorie et la pratique. Ton code ne sera pas toujours un parfait exemple de pattern. Du coup, toutes ces questions d'entretien que tu as déjà posté sur DVP seront un peu plus facile à aborder. Suit le conseil de 3DArchi, commence petit, mais commence.

Pour moi, l'apprentissage est un subtil mélange de théorie et de pratique.

Citation:

---

Ton code ne sera pas toujours un parfait exemple de pattern. Du coup, toutes ces questions d'entretien que tu as déjà posté sur DVP seront un peu plus facile à aborder. Suit le conseil de 3DArchi, commence petit, mais commence.

---

Je comprends bien, mais je ne vois pas trop quoi faire. J'ai pas de projet à faire..:lol:

Citation:

---

Envoyé par poukill

Ok c'est bien ce que je pensais. C'est là que la bât blesse. C'est comme le mec qui apprend la technique parfaite de la natation dans les bouquins... pis qui va pas dans l'eau...
Y'a un moment faut y aller.

Plus sérieusement, depuis le début tu apprends des trucs dans un ordre aléatoire sans but à atteindre (si, le CV mais c'est pas un but en soi) et surtout sans les mettre vraiment en pratique. Ça ne m'étonne pas plus que ça que tu les retiennes pas (cf l'exemple sur ++i et i++). En plus, le jour ou tu seras confronté à de gros projets, tu seras tout démuni. Parce qu'il y a quand même une petite différence entre la théorie et la pratique. Ton code ne sera pas toujours un parfait exemple de pattern. Du coup, toutes ces questions d'entretien que tu as déjà posté sur DVP seront un peu plus facile à aborder. Suit le conseil de 3DArchi, commence petit, mais commence.

---

+1

Citation:

---

Pour moi, l'apprentissage est un subtil mélange de théorie et de pratique.

---

Sur ce point particulier par contre, tout en insistant sur la nécessité de la pratique, je ferais peut être une distinction entre deux écoles d'apprentissages qui peuvent être totalement opposées.

La première (qui est très (trop :question:) souvent rencontrée) consiste à vouloir apprendre la théorie de la programmation, ce que je pourrais appeler les "grands principes de la programmation" en se basant sur la connaissance (souvent naissante, vu que nous parlons d'une époque où... on n'a pas les base) un langage donné.

Le gros problème, c'est que cette école va, fatalement, biaiser l'apprentissage de ces grands principes, simplement parce qu'elle va "laisser de coté" toute la partie qui n'est pas prise en compte par le langage étudié.

Il est, par exemple, particulièrement frappant de constater que ceux qui ont appris l'Orienté Objet basé sur l'étude de java n'ont sans doute jamais entendu parler du principe de substitution de liskov ou de la loi demeter.

La deuxième école est bien plus avantageuse: elle consiste à avoir une approche basée sur les grands principes de la programmation, sans chercher à viser un quelconque langage particulier: une boucle ou un test restent une boucle ou un test, quelle que soit la manière dont il faut écrire une expression dans un langage particulier, tout comme une classe ou un membre reste une classe ou un membre en programmation objet, quelle que soit la manière dont on l'implémentera dans un langage.

Qu'il faille calculer une exponentielle ou la date de Pâques, qu'il faille développer un système de classe permettant de jouer au morpion ou un autre permettant de gérer les stocks d'une entreprise, le raisonnement suivi ne doit a priori pas être guidé par un langage particulier, et, au final, le résultat a donc de fortes chances d'être exploitable... dans n'importe quel langage :P

La pratique, à ce niveau là, cela consistera sans doute en beaucoup de réflexion, des tonnes de papiers et de crayons et des heures de "jeu de rôles", parfois très divertissantes d'ailleurs :D

Une fois que l'on a acquis ces grands principes, on se rend compte que la transformation en code se limite, peu ou prou, à... de la pure dactylographie, parce que l'apprentissage de n'importe quel langage se limite, à peu près, à l'apprentissage de la syntaxe, des mot clés, des fonctions et structures fournies par le langage et... des restrictions que le langage impose par rapport aux "principes généraux".

Evidemment, l'apprentissage "fin" du langage passera par... l'écriture de nombreuses lignes de code ;)

Citation:

---

Envoyé par deubelte

Je comprends bien, mais je ne vois pas trop quoi faire. J'ai pas de projet à faire..:lol:

---

Je sais pas pourquoi, mais ta réponse m'a rendu presque triste... :cry:
T'as pas la moindre idée de ce que tu pourrais faire? C'est navrant ! :calim2: Je sais pas moi : un jeu que t'as rencontré dans ta jeunesse, un truc innovant que t'avais en tête, ou un truc tout con que t'avais trouvé marrant. Perso, si j'avais le temps, j'aurai un tas de trucs à faire.

Citation:

---

Envoyé par Koala01

La deuxième école est bien plus avantageuse: elle consiste à avoir une approche basée sur les grands principes de la programmation, sans chercher à viser un quelconque langage particulier: une boucle ou un test restent une boucle ou un test, quelle que soit la manière dont il faut écrire une expression dans un langage particulier, tout comme une classe ou un membre reste une classe ou un membre en programmation objet, quelle que soit la manière dont on l'implémentera dans un langage.

---

Effectivement. Je suis complètement d'accord avec tout ce que tu dis. Mais là c'est un peu spécial, deubelte travaille des points précis (je l'ai déjà vu citer Exceptionnal C++ en étudiant certains items particuliers), mais il lui manque l'approche globale : on a un problème, à moi de trouver la solution. C'est un entraînement particulier. On est pas obligé de poster sur DVP à chaque fois qu'on rencontre un problème pour demander des avis. On peut aussi retrousser ses manches et mettre les mains dans le camboui. Ca s'appelle mettre en pratique ses connaissances, et prendre des initiatives.

Si je devais faire passer un entretien, je m'assurerai de deux choses:

• que le candidat aie des connaissances sur les "grands principes" comme tu le faisais remarquer Koala
• que le candidat sache les mettre en pratique (initiatives).

Si t'étudie l'architecture au sens génie civil pendant 10 ans mais que t'as jamais construit de maisons, ben attention les dégâts lors de la première construction. Tu tomberas dans plein d'embuches, de trucs de "terrains" pas prévus. Ça s'appelle le manque d'expérience.

Citation:

---

Envoyé par poukill

Effectivement. Je suis complètement d'accord avec tout ce que tu dis. Mais là c'est un peu spécial, deubelte travaille des points précis (je l'ai déjà vu citer Exceptionnal C++ en étudiant certains items particuliers), mais il lui manque l'approche globale : on a un problème, à moi de trouver la solution. C'est un entraînement particulier. On est pas obligé de poster sur DVP à chaque fois qu'on rencontre un problème pour demander des avis. On peut aussi retrousser ses manches et mettre les mains dans le camboui. Ca s'appelle mettre en pratique ses connaissances, et prendre des initiatives.

Si je devais faire passer un entretien, je m'assurerai de deux choses:

• que le candidat aie des connaissances sur les "grands principes" comme tu le faisais remarquer Koala
• que le candidat sache les mettre en pratique (initiatives).

Si t'étudie l'architecture au sens génie civil pendant 10 ans mais que t'as jamais construit de maisons, ben attention les dégâts lors de la première construction. Tu tomberas dans plein d'embuches, de trucs de "terrains" pas prévus. Ça s'appelle le manque d'expérience.

---

Nous sommes bien d'accord :D

Mais, ce que je veux faire passer comme message, c'est que la pratique, cela peut aussi ne pas forcément passer par l'écriture de lignes et de lignes de code.

La pratique, c'est, aussi, être capable de déléguer correctement les responsabilités et de pouvoir mettre en place une logique saine et... logique (c'est aussi des pratiques à acquérir :D).

La pratique, ca peut aussi s'acquérir (en partie du moins) en prenant la peine de prendre l'espace d'un moment la place du processeur afin de s'assurer que ce qui est effectué est à la fois correct et, dans une certaine mesure, "optimal".

L'avantage d'acquérir ce genre de pratique avant d'apprendre un langage particulier, c'est, justement, que l'on peut alors se concentrer sur les problèmes propres au langage par la suite ;)

Citation:

---

Envoyé par deubelte

Je comprends bien, mais je ne vois pas trop quoi faire. J'ai pas de projet à faire..:lol:

---

Consulte les pages sources, défis, tutoriels de n'importe quelle rubrique. Lis le titre, isole des petits morceaux et essaie de le faire par toi même. Tu peux aussi éplucher des questions dans le forum pour essayer de trouver des idées intéressantes. Il y a aussi la rubrique projet où tu peux trouver quelques idées. Ne te lance pas dans un truc trop gros dès le début, découpe en chose simple et avance peu à peu.

Citation:

---

Envoyé par deubelte

Je comprends bien, mais je ne vois pas trop quoi faire. J'ai pas de projet à faire..:lol:

---

Tu as les défis C et C++. Il y a même les solutions pour comparer ce que tu as fais avec les idées des autres.

En fait j'ai un peu exagéré. J'aurais bien sur des trucs à faire. Mais rien de bien compliqué.

Au départ, ce que je comptais faire, c'est étudier en profondeur la STL.
Alors j'ai commencé à étudier l'implémentation des containers. Ce qui ma amené à faire qqch comme:


On étudie l’itérateur back_insert_iterator. Il s’agit d’un itérateur output. Il a comme donnée membre qu’un pointeur sur un container.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

// TEMPLATE CLASS back_insert_iterator   template<class _Container> class back_insert_iterator: public _Outit{ Il hérite de l’itérateur Out. Il s’agit d’un itérateur Output.   public: typedef back_insert_iterator<_Container> _Myt; typedef _Container container_type; typedef typename _Container::const_reference const_reference; typedef typename _Container::value_type _Valty; On définit ici 4 types, dont deux sont dependants de template :   -_Myt : permet de définir le type back_insert_iterator<_Container>. Il s’agit du type définit par la classe back_insert_iterator elle-même.   -container_type : il s’agit du type du container lui-même.   - const_reference: C’est un nom dependant. Il s’agit d’une référence constante (A vérifier).   -_Valty: C’est un nom dependant. Il s’agit de la valeur contenue dans le container lui-même.

---

Mais le problème est que tout est imbriqué, et je ne sais pas par où commencé. Alors j'ai plus ou moins laissé tombé.

avant d'étudier comment ça marche, tu devrais peut-être t'en servir? (dans des projets perso, et oui, on y revient)

D'autant que le 'comment ça marche' peut varier d'une implémentation à l'autre de la STL par exemple. Et cela peut s'étendre à d'autres aspects du C++ qui sont mis en œuvre différemment selon les compilateurs.

Bonjour

Je continue sur ce thread car j'ai eu une autre question concernant les dynamic_cast et le static_cast. On m'a demandé ce qu'était la différence.

J'ai dit que le static_cast permettait de faire des conversions entre pointeurs de classes. Mais qu'il était surtout utile pour convertir un pointeur d'une classe dérivée en une classe de base.

Le dynamic_cast permet quant à lui de convertir de manière sûre un pointeur de base sur une classe dérivée. Et que si ce n'était pas possible, il renverrait un pointeur sur void.

On m'a dit que ce n'était pas tout à fait cela. Pourtant, c'est ce qui m'a semblé être écrit dans la FAQ.

Ce n'est pourtant pas ce que l'on dit:

Le static_cast est à utiliser lorsque tu as la certitude que le downcasting effectuté va réussir (parce que tu as la certitude que le type dynamique de l'objet est bel et bien identique à celui dans lequel tu essaye de le transtyper)

Si tu as une classe Base et une classe Derivee telle que Derivee hérite de base, et une fonction proche de

Code:

---

1 2 3 4

Base * foo() { return new Derivee; }

---

et que tu veux récupérer un pointeur sur Derivee, tu as la certitude que le downcasting réussira.

Tu peux donc te "contenter" d'un static_cast:

Code:

---

Derivee * ptr = static_cast<Derivee*> (foo() );

---

Le dynamic_cast est à utiliser lorsque tu veux pouvoir essayer un transtypage qui peut ne pas être correct, et qui doit donc pouvoir te donner un état de réussite ou d'échec.

dynamic_cast ne renverra pas void mais null si tu l'applique sur un pointeur ou lancera une exception de type std::bad_cast si tu l'applique sur une référence:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

class Base { /*...*/ }; class D1 : public Base { /*...*/ }; class D2 : public Base { }; class Holder { private: Base * b_;// peut être en réalité, selon les circonstances, un // pointeur sur Base, sur D1 ou sur D2 public: Holder():b_(new Base){} ~Holder(){delete b_;} Base * ptr(){return b_;} Base & ref(){return *b_;} void makeD1() { delete b_; b_=new D1; } void makeD2() { delete b_; b_=new D2; }   }; int main() { Holder h; // ca commence par un pointeur sur Base D1 * ptr = dynamic_cast<D1*>(h.ptr()); // NULL car c'est un pointeur sur // Base D2 & ref = dynamic_cast<D2 &>(h.ref()); // lance bad_cast h.makeD2(); D2 * ptr1 = dynamic_cast<D2*>(h.ptr()); // ok D2 & ref2 = dynamic_cast<D2 &>(h.ref()); // ok }

---

Sinon, static_cast gère aussi toutes les conversions autres.
Le sujet des casts fut évoqué il y a peu: http://www.developpez.net/forums/d92...ter/casts-cpp/

Et l'upcasting fonctionne toujours implicitement, sans sortir static_cast<> ou dynamic_cast<>.