Bonjour,

j'ai un soucis que je ne comprend pas.

ISquad* vlc2 = new Squad;
ISquad* vlc3 = new Squad(*vlc2);

ISquad est une interface classique, et Squad herite de ISquad.

Et voici le proto du constructeur de copie:

Squad::Squad(Squad const & squad);

"candidate constructor not viable: no known conversion from 'ISquad' to 'const Squad' for 1st argument"

Alors j'arrive a comprendre qu'on ne puisse pas mettre une Instance 'Base' dans une instance 'Derivee', mais bon, la je creer un objet de type 'Enfant', stocker dans un pointeur de type 'Base'. Mais bon, ce qui me tracasse le plus c'est que je n'arrive pas a le caster, un truc du genre:

ISquad* vlc3 = new Squad(static_cast<Squad>(*vlc2));

Comment dois-je m'y prendre ? Vu que je ne peux pas declarer de constructeur de copie pour mon interface :s

Pour infos je suis obliger d'utiliser cette interface.

Merci d'avance !

-
Edité par StephaneLeliegard 19 avril 2018 à 23:32:41

Bonjour,

La définition de l'héritage doit indiquer que la conversion est possible class Squad : public ISquad, il ne faut pas oublier le mot public.

[EDIT] : wow j'ai modifier mon permier post, Dalfab. desoler la fatigue m'a fait ecrire n'imp XD.

Oui, de ce coter c'est bon, c'est bien defini comme tu dit ˆˆ.

Mais l'interface est toute simple au final:

class ISquad
{
    public:
        virtual                 ~ISquad() {}
        virtual int             getCount() const = 0;
        virtual ISpaceMarine*   getUnit(int) const = 0;
        virtual int             push(ISpaceMarine*) = 0;
};

elle est imposee si jamais.

-
Edité par StephaneLeliegard 19 avril 2018 à 23:35:24

Salut,

Première question, ta classe Squad a t'elle un constructeur ?

Ensuite, avec l'héritage, tu peux substituer une référence (ou pointeur) d'une classe dérivée à sa classe de base.
Par contre l'inverse n'offre aucunes garanties.

Dans ton cas précis, tu refiles au constructeur de recopie une référence vers la classe de base (référence de type ISquad), hors il attend une référence vers la classe dérivée (référence de type Squad).

Une solution est de faire un transtypage lors de l'appel du constructeur de recopie (beurk !!):

ISquad* vlc2 = new Squad;
ISquad* vlc3 = new Squad(static_cast<Squad&>(*vlc2));

Avant toute chose, es-tu sûr de vouloir dupliquer tes objets? Si oui, le mot clé est clonage -> constructeur de copie protégé, fonction clone publique, opérateur d'affectation supprimé (`= delete`).

Mais... as-tu vraiment besoin de dupliquer ces objets? C'est excessivement rare que l'on ait besoin de faire ça.

Deedolith a écrit:

Salut,

Première question, ta classe Squad a t'elle un constructeur ?

    -Oui, de base et de copie.

Une solution est de faire un transtypage lors de l'appel du constructeur de recopie (beurk !!):

ISquad* vlc2 = new Squad;
ISquad* vlc3 = new Squad(static_cast<Squad&>(*vlc2));

    -En effet, j' avais trouver ca moi:

ISquad* vlc3 = new Squad(*(static_cast<Squad*>(vlc2)));

    -Ta version est mieux :p. Sinon oui je confirme, c' est beurk, mais c'est uniquement pour l' excercice donner. Surement pour se rendre compte de l' utilite du polymorphisme, qui sait ...

lmghs a écrit:

Avant toute chose, es-tu sûr de vouloir dupliquer tes objets? Si oui, le mot clé est clonage -> constructeur de copie protégé, fonction clone publique, opérateur d'affectation supprimé (`= delete`).

Mais... as-tu vraiment besoin de dupliquer ces objets? C'est excessivement rare que l'on ait besoin de faire ça.

La oui, une Squad contient des instance de different type de ISpaceMarine (de soldat quoi), et on doit pouvoir deep copy la squad. Mais du coup pas sur de comprendre ce que tu veux dire par "constructeur de copie protégé, fonction clone publique, opérateur d'affectation supprimé (`= delete`)".

Si jamais je suis obliger d' utiliser mes classes en Coplien's Form, donc operateur d' affection obligatoirement declarer.

Merci en tout cas !

Salut,

StephaneLeliegard a écrit:

La oui, une Squad contient des instance de different type de ISpaceMarine (de soldat quoi), et on doit pouvoir deep copy la squad. Mais du coup pas sur de comprendre ce que tu veux dire par "constructeur de copie protégé, fonction clone publique, opérateur d'affectation supprimé (`= delete`)".

J'aurais, au contraire, tendance à dire que cela plaide en défaveur d'une copie en profondeur...

Car, avec une copie en profondeur:

• tu ne pourras jamais être sur de t'adresser effectivement au SpaceMarine auquel tu crois t'adresser, plutôt qu'à sa copie
• Un SpaceMarine pourrait se retrouver dans une escouade particulière, et sa "copie" dans une autre... Ou pire, dans la même escouade

Si jamais je suis obliger d' utiliser mes classes en Coplien's Form, donc operateur d' affection obligatoirement declarer.

Justement, la forme de Coplien n'est valable que pour les classes qui ont sémantique de valeur.

Or, tes classes (et les interfaces qui y sont relatives) Squad, SpaceMarine et autres ont... sémantique d'entité.

-
Edité par koala01 20 avril 2018 à 17:59:05

Que tu aies besoin d'une factory pour en générer 100 je veux bien, mais que tu aies besoin de les copier, non, je ne comprends pas.

Je ne sais pas qui t'as dit que tu devais suivre la FCOC sur une classe impliquée dans un héritage public. On t'a menti, il ne le faut surtout pas, au contraire, il faut interdire la duplication car ce n'est pas compatible. Jim O'Coplien range d'ailleurs la FCOC au milieu des value classes dans son livre. Ce n'est pas un hasard.

Pour rejoindre mes petits camarades,on voit immédiatement qu'un soldat est unique, le soldat a ses caractéristiques propres, ses compétences, son expérience, et son "état général" (les dégats qu'il subi, son équipement...), en faire une copie n'a aucun sens, c'est comme si je faisais une copie de toi. A l'instant où je fais cette copie,  elle va vivre autre chose que toi, ce sera un clone de toi, mais ça ne sera pas toi. Un squad possède aussi cette propriété, il ne peut pas combattre simultanément sur deux positions différentes, et du fait de l'unicité des soldats, la seule opération ayant du sens est le déplacement d'un soldat d'un squad dans un autre. Cette notion d'entité est absolument fondamentale, car elle est la base d'une conception cohérente. Il en résulte qu'une entité ne peut pas être copiable.

Un autre point qui est important, c'est l'idée de raisonner en termes de services à rendre, et non d'encapsulation de données. Une classe rend des services, elle encapsulera les données dont elle a besoin pour rendre les services qu'elle doit rendre. Par exemple un missile, les services à rendre sont se déplacer et exploser, les données qu'elle doit détenir sont relatives à sa position, sa direction et sa vitesse pour rendre le service "se déplacer", et les données permettant de calculer les dégats lorsqu'on appelera le service "exploser".

J' ai peut-être omis de préciser que ce sont des sujets d' école :p, donc pour ce qui est de la deep copy sur la classe Squad, ainsi que les interfaces de ISquad et ISpaceMarine, je n' ai pas le choix. Je comprend ce que vous voulez dire cela dit, et surement que les classes choisies ont mal été choisies, mais on peut voir ça également comme un jeu dans lequel tu as des squad avec différents type de soldat, sans particularité aucune mis a part leur type, et lorsque l' on copy la squad, on ne veux pas avoir les même soldats, mais le même nombre (genre un jeu de guerre/rpg ou un sort spécial duplique ta Squad). Ou encore surement d' autre scénarios, mais bon, peu importe, même si le type des classes sont inadéquates, c' est juste un sujet de formation c++, pour aborder les interfaces et leurs utilités et inconvénients je pense.

Apres moi-même sans expérience en cpp je remarque qu' il y a des choses bizarres dans les sujets, donc bon. Mais c'est uniquement le temps de l' "initiation" au cpp. Apres ça pour les projets je serais libre. La pour l' instant dites-vous que je peux même pas utiliser ni les features de c++11, ni tout ce qui est Vector, map, etc, ni d' include <algorithm> avant les dernières journées de formation. Pour dire qu' il faut voir ça comme un exercice ciblé, bien fait ou mal fait je saurais pas dire mais bon, en tout cas grâce a ça j' ai compris des choses. Donc il y a du bon quand même :p.

Mais je comprend ce que vous me dites. Les notions de sémantiques de valeurs et d' entités sont encore un peu floues, je lis beaucoup de doc et tuto donc il va falloir du temps pour que tout rentre :p. Merci pour les retours en tout cas, c'est cool ! Je reviens vous embêter bientôt, le prochain aborde les templates ! Bonne soirée !

Ton "sort" de deep copy, c'est une interface de clonage comme l'a indiqué lmghs. il existe des situations où ce genre de chose peut servir, mais comme il l'a dit, elles sont plutôt rares.

Dans le cadre de mon boulot, je suis très souvent amené à devoir implémenter en c++03, pour une très bonne raison: je n'ai pas de compilo supportant c++1x à ma disposition. En revanche, la conception ne change pas, c++1x ou pas, elle reste la même, c'est juste la mise en oeuvre qui est plus compliquée parce qu'en c++03, on ne dispose pas des features de c++1x, on est donc obligé de se débrouiller pour les émuler via des bibliothèques comme boost ou du code fait maison.

c++1x ou pas, on évite le deep copy comme la peste, parce qu'en plus d'être le plus souvent, conceptuellement inepte, c'est totalement inefficace et source quasiment infinie d'erreurs et d'emmerdements.

Enfin, il y a une question qui me parait essentielle: A quoi sert une formation qui t'apprends à "faire de la merde"? Quelle est sa valeur?

A l'époque où j'ai appris c++, la question d'utiliser map, vector ou l'en-tête algorithm ne se posait pas, tout simplement parce que ça n'existait pas, donc on devait se taper le boulot à la main. Depuis, les choses ont changées, la bibliothèque standard est apparue puis s'est etoffée. 

De la même façon que je n'ai pas besoin de connaitre tous les détails du fonctionnement de ma voiture pour la conduire, je n'ai pas besoin d'être capable d'implémenter un map ou un vector pour m'en servir.

Economiquement, c'est aussi plus rentable, le temps que je ne vais pas passer à recoder map ou vector, je pourrais le consacrer à autre chose. De plus, ils sont très largement utilisés, donc largement testés, donc très fiables, ce qui réduit d'autant le risque de problème. En les utilisant, on réduit ce qu'on appelle le "Time to market", c'est à dire le temps nécessaire pour passer de l'état de projet à l'état de programme qui fonctionne. Finalement, il est probablement plus intéressant de savoir se servir de map ou vector, que savoir les implémenter...

-
Edité par int21h 21 avril 2018 à 5:37:01

@int21h je ne suis pas 100% d'accord.

Oui savoir utiliser std::vector, std::map c'est plus important que de connaître leurs implémentations.

Mais si on fait les choses dans l'ordre (à savoir apprendre à l'utiliser, puis comprendre le fonctionnement) c'est très formateur.

Dans mes formations (ruby) j'apprend à mes élèves à utiliser la méthode #each des tableau. Une fois qu'ils connaissent, ils implémentent #my_each, une fois ça, ils découvrent le monde des iterateurs. C'est la même chose pour std::vector. std::vector ce n'est pas qu'un objet stockant des donnés, c'est un bon gros service avec pas mal d'options intéressantes à comprendre.

@necros211 En fait, tu es tout à fait d'accord avec moi

Je n'ai pas la moindre idée de comment fonctionne mon four micro-ondes, je met mon truc dedans, je règle la minuterie, j'appuie sur le bouton et ça marche. Si je veux comprendre comment marche un four micro-onde, il va falloir augmenter sérieusement mon niveau en physique quantique... Mais pour rechauffer mon plat de nouilles, le minuteur et le bouton start, ça suffit largement.

Si je faisais une formation à c++ sur vector, je parlerais de push_back(éventuellement emplace_back en c++1x) pour coller un truc à la fin du tableau, j'evoquerais l'opérateur [] pour accéder aux éléments d'un tableau par son indice, et si je me place dans l'univers c++1x, je vais parler du ranged for, qui traduit un concept vraiment interssant : pour tout les éléments. Avec juste ça, j'ai une approche accessible de vector, qui suffira à la totalité des programmeurs c++ débutants, et avec un petit complément à l'immense majorité des programmeurs c++.

Si le thème de la formation est concevoir une classe vector, je vais négliger ces évidences pour débutants et rentrer directement dans le dur, en considérant  que celui qui ne maîtrise pas l'utilisation de vector, n'a aucune chance de comprendre sa conception. Je vais parler de définition d'invariants de classe, de stratégie d'allocation, d'optimisation... bref de tout ce qui va garantir que le néophyte qui utilise mon vector n'aura pas de mauvaises surprises (ni sur le plan fonctionnel, ni sur le plan des performances). L'implémentation de vector, est sur le papier, plutôt simple, mais si tu vas voir tout ça dans le détail, c'est une autre histoire. Refaire la classe vector est un excellent exercice, mais il n'a rien de facile, pourtant vector est le plus "simple" des conteneurs de la SL...

@StephaneLeliegard: puisque tu as appris avec le C, pourrais tu m'expliquer en détail ce qui se passe lorsque cette ligne de code est exécutée:

char * ptr = malloc(55);
/* petit rappel: le cast depuis void * est implicite en c */

Pourrais tu m'expliquer au passage la différence avec cette ligne de c++

char * ptr = new char[55]

Et la question qui tue: En quoi la première ligne que je te propose d'étudier donne t'elle plus d'information sur le bas niveau que la seconde? 

Recoder vector à l'identique, ne t'apprendra pas vraiment grand chose en fait au niveau des concepts. Si tu sais bien utiliser vector, tu seras fatalement tombé à un moment ou un autre sur le concept d'itérateur et sans même savoir ce que c'est réellement tu auras une idée assez précise de la réponse à la question "A quoi ça sert?". En fait le seul point vraiment intéressant dans l'étude d'une implémentation de vector, c'est comment il fait pour changer de taille, le reste est pratiquement sans intérêt.

-
Edité par int21h 21 avril 2018 à 14:10:23

StephaneLeliegard a écrit:

@int21h: et bien dans ce cas il y a deux écoles je pense. (1)Perso j' ai commencer le C en recodant pas mal de fonctions de la libc, et bien ça m' a bien appris. (2)Et je dirais que c' est d' autant plus important en c++ vu que ses fonctions requiert d' autant plus de "concept de programmation", et si j' arrive a recoder un std::vector quasi a l' identique, (3)et bien cela voudra dire je pense que j' aurais compris beaucoup de chose sur le fonctionnement du cpp (templates, iterators, et bien d' autre concept je pense que je ne connais pas encore). (4)Mais arriver sur le c++ et tout assimiler d' un coup, ba je te dit chapeau parce que moi perso je ne peux pas. (5)Donc y aller étape par étape me va, et donc aborder les interfaces avec un sujet court et cibler comme celui-ci me va. (6)Mais non je ne considère pas ces sujets comme vérité absolues, (7)encore une fois je vois bien que des choses 'cloche' dans les sujets, mais je me répète, c' est des sujets d' initiation aux bases du cpp ...

(1) En C, oui, d'accord (*), parce que

• C n'est qu'un assembleur évolué (le "plus bas niveau des langages de troisième génération")
• C ne fournit que très peu de fonctionnalités de très haut niveau

(*) Et, encore, il faut voir comment tu l'as fait: si tu n'as pas codé ta propre fonction malloc sans utiliser ses homologues fournis par libc, qu'as tu appris en fait?

(2) Justement, non... Les concepts que l'on ajoute en s'abstrayant de plus en plus du langage machine rendent, effectivement, les langages plus complexes, dans le sens où ils nous obligent à comprendre les concepts en question afin de faire nos choix en connaissance de cause: "vais-je utiliser un tableau dynamique ou une file ici? ou peut-être devrais-je utiliser un arbre binaire?"

Mais tous ces concepts tendent en définitive à rendre la programmation plus facile et / ou de meilleure qualité:

• on n'a pas à s'inquiéter d'augmenter la capacité d'un tableau lorsque l'on veut rajouter "un élément de plus"
• on n'a pas à s'inquiéter de libérer la mémoire lorsqu'un tableau n'est plus utilisé, afin de la rendre disponible pour un "usage ultérieur"
• on peut déterminer plus clairement s'il est cohérent d'envisager un héritage publique ou non
• on peut déterminer si deux données sont clairement équivalentes, et donc s'il est possible / cohérent de prévoir le moyen de les convertir l'une dans l'autre, ou, au contraire si elles font partie de domaines clairement séparés
• j'en passe et de meilleures.

En un mot comme en cent: on n'a plus besoin de s'inquiéter "de que qu'il y a sous le capot", même si cela sous entend de se poser... d'autres questions (et peut-être bien plus qu'avant)

(3)J'aurais difficile à te donner tord sur ce point là.  Seulement, si tu y regardes bien, tout ce que tu as fait en essayant d'implémenter les classes existantes, c'est... De te choisir des exercices (pour lesquels tu avais un corrigé) qui t'on juste permis de... gagner de l'expérience.

Or, tu aurais sans doute pu gagner tout autant d'expérience avec des exercices différents

(4) Et personne ne le peut...  Quand on pense (pour ce que cela vaut) que la norme fait plus de 1800 pages en 2017, qu'elle en faisait à peu près 1600 en 2011 et à peine plus de 1200 en 2005, il est parfaitement clair qu'il est impossible de tout assimiler d'un seul coup, surtout pour le pauvre malheureux qui ne découvre la norme que maintenant

Mais c'est justement la raison pour laquelle l'ordre dans lequel tu vas apprendre ce langage est important: si tu as une courbe d'apprentissage "lisse" et relativement faible, tu y arriveras bien mieux que si tu as une courbe d'apprentissage qui joue les montagnes russes.

Je m'explique:

En C, tu n'as pas le choix: dés que tu as vu la syntaxe de base (fonctions, instructions, tests et boucles), tu dois t'attaquer au gros morceau de ce qu'est la gestion dynamique de la mémoire, parce que sans cela, tu ne peux rien faire. 

Tu passe d'une difficulté de niveau 2 à  une difficulté de niveau 20 avant de pouvoir t'intéresser à des éléments dont la difficulté variera entre deux et vingt.

En C++, une fois que tu as vu la syntaxe de base (fonctions, instructions, tests et boucles), tu peux apprendre ne serait-ce qu'à utiliser std::vector qui se chargera de tout l'aspect relatif à la gestion dynamique de la mémoire pour toi.  C'est une difficulté de niveau 3.

Mais, grâce à elle, tu peux faire énormément de choses que tu ne pourrais pas faire sans avoir appris la gestion dynamique de la mémoire en C.

Par la suite, tu vas rajouter de la difficulté: la surcharge de fonction, la récursivité, la notion de fonctions membres Vs la notion de fonctions libres (on n'est même pas encore obligé de parler objet au sens LSP du terme: on parle d'encapsulation et de data hidding), et tu acquéras  donc des capacités à résoudre des problèmes de difficulté quatre à 15.

Puis, seulement, nous venons avec des notions comme l'héritage publique, l'héritage multiple.  Et bien sur, avec la gestion dynamique de la mémoire, vu que nous n'en avions pas besoin avant, et que là, elle devient "indispensable".  Mais il ne faut pas oublier tout ce qui va avec (les exceptions), et, bien sur, le moyen de s'en sortir "sans casse" (les pointeurs intelligents).  Et tu atteints quand même ton niveau de difficulté 20!

Et, enfin, s'il reste du temps, tu peux t'intéresser à ce qui a trait à la programmation générique, au templates et à ce qu'ils peuvent faire pour toi

(5)Nous sommes tous tout à fait d'accord sur le fait d'y aller étape par étape. Mais quel exemple crois tu donner à tes élèves en leur disant "on va pas être trop attentif à l'aspect conceptuel du problème"???

Quel sera le résultat d'un tel discours à ton avis, si ce n'est que tes élèves en arriveront à se dire "bah, la conception, c'est pour les vieux tromblons qui ne savent pas aligner deux idées à la suite" ou "la conception ne sert à rien, vu qu'on n'est pas obligé de la respecter"???

Et tu t'étonnes d'avoir régulièrement sur les forums des réflexions du genre de "oui, mais tu sais bien qu'il y a toujours des exceptions" ou de "oui, mais il y a des fois où l'on n'a pas le choix"???

Les exceptions doivent être limitées au possibles et pleinement justifiées, pour leur laisser leur statut d'exception, et on a toujours le choix de faire une conception correcte et de s'y tenir.  C'est d'ailleurs la seule chose qui t'évitera de perdre énormément de temps sur des conneries.

(6) encore heureux

(7) Alors, pourquoi ne pas refaire l'exercice de manière à ce qu'il n'y ait "rien qui cloche", même dans le cadre d'une initiation aux base du C++???

Bon, pour essayer de consillier les chevres (profs) et le loups (les professionnels d'ici) tout en gardant un code correcte, tu peux equiper ta classe Squad d'une fonction membre clone, ainsi tu pourras ecrire quelque chose qui ressemble à ceci:

ISquad* vlc2 = new Squad;
ISquad* vlc3 = static_cast<Squad*>(vlc2->clone());

Deedolith a écrit:

Bon, pour essayer de consillier les chevres (profs) et le loups (les professionnels d'ici)

C'est bien aimable à toi, mais si on ne se décide pas, à un moment ou à un autre, à bousculer les profs sous prétexte qu'ils sont prof, nous en serons dans trente ans exactement dans la même situation.

Je serai sans doute trop gâteux pour m'en rendre compte, j'aurai peut etre déjà pris ma retraite depuis longtemps (s'il y en a encore), mais la qualité du développement n'aura pas évolué d'un iota, et de sera bien dommage 

Je ne suis pas fan du "prof bashing", mais que faire ?

L'éducation nationale à toujours été en décalage avec la réalité du terrain, et ce dans tous les domaines (ex: Vielles machines manuelles quand toutes les entreprises ont déjà des commandes numériques), faute de moyens, de temps, de volonté, d'amour propre.

J'avais déjà lancé une invitation aux profs à venir s'exprimer ici, visiblement, ca n'a pas été suivit.

Resultat, on en vient à proposer des solutions "les moins crades".

-
Edité par Deedolith 21 avril 2018 à 18:05:44

Ce n'est pas lié aux `profs`, des professionnels font aussi ce genre de solutions crades. Ce problème est bel et bien lié à la mentalité de chacun, à savoir, suivre les normes, s'informer sur des astuces, des bonnes pratiques, etc. Maintenant on peut en vouloir aux enseignants plutôt qu'à des professionnels, car l'enseignement touche des milliers de futurs professionnels, cependant, rien n'empêche le professionnel de se mettre à jour et de prendre le taureau par les cornes pour progresser suite à ses études.

Quand à ces métier (développeurs, enseignants, aides soignants, ...), si ça n'est pas une vocation et un plaisir de le pratiquer, alors c'est comme partout, on ne se donnera pas la peine de progresser et on considérera son emploi comme un simple moyen de pouvoir `bouffer`.

Généraliser sur le monde enseignant c'est simplement montrer de l'animosité sur un cercle lié à des frustrations sans doute lointaines. Rien de tel que de passer des concours éducation nationale pour participer au cercle et faire profiter de votre expérience. Sinon, vous referez pas le monde !

Deedolith a écrit:

Je ne suis pas fan du "prof bashing", mais que faire ?

Je ne suis absolument pas fan du "prof bashing", et, si cela peut te rassurer, je taperai avec la même force (et sans doute même plus fort encore) sur la tête d'un professionnel qui ne se met pas à jour

Deedolith a écrit:

<...>faute de moyens, de temps, de volonté, d'amour propre.

C'est bien à cause de ces manques que je râle le plus

oldProgrammer a écrit:

Ce n'est pas lié aux `profs`, des professionnels font aussi ce genre de solutions crades. Ce problème est bel et bien lié à la mentalité de chacun, à savoir, suivre les normes, s'informer sur des astuces, des bonnes pratiques, etc. Maintenant on peut en vouloir aux enseignants plutôt qu'à des professionnels, car l'enseignement touche des milliers de futurs professionnels, cependant, rien n'empêche le professionnel de se mettre à jour et de prendre le taureau par les cornes pour progresser suite à ses études.

Nous sommes bien d'accord là dessus...

Mais, quand tu vois que de plus en plus professions finissent par imposer une formation continue, que cette formation continue devient une règle sine qua non à la poursuite de la profession dans de nombreux cas (c'était déjà le cas en Belgique pour les membres des services de secours il y a pres de trente ans, c'est devenu le cas pour les avocats, les aides soignants et, récemment pour les camionneurs);

Quand tu vois que le développeur qui cesse de suivre les évolutions pendant ne serait-ce que trois ans se retrouve complètement largué;

Quand tu te rends compte qu'une bonne partie de ce que (certains) enseignants apprennent à leurs élèves n'est pure ineptie (par chance, il y en a d'autres qui sont vachement bons, et je le pense, ce n'est pas "juste pour éviter de généraliser" );

J'ai envie de dire "mais qu'est ce qu'on attend pour mettre un ''permis d'enseigner'' en place, qui obligerait les profs à se tenir au courant des évolutions dans les branches qu'ils enseignent???"

Et, quand on voit que, dans certains domaines, tu ne peux pas être prof si tu ne justifie pas d'une expérience suffisante dans la profession, on se demande aussi comment cela peut se faire que nous n'en soyons pas encore arrivé à une conclusion équivalente dans le domaine du développement informatique.

Je ne jette la pierre à personne, ou, du moins, à aucun prof et à aucun professionnel en général (par contre, je la jette aux dirigeants, car c'est à eux de mettre de tels systèmes en place)

Mais il y a -- très clairement -- et depuis très longtemps un problème auquel, même le fait de faire "partie du cercle" ne pourra rien changer

Et je ne compte pas non plus le nombre de fois où j'ai fini une intervention en proposant à un élève d'inviter son prof à venir discuter avec moi

-
Edité par StephaneLeliegard 21 avril 2018 à 22:02:44

koala01 a écrit:

J'ai envie de dire "mais qu'est ce qu'on attend pour mettre un ''permis d'enseigner'' en place, qui obligerait les profs à se tenir au courant des évolutions dans les branches qu'ils enseignent???"

Il y a beaucoup de stages pour remettre en question les enseignements actuels et amener les enseignants à suivre les évolutions. Seulement, quand quelqu'un ne veut pas, tu peux pas lui mettre le couteau sous la gorge. C'est ce dont je parlais quand j'évoquais le terme de vocation, tu te donneras plus ou moins le mal selon ta motivation.

koala01 a écrit:

Et, quand on voit que, dans certains domaines, tu ne peux pas être prof si tu ne justifie pas d'une expérience suffisante dans la profession, on se demande aussi comment cela peut se faire que nous n'en soyons pas encore arrivé à une conclusion équivalente dans le domaine du développement informatique.

C'est pire que ça, on impose à des mecs d'enseigner des langages tels que python, ruby, ... pour amener l'élève à réfléchir sur la résolution d'un problème par la pratique alors que les mecs n'ont jamais développé de leur vie et les stages sont donnés par des mecs qui n'ont pas plus d'expérience.

Je prends le cas des enseignants ISN qui s'évertuent à rester en python 2.x alors que la version 3.x a plus de 10 ans et que cette version 2.x, on en parlera plus d'ici 2020. T'as beau le dire, c'est à croire que ça les saoule de devoir réapprendre quelques subtilités du langage. Là je parle encore de vocation.

StephaneLeliegard a écrit:

Merci pour les reponses, je pense qu' on derive la... sujet resolu, bonne soiree

Super ! Ça m'a permis de ne plus hésiter à répondre...

oldProgrammer a écrit:

Il y a beaucoup de stages pour remettre en question les enseignements actuels et amener les enseignants à suivre les évolutions. Seulement, quand quelqu'un ne veut pas, tu peux pas lui mettre le couteau sous la gorge. C'est ce dont je parlais quand j'évoquais le terme de vocation, tu te donneras plus ou moins le mal selon ta motivation.

Effectivement, si la personne n'est pas motivée, on ne pourra sans doute "rien en faire"

C'est pire que ça, on impose à des mecs d'enseigner des langages tels que python, ruby, ... pour amener l'élève à réfléchir sur la résolution d'un problème par la pratique alors que les mecs n'ont jamais développé de leur vie et les stages sont donnés par des mecs qui n'ont pas plus d'expérience.

Quelque part, c'est bien la preuve que le véritable problème ne se situe pas forcément au niveau des enseignants, mais bien au niveau des décideurs

Je prends le cas des enseignants ISN qui s'évertuent à rester en python 2.x alors que la version 3.x a plus de 10 ans et que cette version 2.x, on en parlera plus d'ici 2020. T'as beau le dire, c'est à croire que ça les saoule de devoir réapprendre quelques subtilités du langage. Là je parle encore de vocation.

Ce qui semble indiquer que les décideurs ne sont pas les seuls en causes (à moins que les enseignants n'aient une bonne raison -- due aux décideurs -- de ne pas vouloir "passer du temps à réapprendre quelques subtilités"

Mais, quoi qu'il en soit, le problème est majeur... Et il serait temps -- à mon sens -- de "faie quelque chose" pour y remédier

ISquad* vlc2 = new Squad;
ISquad* vlc3 = vlc2->clone();

(Pas besoin du static_cast)

@StephaneLeliegard

Pour clone, cf https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Virtual_Constructor. C'est un pattern de programmation objet.

Mais comme déjà dit, cela pose probléme de vouloir copier des objets qui appartiennent à un héritage. D'ailleurs, quand tu disais :

StephaneLeliegard a écrit:

Surement pour se rendre compte de l' utilite du polymorphisme, qui sait ...

C'est tout le contraire. Comme tu le vois (ou pas), tu es obligé d'écrire un code spécifique en fonction du type. Ce qui est tout le contraire du polymorphisme. D'où la réaction des intervenants précédents : quel est le sens d'un cours où tu apprends le polymorphisme avec un code qui n'est pas du polymorphisme ??? Il y a quelque chose de complètement illogique dans cette démarche.

Deedolith a écrit:

Je ne suis pas fan du "prof bashing", mais que faire ?

Dire qu'un prof incompétent est incompétent, ce n'est pas faire du prof bashing. Quelques soient les raisons de cette incompétence, que ce soit de son fait ou de causes externes au prof.

Il n'y a aucun intérêt, pour l'apprenant, de ne pas lui dire que son prof lui apprend pas correctement les choses. Et il n'y a que les intérêts de l'apprenant qui sont important dans l'histoire, pas la susceptibilité des profs.

Deedolith a écrit:

Resultat, on en vient à proposer des solutions "les moins crades".

Est-ce l'intérêt de l'apprenant qu'on lui apprenne des choses incorrectes ?

Chacun est libre de faire les choses comme il souhaite, mais pour moi, je préfère expliquer correctement les choses, même si cela ne suit pas ce que le prof a expliquer.

Et ca serait bien d'arrêter de reprendre les gens qui corrigent (avec raison) les profs. Il y a une erreur, on la corrige. Et ca ne sert a rien de défendre les erreurs des profs.

gbdivers a écrit:

ISquad* vlc2 = new Squad; ISquad* vlc3 = vlc2->clone();

(Pas besoin du static_cast)

@StephaneLeliegard

Pour clone, cf https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Virtual_Constructor. C'est un pattern de programmation objet.

Mais comme déjà dit, cela pose probléme de vouloir copier des objets qui appartiennent à un héritage. D'ailleurs, quand tu disais :

StephaneLeliegard a écrit:

Surement pour se rendre compte de l' utilite du polymorphisme, qui sait ...

C'est tout le contraire. Comme tu le vois (ou pas), tu es obligé d'écrire un code spécifique en fonction du type. Ce qui est tout le contraire du polymorphisme. D'où la réaction des intervenants précédents : quel est le sens d'un cours où tu apprends le polymorphisme avec un code qui n'est pas du polymorphisme ??? Il y a quelque chose de complètement illogique dans cette démarche.

Merci, je vais aller voir ca. Et oui du coup, je vois bien que ce n' est pas du polymorphisme, tout ce que je dit, c' est que vu que l' exo nous force a utiliser une interface donnee, et de ce fait impossible d' utiliser le polymorphisme avec la dite interface, en codant et en testant je me suis dit tient, c'est la que le polymorphisme aurait pu etre utile. Bref, en fait tout ce que j' ecrit est mal interpreter, donc bon, comme je disais, sujet clos. Mais merci pour le retour, je vais aller voir ce pattern de clonage !

-
Edité par StephaneLeliegard 22 avril 2018 à 9:56:05

Hum.. OK. Ton prof impose une interface dans laquelle il n'y a rien de bien pratique pour dupliquer.

C'est aussi lui qui t'impose de dupliquer tes unités? Ou alors c'est juste ton interprétation de la FCOC qui te fait dire qu'il faut que tu en soit capable?

imposer egalement:

"Upon copy construction or assignation of a squad, the copy must be deep. Upon assignation, if there was any unit in the Squad before they must be destroy before being replaced. You can assume every unit will be created with new".

koala01 a écrit:

oldProgrammer a écrit:

Il y a beaucoup de stages pour remettre en question les enseignements actuels et amener les enseignants à suivre les évolutions. Seulement, quand quelqu'un ne veut pas, tu peux pas lui mettre le couteau sous la gorge. C'est ce dont je parlais quand j'évoquais le terme de vocation, tu te donneras plus ou moins le mal selon ta motivation.

Effectivement, si la personne n'est pas motivée, on ne pourra sans doute "rien en faire"

Il est assez probable que si ils étaient motivés par la technique au point de vouloir se mettre au niveau des professionnels de la profession (du moins ceux qui sont au niveau, parce que c'est pas toujours brillant), ils deviendraient eux même professionnels pour gagner 3 fois plus et pas être emmerdés par les copies à corriger, les parents d'élèves et l'administration.

Voir aussi qu'ils sont chargés d'enseigner de multiples sujets. Trouvé sur internet, ce qu'on demande pour un poste de prof, avec un spectre dont le SIN n'est qu'une partie.

ETT :
Compétences généralistes dans le domaine technologique couvrant les quatre options de la
filière STI2D : Architecture et conception (AC), Energie environnement (EE), Innovation
technologique et Eco conception (ITEC) et SIN
Option SIN :
Electronique analogique :
-Amplification
-Filtrage
-Commande d’actionneur
-Capteurs, mise en forme de signal
Electronique numérique :
-Numérisation du signal
-Protocoles de communication
-Programmation de microcontrôleur
-langage C, Python, Flowcode, Proteus, HTML ou autres
Réseaux informatiques :
-Architecture client / serveur
-Télécommunication de l’information (son, images, données)
-Développement de systèmes virtuels

Bref, ils font ce qu'ils peuvent.

Et je suis bien d'accord que le résultat n'est pas satisfaisant. De l'option SIN, j'attendais qu'arrivent en IUT des lycéens de dérouler à la main une boucle. Ben non. Il y a une proportion non négligeable qui n'a pas passé ce stade. Y en a encore qui font les affectations dans le mauvais sens.

-
Edité par michelbillaud 22 avril 2018 à 19:28:50

gbdivers a écrit:.

Deedolith a écrit:

Resultat, on en vient à proposer des solutions "les moins crades".

Est-ce l'intérêt de l'apprenant qu'on lui apprenne des choses incorrectes ?

Hola, ne me fais pas dire ce que je n'ai pas dit.
Certes apprendre de mauvaises chose n'est pas son intérêt (c'est pour ca qu'on est la, entre autre), mais rendre un devoir avec des réponses "non attendues" (donc fausses du point de vue du correcteur/enseignant) n'est pas son intérêt non plus.

C'est malheureux, mais dans la pluspart des cas:
int* ptr = new int; Ca vaut 20/20.
std::unique_ptr<int> ptr = std::make_unique<int>(); Ca vaut 0/20.

Deedolith a écrit:

C'est malheureux, mais dans la pluspart des cas:

int* ptr = new int; Ca vaut 20/20.
std::unique_ptr<int> ptr = std::make_unique<int>(); Ca vaut 0/20.

Cela dépend encore du prof...

je l'ai déjà expliqué, j'avais un prof qui ne prenait en compte que le résultat final (et les avertissements émis par le compilateur), sans s'inquiéter outre mesure de la manière dont on l'obtenait.

C'était sympa, dans le sens où, bien qu'il s'attendait à l'époque (C++11 n'était encore qu'une chimère à l'époque ) à voir une bonne vieille gestion de la mémoire "à la main", il acceptait volontiers qu'on utilise les classes "faites pour" (std::string et std::vector, et toutes les autres).

Bien sur il se mettait à la recherche des cas "peau de banane" qui feraient planter l'application ou qui fourniraient un résultat erroné, surtout si des avertissements étaient émis par le compilateur.

Je trouve que cette approche du genre "le résultat avant tout" est particulièrement méritoire