Discussion :

[poukill]

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 !

[deubelte]

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.

[poukill]

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

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

[3DArchi]

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'.

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.

[deubelte]

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.

[gl]

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

Code :

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

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

on peut faire

Code :

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

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.

[poukill]

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.

[deubelte]

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

[koala01]

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

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

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

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

[poukill]

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

Je sais pas pourquoi, mais ta réponse m'a rendu presque triste...
T'as pas la moindre idée de ce que tu pourrais faire? C'est navrant ! 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.

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.

[koala01]

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

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

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

[3DArchi]

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

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.

[ram-0000]

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

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.

[deubelte]

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 :

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

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é.

[nikko34]

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

[3DArchi]

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.

[deubelte]

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.

[koala01]

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 :

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

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 :

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

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 :

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

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
}

[Luc Hermitte]

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