Reprise du message précédent :

La vraie plus-value des écoles d'ingénieur elle est même au delà de ça dans la formation scientifique elle-même. Nico n'a pas entièrement tort quand il pointe le côté conservateur du système mais bon, pour comprendre des équations différentielles, des transformées de Fourier et des lois de conservation on n'a pas besoin d'un professeur disruptif, un vieux schnock qui connait son affaire fait le job très bien. Mes collègues qui ont fait des écoles d'info sont plutôt calés en maths et en stats mais l'idée est la même, les fondamentaux n'ont pas changé depuis 200 ans, et ces bases servent de socle à l'innovation. Maintenant, avoir une formation technologique pertinente c'est pas inutile non plus, et les écoles font ça assez bien je suppose (je saurais pas dire l'école où je bossais enseignait la mécanique avec des turbines construites dans les années 20), mais ça reste globalement des trucs qu'on peut apprendre en formation continue plus tard.

Je pense que c'est un tort, car je pense (en tout cas j'espère) qu'il existe d'autres manières d'enseigner les maths que ce que j'ai vu. C'est l'horreur pour les gens comme moi. Même si les maths sont vieilles, il doit bien y avoir une manière moins stupide et autoritaire de les enseigner.
 

 
 
Les deux points de vue se défendent complètement.
 
Cela dit, c'est pas en école que j'ai appris mes bases scientifiques, c'est en prépa.
 
En école, c'était marrant de voir les différences de perception et de compétences/connaissances entre les prépas et les IUT ou les BTS : les mecs étaient nettement meilleurs que nous en développement mais avaient des lacunes en maths. Ca s'est rattrapé en fin de première année (ils avaient moins d'info et des cours de maths à la place)
 
Mais quoi qu'il en soit, au moins dans l'école que j'ai faite, on n'avait pas de cours de maths. On n'avait un peu de théorie des graphes, mais très appliquée. On n'avait pas non plus beaucoup de cours de management/méthode, etc..
 
Et en fin de première année, on avait fait un projet en Java, un en C et un en Scheme (un fonctionnel), plus de la preuve de programme (je me souviens plus avec quoi), un peu de truc en assembleur...
 

Je sais pas, les vieux schnocks en question ont plein de manières différentes d'enseigner. La modernité n'est pas une qualité dans la mesure où le contenu est, par définition, vieux (et la pédagogie n'a pas non plus été inventée en 2015).

 
Tu en demande peut être aussi un peu trop pour un 1ere année?
 
Je me souviens qu'en fin de 1ere année on avait des notions de prog impératives, objet, BDD, Merise archi des ordinateurs, réseaux mais tous les étudiants ne les avaient pas assimilé.
 
Pour la plupart des étudiants j'ai toujours pensé qu'il fallait un peu de temps pour que les concepts rentrent.

Disons que d'un mec qui cherche un stage dans un environnement a 90% Java et web (JS, donc), j'attends qu'il ait des notions de java, a minima.

Tous ses "projets" ont été fait en C.
Du coup le mec est incasable en stage. A moins de trouver une boîte qui veuille bien faire le boulot de l'école.

j'imagine que dans le compromis entre les compétences à usage immédiat  
 mais qui  périment vites (la connaissance technique) et celles à long terme mais qui ne servent à rien toute seules ( la capacité a s'auto organiser notamment), epitech à fait son choix
 
D'un autre côté :  

• il est en première année d'école d'ingé, c'est l'quivalent du stage de découverte de  3eme  
• il va vite boucher les trous, mais il faut que le stage dure 4 a 6 mois pour que tu en vois les résultats

A Centrale en première année (donc à BAC+3), le stage c'était un stage ouvrier

J'ai fait une année chez Epitech que j'ai refusé de valider parce que, effectivement, c'est complètement creux et c'est une pompe à fric.
Ce qui me chagrinne au final, c'est que mon promier boulot, c'est après avoir eu un stage, et ce qui a retenu l'attention sur mon CV pour le stage en question, c'est le nom d'Epitech, parce que l'université de Besançon, c'est pas super vendeur

en vérité sur n'importe quelle classe t'as que 40% au mieux des effectifs qui a des notions potable de code après 2 ans
parce que le code c'est pas un savoir qui se transfère juste avec les heures de cours : faut que le mec investisse du temps à côté  
partant de là les généralités sur les bonnes et mauvaises écoles ...

+1, en première année tu sais pas faire grand chose.
 
Après je pense aussi que tous les bons codeurs que j'ai vu à la fac étaient des gens qui codaient hors des cours
 
In other news : c'est rigolo d'apprendre le C++ après avoir appris le Java et Python

 
Pis c'est bien c'est pas piégeux  
 
Par exemple en cas d'héritage faut juste se rappeler de bien utiliser "override" et "virtual". Et de mettre un destructeur virtuel dans la classe mère. Et aussi de se méfier si on appelle des méthodes surchargées depuis le constructeur dérivé. Pis de pas faire d'héritage privé. Et de ne jamais hérité d'un type de std:: . Etde faire gaffe au shadowing aussi tiens. Pis aussi de faire attention à ...
 
Enfin ça va j'ai pris une feature simple ici

Ça donne envie

 
Le fait que l'investissement hors des cours soit important n'empêche pas le fait que des cours peuvent être de bonne ou de mauvaise qualité et que les intervenants peuvent être vraiment qualifié ou non  

 
Pour ces points là, je suis moyen d'accord. L'héritage privé, c'est bien (typiquement, toutes les interfaces façon listener, ca ne devrait jamais être hérité en public), et quand tu dérives d'un type STL pour une raison ou une autre, tu veux précisément le masquer, donc aussi en hériter en privé pour avoir du contrôle sur les casts.

Ben dans ces cas là tu fais de la composition, pas de l'héritage   Surtout que les types de la STL (le standard l'interdit), je ne fais que de la composition si je dois encapsuler un vector ou autre.
Avec un héritage privé tu hérites de Foobar sans pour autant en être un, c'est tordu.

Entre clang-tidy qui gère la moitié des problèmes que tu mentionnes, et des reviewers relativement au point pour pas laisser passer le reste, je me fais pas de souci pour ça. C'est bon il va déjà assez galérer comme ça, c'est pas la peine de lui faire peur avec des trucs qui le concerneront pas !

VERBOTEN !!!

C'est quoi les arguments, à part "Michel a dit qu'on devait pas" ?

Edit : et accessoirement, pour implémenter un listener, déporter ca sur un membre, ca me semble encore moins malin que de le laisser public. Le mettre privé, c'est juste une meilleure encapsulation.

 
mais ça ne jouera qu'à la marge  
si tes cours sont bons dans les faits y a que ces 40% qui pourront le suivre parce qu'ils capteront les questions d'algo sans être emmerdé par des questions de syntaxe de code de compilation d'enchaînement logique ou de debug
d'où l'importance d'avoir des niveaux homogènes dans ces formations à mon sens  
mais ces écoles mine de rien elle sont grosses et ne sélectionnent pas au niveau, à vrai dire à part les écoles tip top haut du panier qui j'imagine sélectionne au niveau : qui sélectionne au niveau ? ces écoles sélectionnent à l'argent

Ben

1. le standard l'interdit, et donc ya rien qui empêche quelqu'un d'implémenter le standard de telle façon que l'héritage soit impossible/ne compile pas/crash.

2. les vector list deque et compagnie n'ont pas de destructeur virtuel

3. on peut faire exactement la même chose par composition (en ayant un vector comme membre privé)

 
Epita ça écrème un peu à l'entrée, mais c'est pas super difficile comme sélection. Ça écrème beaucoup en cours de route par contre.

j'ignoais  
 
Pour revenir au sujet avec l'âge je demande surtout aux candidats d'être honnête sur ce qu'ils savent faire. Je trouve que l'encadrement est plus complexe quand le mec est un point d'interrogation sur pattes.  
Et du coup c'est vrai je me méfie des mecs qui m'annoncent des compétences au dessus. Et sur les technos aujourd'hui je trouve que la mémoire est prépondérante : faut se souvenir que tel truc doit être dans tel fichier de conf  
Mon côté vieux con mais j'ai l'impression que ça a explosé :  à l'époque on se plaignait de la complexité et de l'aspect découplé de struts, maintenant ça donne presque envie.

Perso j'étais à SUPINFAIL, c'était parfait pour moi après un IUT Info à Grenoble au top (meilleur formation ever pour la technique ) et un Bachelor of Science in CS au UK. Tu pouvais pas trop bosser, et avoir un BAC+5 Par contre tout bien réfléchi, j'aurai mieux faire de faire un truc genre GEM ou truc orienté business au lieu d'un bac +5 en « spécialiste en système d'information ». Mais ça je pouvais pas deviner avant de monter ma boîte

edit : je compte pas mes 2 premières années de fac qui ont servi à rien en terme de diplôme, mais au top pour la culture scientifique

tu sais où c'est précisé dans le standard ?
Edit : ma question est sincère, j'ai tenté de chercher rapidement et j'ai perdu patience vu que je suis au boulot.

C'est précisément la raison pour hériter en privé : personne ne peut t'upcaster vers le type dont tu dérives, donc ca empêche ce genre de scénario.

Non, on ne peut pas : exposer les fonctions que tu veux retrouver dans ta classe fille via using est plus efficace que faire des fonctions inline pour rediriger de ta classe vers ton member. Quand les optimisations sont activées, certes, ca n'a aucun avantage, mais ne pas dégrader inutilement les perfs en debug est aussi important sur les projets sur lesquels je travaille.

En fait c'est marrant c'est l'inverse, je viens de regarder ( http://www.open-std.org/jtc1/sc22/ [...] /n4713.pdf   20.4.1.3)  l'héritage est mentionné comme possibilité   Je vais vérifier tout ça.

Bah tu te fais une classe de facade dont tu hérites et c'est marre   Le coût d'appel n'est même pas mesurable (un peu comme le mythe qui dit const = meilleur perf )

(bonus point tu mets tout en protected et ne repasse que ce qui t'arrange en public avec des using)

 
Okay, merci pour la recherche, parce que ca me semblait plutôt surprenant
 

 
A nouveau, ce genre de comportement généralisé, quand tu fais tourner un build en debug avec des endroits où tu as des tight loops, le coup des appels de fonction inutiles peut ne pas être négligeable. C'est le côté difficile dans l'effort de conserver des perfs en debug, tu perds énormément de temps parce que ta base de code est remplite de pratiques inefficaces "parce que le compilateur est malin", et souvent, le code pourrait être mieux écrit sans compromettre la maintenabilité.
 
Ta proposition ici a les défauts des deux côtés.
 

 
C'est exactement ce qu'on fait quand on hérite en privé : on réexpose juste le minimum vital de la classe parent.
 
Edit : le coût qui n'est "pas mesurable", c'est comme la pratique d'instrumenter son code pour indiquer au compilateur/CPU quelle braénche va être prise dans un test. Quand c'est juste changer un seul if statement, ca ne t'apporte souvent pas un gain visible, mais si toute ta base de code a pris ce coup là, tu peux assez aisément vérifier que désactiver cette optimisation a un impact non-négligeable sur l'application complète, sur les plateformes où c'est applicables.
Ca m'amène aussi à ajouter : certes, "Premature optimization is the root of all evil", mais se contrefoutre des performances en permanence est aussi parfois contre-productif

Non mais les branches ok oui, mais vraiment essaie de mesurer en debug avec un profiler le coût d'une indirection supplémentaire de fonction, même dans ton point le plus chaud, même au cœur d'un algo qui prend plusieurs minutes, tu ne le verras pas (cas vécu sur de la simulation numérique de modèle physique, on est sur du bruit de mesure).
Ou alors tu as des algo qui ne font rien, à la limite là ça peut ptet devenir mesurable ok

 
A nouveau, c'est même pas le seul angle d'approche dessus : faire une façade sur ce cas, c'est juste un des exemples où on rajoute du code inutile sans apporter d'avantage en terme de maintenabilité. L'accumulation de tous ces endroits où tu gâches "un peu" sans justification, c'est ce qui fait au final que tu as un jeu "utilisable" en debug poure reproduire des problèmes ou bien complètement inutilisable.
 
Aussi, quand tu parles de faire des mesures, j'ai du mal à croire que tu me parles de performance en debug, donc sans optimisations. Le code pour une fonction triviale en debug est loin d'être négligeable : https://gcc.godbolt.org/z/bMhwyL

 
Je parle bien du coup de l'indirection en debug oui. Dans ton exemple si tu benchmarks, puis que tu remplaces Blah (ma solution) par Blih (ta solution) et que tu re-benchmarks tu ne gagneras rien    

J'ai du mal à croire que tous les cycles pour des instructions inutiles et la pollution du cache par des fonctions inutile soit gratuit.
J'ai pas la possibilité de faire un essai représentatif directement pour mon application, mais pour avoir observé des boîtes avec des approches différentes sur les perfs en debug, le résultat était parlant.

Bref, on a bien divergé du sujet initial, qui était : hériter d'une classe en privé, est-ce le mal absolu ? Je maintiens que non.

Edit : si quelqu'un veut comparer plus facilement, j'ai mis les deux versions ici : https://gcc.godbolt.org/z/WQ93pn

Aussi, pour les listener, je parlais de bonnes pratiques :

'tain hier j'ai vu le projet d'un mec c'était une carte électronique avec un FPGA à $1200 et une ram DDR4, routé avec kicad et excel
 
Il est vraiment balaise le type.

Chez nous ça vient d'une approche du language assez fool-proof, les aspects qui ont tendance à causer des problèmes quand ils sont mis dans les mains de quelques dizaines de milliers d'ingénieurs qui doivent utiliser une petite dizaine de languages de programmation différents sont gentiment écartés (et les barbus qui veulent absolument utiliser ces aspects sont poliment écoutés, et si ils sont assez convaincants ils ont le droit de faire comme ils veulent dans leur coin... mais en général, ils sont juste poliment écoutés).

 
je vous lis, et j'oscille entre  

 
et  
 
Message à caractère informatif - Berthier (celui sur la finance)
https://youtu.be/0MKcLhsq994?t=99
 
 

Moi plus je vous lis moins j'ai envie de faire du C++ (pas que j'avais initialement envie d'en faire hein...)

Demain nous aborderons les template et le pimpl idiom, ne zappez pas

 
FTFY
 

Sinon on peut parler OCaml si vous voulez  

on peut parler de l'env de dev de plamcorp pour ocaml aussi

 
Franchement il est tout à fait conforme aux standards du OCaml Demande à John (l'autre)

non, le merdier avec le docker pour compiler, le bordel avec un repo pour le code et un autre repo pour le RPM, devoir extraire tout ses changements dans un patch pour lancer un cycle e compil etc.