Discussion :

[Luc Hermitte]

Est-ce que la taille du code compilé est la même qu'en C ? Pour de petit micro controller, je pense que ça fait la différence, on a pas forcément envie d'un RPI juste pour prendre une température et la transmettre.
Je me trompe peut-être (trop longtemps que je ne pratique plus le C++)

Oui elle peut l'être. Elle peut même être moindre grâce à des nouveaux outils absents du C, ou pour des raisons obscures aussi (cf la video de Bartosz dont j'ai déjà donné le lien)

1- Ceux qui font du C aujourd'hui savent en général pourquoi ils ne font pas de C++. 2- Je ne vois pas un seul argument qui pourrait les convaincre d'en changer.

Perso, c'est le C pour tout ce qui est électronique ou demande de la performance. Si j'ai besoin de quelque chose de moins performant, nécessitant la POO c'est python3, C# ou mono pour windows

1- Cela démontre juste une totale méconnaissance du C++ de leur part. Quelle que soit la raison : réduction du C++ à du C avec OO, mauvaise foi, effet de groupe, apriori, pas le temps/volonté de monter en compétence sur cette techno, ...
2- Mais comme tu le dis très bien : aucun argument ne les fera changer d'avis. Ca rejoint le message récurrent de Dan Saks : "If you argument, you loose!". Et c'est n'est pas un problème de véracité technique derrière les arguments. C'est un problème humain.

C'est compatible. Ce n'est pas trivial, mais c'est possible.

Pour ceux qui voudraient plus de détails sur comment implémenter correctement equals en Java, je conseille la lecture de l'article suivant, à partir de "Pitfall #4: Failing to define equals as an equivalence relation" :
http://www.artima.com/lejava/articles/equality.html
L'auteur prend en exemple une classe ColoredPoint qui dérive de Point.

Et l'auteur rappelle que cette implémentation n'est pas compatible avec le LSP:

One potential criticism of the canEqual approach is that it violates the Liskov Substitution Principle (LSP). For example, the technique of implementing equals by comparing run-time classes, which led to the inability to define a subclass whose instances can equal instances of the superclass, has been described as a violation of the LSP.5 The reasoning is that the LSP states you should be able to use (substitute) a subclass instance where a superclass instance is required. In the previous example, however, “coll.contains(cp)” returned false even though cp's x and y values matched those of the point in the collection. Thus it may seem like a violation of the LSP, because you can't use a ColoredPoint here where a Point is expected. We believe this is the wrong interpretation, though, because the LSP doesn't require that a subclass behaves identically to its superclass, just that it behaves in a way that fulfills the contract of its superclass.

Il botte en touche en disant que ce n'est pas important car le LSP exige juste un respect du contrat des parents. Justement j'estime qu'il y a rupture du contrat des parents.
Dans Effective Java, J.Bloch conclue que la seule bonne implémentation ici, c'est la composition. En C++, on a aussi l'héritage privé.

[Iradrille]

Je ne vois pas un seul argument qui pourrait les convaincre d'en changer.

L'argument de "transformer" des erreurs d'exécution en erreurs de compilation est pourtant assez fort.
Il est plus simple (une fois qu'on a compris comment lire les centaines de lignes d'erreurs à cause des templates ) de corriger une erreur de compilation qu'une erreur d’exécution; et on a la garantie que cette erreur sera corrigée.

Le C++ permet de mettre en place des abstractions de plus haut niveau que le C (ou plus facilement en tout cas); tout en étant capable d'une approche aussi bas niveau que le C (intrinsincs / inline assembly).

[nikko34]

A noter qu'actuellement il y a de gros efforts pour justement simplifier les messages d'erreurs rebutants des compilateurs.

[Pyramidev]

Justement j'estime qu'il y a rupture du contrat des parents.

-Si ColoredPoint dérive de Point,
-si on pose comme contrat que deux objets de type Point ou qui dérivent de Point sont égaux ssi ils ont les mêmes coordonnées et
-si on pose comme contrat que deux objets de type ColoredPoint sont égaux ssi ils ont à la fois les mêmes coordonnées et aussi la même couleur
alors, oui, forcément, si on veut que ces conditions soient remplies par la même fonction de comparaison, on arrive à une contradiction.

Mais, ça, c'est la faute de celui qui rédige les contrats, pas de l'OO. Il faut juste plusieurs fonctions de comparaison.

Par exemple, en C++, on pourrait faire ceci :

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
44
45
46
class Point
{
    friend bool operator==(const Point& lhs, const Point& rhs)
    {
        return (lhs.m_x == rhs.m_x) && (lhs.m_y == rhs.m_y);
    }
public:
    bool equals(const Point& other) const
    {
        return canEqual_1(other) && other.canEqual_2(*this);
    }
    // ...
private:
    virtual bool canEqual_1(const Point& other) const
    {
        return (*this == other);
    }
    virtual bool canEqual_2(const Point& other) const
    {
        return true;
    }
    // ...
};
 
 
class ColoredPoint : public Point
{
    friend bool operator==(const ColoredPoint& lhs, const ColoredPoint& rhs)
    {
        return static_cast<const Point&>(lhs) == rhs && (lhs.m_color == rhs.m_color);
    }
public:
    // ...
private:
    bool canEqual_1(const Point& other) const override
    {
        const ColoredPoint* that = dynamic_cast<const ColoredPoint*>(&other);
        return that != nullptr && (*this == *that);
    }
    bool canEqual_2(const Point& other) const override
    {
        const ColoredPoint* that = dynamic_cast<const ColoredPoint*>(&other);
        return that != nullptr;
    }
    // ...
};

Pour comparer deux objets de type Point ou qui dérivent de Point, on aurait alors le choix entre :
-equals(const Point& other) const pour la comparaison virtuelle et
-bool operator==(const Point& lhs, const Point& rhs) pour la comparaison de coordonnées.

A part ça, dans l'article, l'auteur utilise java.util.HashSet<E> qui ne permet pas de choisir la fonction de comparaison à utiliser. Mais, ça, c'est la faute de Java, pas celle de l'OO.

PS : Désolé pour le HS. Si la conversation se poursuit, je continuerai dans un autre fil.

[Iradrille]

-Si ColoredPoint dérive de Point,
-si on pose comme contrat que deux objets de type Point ou qui dérivent de Point sont égaux ssi ils ont les mêmes coordonnées et
-si on pose comme contrat que deux objets de type ColoredPoint sont égaux ssi ils ont à la fois les mêmes coordonnées et aussi la même couleur
alors, oui, forcément, si on veut que ces conditions soient remplies par la même fonction de comparaison, on arrive à une contradiction.

Mais, ça, c'est la faute de celui qui rédige les contrats, pas de l'OO. Il faut juste plusieurs fonctions de comparaison.

Par exemple, en C++, on pourrait faire ceci :

Code :

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

dynamic_cast

Dans 99% des cas dynamic_cast est synonyme d'erreur de conception, j'ai pas l'impression qu'on soit dans les 1% ici.

Vu l'énoncé, je verrais plutôt une composition.

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
struct Point {
   int x;
   int y;
};
 
struct Color { ... };
 
struct ColoredPoint {
   Point point;
   Color color;
};

Si ColoredPoint hérite de Point, il doit ÊTRE un Point (c'est le principe de l'héritage; et donc se comporter comme tel).
Aussi, un Point sera (très souvent) un POD -> pas d'héritage donc.

[Pyramidev]

Si la conversation se poursuit, je continuerai dans un autre fil.

Du coup, je viens de créer un nouveau fil : http://www.developpez.net/forums/d16...tuelle-equals/

[Bktero]

Le plus triste dans cette discussion sont les réactions épidermiques des développeurs C en embarqué qui donnent tellement raison à Dan Saks.

L'embarqué, c'est mon métier. Plutôt du gros embarqué (Cortex M notamment). Pour paraphraser Vincent PETIT, ça tombe dans les 5% des gros projets mais sans doute ceux qui concentrent 95% des lignes de code de l'embarqué. Ben oui car dans 1k de flash on met pas beaucoup de code mais dans 1Mo il y a de quoi faire.

Il y a quelques années, je ne jurais que par le C. Je pensais le C++ fait pour de plus gros cibles, genre RPi, je ne parle même pas de Java. Et puis j'ai travaillé pendant 4 ans avec Java sur Cortex M. Et j'ai changé de regard. Des fois, on code en assembleur car on a besoin de tout maitriser. Des fois on code en C car veut encore maitriser mais veut être plus productif. Des fois on prend Java car on a moins besoin de maitriser mais on veut être très productif. Le bon outil au bon moment. Un tournevis c'est bien, une viseuse électrique ça peut servir.

Depuis peu, je découvre le C++ pour l'appliquer sur Renesas RX113. Et je pense qu'il y a des choses intéssantes à faire. J'ai déjà mis en place un framework de génération d'évènements à partir de boutons et de sliders physiques, grâce à des classes. Et c'est pratique, simple, adaptable. Pour la suite, je vais regarder du côté des templates ce qu'on peut faire d'intéressant.

Je suis un peu de triste de voir autant de gens fermés et des réponses se résumant à "C++ je connais pas, l'OO je connais pas, alors plutôt que d'être curieux, ben je dis que C++ ça sert à rien". C'est le métier d'ingénieur que d'explorer, de tester, de se former, de réssayer quelques années plus tard pour voir si les choses ont évolué. Et ici, j'ai vu beaucoup de commentaires à l'opposé d'une démarche positive.

[CodeurPlusPlus]

Il existe aussi des personnes comme moi, qui ont beaucoup défendu C++ pendant des années, et puis qui en sont revenues et qui se sont remises au C.

[Firwen]

Il existe aussi des personnes comme moi, qui ont beaucoup défendu C++ pendant des années, et puis qui en sont revenues et qui se sont remises au C.

C'est souvent ce que font les personnes qui n'ont jamais pris le temps d'apprendre le C++ correctement oui.
Quand tu as compris la puissance du langage, et ce qu'il apporte en terme de généricité, safety, efficacité.... Tu ne reviens pas en arrière.

La plupart des programmeurs C arguent que la première faiblesse du C++, c'est sa complexité. C'est faux, et c'est déjà prouver qu'ils ne comprennent pas le C++.

En C++, la notion reine est "Tu paies pour ce que tu utilises". Et c'est aussi valide pour la complexité.

Si les templates SFINAE, les variadics sont trop compliqués pour toi, rien ne t’empêche de te limiter à un subset du langage avec une complexité limité, tu y gagneras dèja beaucoup en terme de safety et d'efficacité ( lock object, unique_ptr, basic OO, STL type safe containers.... ).

C'est ce qu'un paquet de boites qui font de l'embarqué font, pour de trés bonne raison. Même google pour certains de ces projets se limite à un subset qu'ils définissent à l'avance.

Je pouvais parfaitement comprendre les critiques des programmeurs C vs C++, il y a 10 ans, principalement due aux faiblesses de la STL à ce moment là ( copies inutile dans std::vector, auto_ptr , abus des functors, etc ). Tout ça a été corrigé avec C++11 elles sont complétement irrélévantes depuis 2011.

Aujourd'hui quand je vois des personnes qui pondent des cathédrales en C, impossible à maintenir, bourrées d'overflow, et de memory leaks, et généralement plus lente qu'un equivalent en C++... juste pour l'unique raison qu'ils ont la flemme d'apprendre correctement un nouveau langage..... j'ai une forte envie de mettre des coups de boules.


Je vais troller un peu en disant ca, mais C apparait maintenant comme un subset dépassé de C++ qui a malheureusement loupé son évolution. Preuve s'il en faut avec C11.

[vohufr]

Firwen, oui, tu as raison.

Personnellement, le C++ me donne pas envie, et plus ça avance, et moins j'ai envie. Pourquoi ?

A l'époque ou j'ai appris le C, j'hésitais avec le C++, qui me semblait assez accessible aussi. J'ai choisi le C pour le fun, et pour suivre le fil historique. Je m'étais toujours dis que j'ajouterai le C++ à mes compétences quelques années après.
J'ai dû apprendre le C# entre temps pour le boulot, ce qui n'a pas beaucoup demandé d'efforts. Je trouve que c'est un beau langage, et j'y ai trouvé tout ce que je voulais que le C++ devait m'offir.

Quand j'ai voulu me mettre au C++ l'an dernier... j'ai eu une douche froide. La syntaxe est devenue tellement complexe ! Le problème n'étant pas d'écrire soit même du C++, car il serait possible de ne pas utiliser toute la palette d'outil que ce langage propose. Mais lorsqu'on travaille avec d'autres personnes, c'est déjà pas évident avec un langage à la syntaxe réduire, mais là ça devient l'enfer.

Ayant tout ce qu'il me faut pour travailler, pourquoi on devrait faire de gros efforts à se se servir d'un autre outil ? De la même façon dont tu critiques les dev C qui font des grosses ****. Ok mais avec la palette d'outil du C++, imagine ce que ces dev seraient capable de faire

[nikko34]

Tu as des exemples de ce qui serait complexe aujourd'hui et pas avant? Parce que pour le code métier de base ("le code de tous les jours"), c'est sensé être plus simple qu'avant en C++1X. Enfin c'était le but.

Pour le code métier C++, et c'était pareil il y a 10 ans, ce que je passe toujours du temps à expliquer ce serait le passage de paramètres (passage par valeur/référence, les gens qui se souviennent de leurs cours d'algo papier n'ont pas de problèmes.. ils sont rare) et les différents usages de const. (Et oublier les pointeurs pour les dev C qui malheureusement ont le même opérateur & que les références, principale source de confusion). Je demande pas à tous les dev de me sortir des librairies en template ultra-générique, il y en a pas besoin.

Tout ça pour dire que je différencie toujours le code côté utilitaire/librairies qui peut-être complexe mais qui est au final un but pour simplifier le code métier qui devrait être la majorité du code.

[Matt_Houston]

Allez je viens troller un peu avec vous pour bien commencer la semaine.

C'est souvent ce que font les personnes qui n'ont jamais pris le temps d'apprendre le C++ correctement oui.
Quand tu as compris la puissance du langage, et ce qu'il apporte en terme de généricité, safety, efficacité.... Tu ne reviens pas en arrière.

Merci d'éviter la condescendance, les programmeurs C ne sont pas plus idiots que les autres. Et « en arrière »... euh non, c'est un autre langage pas une évolution.

La plupart des programmeurs C arguent que la première faiblesse du C++, c'est sa complexité. C'est faux, et c'est déjà prouver qu'ils ne comprennent pas le C++.

En C++, la notion reine est "Tu paies pour ce que tu utilises". Et c'est aussi valide pour la complexité.

Si les templates SFINAE, les variadics sont trop compliqués pour toi, rien ne t’empêche de te limiter à un subset du langage avec une complexité limité, tu y gagneras dèja beaucoup en terme de safety et d'efficacité ( lock object, unique_ptr, basic OO, STL type safe containers.... ).

Tu donnes tellement raison à Linus (emphase mienne) :

C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. [...]

Aujourd'hui quand je vois des personnes qui pondent des cathédrales en C, impossible à maintenir, bourrées d'overflow, et de memory leaks, et généralement plus lente qu'un equivalent en C++... juste pour l'unique raison qu'ils ont la flemme d'apprendre correctement un nouveau langage..... j'ai une forte envie de mettre des coups de boules.

Phrase complètement interchangeable si on remplace C par C++. Un mauvais programme n'est pas mauvais à cause du langage dans lequel il est implémenté.


En C, pour comprendre ce que ton code fait, tu lis la page de man.

En C++, pour comprendre ce que ton code fait, tu lis la page de man. Puis une autre. Puis encore une autre. Tu parcoures l'implémentation du template (imbitable). Tu vas faire un tour sur StackOverflow. Tu écris quelques tests unitaires pour bien être sûr. Tu vérifies le code assembleur. Tu retournes sur StackOverflow. Tu te rends compte que ce n'était pas la best practice, tu recommences... j'exagère à peine !

[ternel]

Sans blague... tu es si mauvais que ca?
Pour comprendre un code, je lis le code.
Puis je lis cppreference.com pour retrouver l'ordre des arguments que j'ai encore oublié (et que j'aurai aussi oublié en C)
Puis je lis la doc de la bibliothèque que le code manipule.
Puis c'est tout.

Quand je tombe sur stackoverflow, en général, c'est que je suis déjà en train de chercher à faire un truc bancal, et j'apprends pourquoi ne pas le faire, et quelle choix j'ai loupé.

Parce que comme tout outil, il n'est correctement utilisé que par quelqu'un qui a appris à s'en servir. donc, au minimum, lu la documentation.

Cela dit, au vu de la formation que je suis sur le point de donner, le gros apport du C++ au C, en toute circonstance, c'est le RAII.
L'art de ne pas gérer manuellement les problèmes, parce qu'ils sont géré automatiquement.

Et ca, ca ne demande que quatre choses: private, les constructeurs, le destructeur et la surcharge d'opérateur (pour l'opérateur =).
La partie couramment utilisée de la STL, c'est l'application du RAII: string, vector et map. et via C++11, les smart_ptr.

Autant dire que les bases sont enseignées en une heure, et que le reste, c'est prendre l'habitude.

Le reste du langage: template, lambda, move, etc, ca s'apprend après, et il convient surtout de savoir que ca existe, pour ne pas recréer la roue le moment venu.

[Bousk]

Tu parcoures l'implémentation du template (imbitable).

Je m'amuse pas plus à lire l'implémentation des template qu'à lire celle de memcpy ou toute autre fonction C que j'utilise.

[neuneutrinos]

Du point de vue de certains ici, les développeurs C seraient vu comme des mormons pas encore touché par la grâce fabuleuse du C++ !
Heureusement que ce n'est pas la majorité des avis ici et que les personnes respectent le choix des uns et des autres

C et C++ sont deux langage différents avec une conception différente et une philosophie de développement différents (ne serait-ce déjà que pour la POO)
Dans les deux langages, on peut faire le meilleur comme le pire.

Déballage de phrase générique sans rien dire : fait !
Ensuite, je programme dans différents langages, que ce soit pour moi ou pour mon travail (même un avec une base prolog )

J'aime bien programmer en C, et pas que de l'embarqué.
non pas parce que la C est le langage le plus performant de l'univers. (des raisons plus subjectives)
Comme je peux comprendre qu'on préfère la C++ ou n'importe quel autre langage.

Je n'aime plus le C++, et pourtant j'y ai développé plus qu'en C, ce n'est pas pour son apparente complexité , ni autre raisons rationnelles ou bien logique.
J'ai l'impression que le C++ a perdu "son âme", je ne m'amuse plus à développer comme avant. (cela ne m’empêche pas de faire ce que j'ai à faire, mais si j'avais le choix, je ne prendrais pas ce choix de langage)

Si cela [cppcon] donne envie a des personnes de tenter l'aventure C++, ( il y en a pleins qui veulent faire C->C++ dans leur apprentissage et leur dire qu'ils peuvent directement commencé par le C++ peut aider à mieux apprécier le langage).
Après ce qui ne veulent pas passer le cap ont fait leur choix, la moindre des choses et de le respecter même si cela pourrait sembler être un choix complètement irrationnel.

Étrangement l'échange d'idée n'a pas été aussi stérile que prévu, bonne surprise à vous lire !

[TJ1985]

>Sans blague... tu es si mauvais que ca?
Aimable apostrophe...

>Pour comprendre un code, je lis le code.
Tout code n'est pas forcément écrit par un humain. Certains comptables ont aussi sévi, ils sont incroyablement dangereux et pervers.

>Puis je lis cppreference.com pour retrouver l'ordre des arguments que j'ai encore oublié (et que j'aurai aussi oublié en C)
Ça, tout le monde peut faire, si il y a le temps.

>Puis je lis la doc de la bibliothèque que le code manipule.
Là, le projet va déborder, la compta doit tourner ce soir sinon la boîte ferme (Une banque, c'est comme ça)

>Puis c'est tout.
Oui, donc un peu court, et ça marche bien quand on bosse dans un environnement stable et des projets structurés. On n'a pas tous cette chance.

>Quand je tombe sur stackoverflow, en général, c'est que je suis déjà en train de chercher à faire un truc bancal, et j'apprends pourquoi ne pas le faire, et quelle choix j'ai loupé.

>Parce que comme tout outil, il n'est correctement utilisé que par quelqu'un qui a appris à s'en servir. donc, au minimum, lu la documentation.

Combien de langages et d'environnements maîtrises-tu ? Là aussi, tu as peut-être de la chance, et je t'envie. Dans ma vie, si on passait plus d'un quart d'heure sur la doc, c'est qu'on était nul...

>Cela dit, au vu de la formation que je suis sur le point de donner, le gros apport du C++ au C, en toute circonstance, c'est le RAII.
>L'art de ne pas gérer manuellement les problèmes, parce qu'ils sont géré automatiquement.

Je n'ai pas une grande pratique de C++ mais je lui avais trouvé bien d'autres agréments.

Et ca, ca ne demande que quatre choses: private, les constructeurs, le destructeur et la surcharge d'opérateur (pour l'opérateur =).
La partie couramment utilisée de la STL, c'est l'application du RAII: string, vector et map. et via C++11, les smart_ptr.

Autant dire que les bases sont enseignées en une heure, et que le reste, c'est prendre l'habitude.

Le reste du langage: template, lambda, move, etc, ca s'apprend après, et il convient surtout de savoir que ca existe, pour ne pas recréer la roue le moment venu.

Très affirmatif, très catégorique, très valable dans un aquarium. Pas dans ceux que j'ai fréquentés. Mais j'aurais bien voulu, vraiment ! Quant à l'apostrophe initiale, je n'en suis pas la cible, mais je l'ai tant entendue autour de moi... C'est si constructif, ça fait tant de bien.

[ternel]

Alors, oui, comme apostrophe, c'est un peu vif, mais c'est aussi pour réagir à des propos assez vifs.

Je code depuis près de 20 ans (j'ai commencé tot)
du C depuis 15, du C++ depuis 12, du java depuis 10.
Du php, du javascript (c'est même mon premier langage après le TI-basic)
du shell, du batch, du perl, et plein d'autre
Et aussi des choses pas forcément connues, comme le LSE89, l'assembleur

Bon, je ne donnerais pas des cours approfondis dans tous, mais je peux raisonnablement enseigner le C, le Java, le shell (surtout sa variante bash). Et je connais le C++ sur le bout des doigts (pour le langage), et pourrait lister le contenu de la STL, en dehors de la partie thread, je n'en ai pas encore eu besoin.

Et quand je dois utiliser un nouvel outil, oui, je prends le temps de comprendre comment il fonctionne, pour ne pas me contenter d'appuyer sur tous les boutons en priant.
C'est pour ce genre de raison que j'ai explorer une bonne douzaine de système d'automatisation de build, avant de me faire un SConstruct assez générique (mais pas parfaitement optimal).
J'ai travaillé en banque. et quand j'ai expliqué que je préfère prendre deux jours pour comprendre la chaîne de compilation et l'environnement de production, plutôt que de commencer à coder de suite, le chef de projet m'a remercié.
Résultat, j'ai pu refuser de faire une mise en prod qui aurait tout cassé.

"Dans ma vie, si on passait plus d'un quart d'heure sur la doc, c'est qu'on était nul..."
Dans la mienne, c'est qu'on n'est pas encore assez connaisseur.
Tu as appris à lire en un quart d'heure?
Tu as appris les maths en un quart d'heure?
L'histoire? l'anglais? ton langage de programmation du jour?
Félicitations, je suis preneur de ta méthode.

[Iradrille]

J'ai travaillé en banque. et quand j'ai expliqué que je préfère prendre deux jours pour comprendre la chaîne de compilation et l'environnement de production, plutôt que de commencer à coder de suite, le chef de projet m'a remercié.
Résultat, j'ai pu refuser de faire une mise en prod qui aurait tout cassé.

"Dans ma vie, si on passait plus d'un quart d'heure sur la doc, c'est qu'on était nul..."
Dans la mienne, c'est qu'on n'est pas encore assez connaisseur.

Il n'est malheureusement pas toujours possible de prendre le temps de comprendre le fonctionnement de ce qui est en place avant de coder. C'est stupide, une perte de temps (parce qu'on va faire du code de merde qui va entrainer une perte de temps quand faudra corriger), mais c'est comme ça.
Certains projets sont en retard avant même de commencer, et tout ce qui intéresse la hiérarchie c'est le sentiment que ça avance; donc poser des bases solides c'est pas possible, il faut quelque chose de testable (même si bancal) dès les premiers jours (en 20 ans, j'imagine que tu as croisé ce genre d'horreur).

Mais idéalement oui, tu as raison. Lire de la doc / apprendre à utiliser de nouvelles libs / outils / techniques ça fait parti du job.

D'ailleurs je serais vraiment curieux de savoir si des stats existes sur le ratio : "qualité du code vs nombre de recherche du Google / StackOverflow". Je mettrais ma main à couper que les deux sont proportionnels.
(Sur mon projet actuel, j'ai du faire une dizaine de recherche Google en 9 mois ).

[TJ1985]

Alors, oui, comme apostrophe, c'est un peu vif, mais c'est aussi pour réagir à des propos assez vifs.

Je code depuis près de 20 ans (j'ai commencé tot)
du C depuis 15, du C++ depuis 12, du java depuis 10.
Du php, du javascript (c'est même mon premier langage après le TI-basic)
du shell, du batch, du perl, et plein d'autre
Et aussi des choses pas forcément connues, comme le LSE89, l'assembleur

Bon, je ne donnerais pas des cours approfondis dans tous, mais je peux raisonnablement enseigner le C, le Java, le shell (surtout sa variante bash). Et je connais le C++ sur le bout des doigts (pour le langage), et pourrait lister le contenu de la STL, en dehors de la partie thread, je n'en ai pas encore eu besoin.

Et quand je dois utiliser un nouvel outil, oui, je prends le temps de comprendre comment il fonctionne, pour ne pas me contenter d'appuyer sur tous les boutons en priant.
C'est pour ce genre de raison que j'ai explorer une bonne douzaine de système d'automatisation de build, avant de me faire un SConstruct assez générique (mais pas parfaitement optimal).
J'ai travaillé en banque. et quand j'ai expliqué que je préfère prendre deux jours pour comprendre la chaîne de compilation et l'environnement de production, plutôt que de commencer à coder de suite, le chef de projet m'a remercié.
Résultat, j'ai pu refuser de faire une mise en prod qui aurait tout cassé.

"Dans ma vie, si on passait plus d'un quart d'heure sur la doc, c'est qu'on était nul..."
Dans la mienne, c'est qu'on n'est pas encore assez connaisseur.
Tu as appris à lire en un quart d'heure?
Tu as appris les maths en un quart d'heure?
L'histoire? l'anglais? ton langage de programmation du jour?
Félicitations, je suis preneur de ta méthode.

Bon, on ne va pas se disputer, de toutes façons c'est moi qui ai la plus grosse (carrière) : En 1988 j'étais responsable SI DOS-VMS, je codais en TurboPascal des softs entre les deux mondes. J'avais le temps de me former en continu, de lire et d'apprendre. Comme j'étais mauvais j'ai été pompé par une boite de soft, où j'ai eu moins le temps de réfléchir. Puis comme je ne m'améliorais pas j'ai été scotché chez un client de cette boite, en environnement VMS, puis Windows que j'ai contribué à introduire.
En route, sous VMS, j'ai co-écrit un environnement de développement en DCL, qui comme pas mal de mes trucs, est encore utilisé quotidiennement aujourd'hui.
Ceci pour dire que sur le fond, tu as raison, ta méthode est la bonne et comme je te l'ai dit, je t'envie. Mais à certains endroits ça ne marche simplement pas comme ça si tu as envie de bouger un peu dans la boite.
Car même en tant qu'externe perpétuel j'ai fonctionné comme décideur, aux manettes de l'architecture et des standards en plus du support 3eme niveau. D'autres gars ont travaillé "normalement", ils sont encore aujourd'hui en train de lire des docs et de réfléchir, en ne faisant que ce qui leur est demandé.
C'est un choix.

[sarnikoff]

Personnellement je suis sorti du marché , au moment de l' arrivée de C++
C'était le moment de l'intégration de travailleurs de l' EST ... Et
donc l' état nous "paya" des reconnaissances de compétances par des "formations".

Donc le grand débat de la programmation objet :
J'ai essayé de l'expérimenter en C mais aussi par le php5 .
Je ne suis pas convaincu.

Pour ex: je citerais l'annecdote de 1994 ( qui nous fut transmis au CESI d' Ecully) :
HP s'était lancé dans la récolte de ses objets : Plus de 5000, personne n'y voyait plus rien.
est
DONC : Pour moi se pose la capacité d' absorption
Pour le C++ : Les classes.
Mais aussi de toutes les fonctions : Car il y a celle que l' "on" fabrique mais qui existent déjà dans des bibliothèques que l'on ne connait pas.

Donc : Se pose pour quelle utilisation.
Parfois, on a besoin de reccourcir le temps de traitement, et on rentre dans le code objet.
Si je me souviens : Le C++ n' est qu' une forme de syntaxisme qui crée un mode de vision (objet) et donc qui signale les dérappagent par des règles de compilation qui seraient plutot des règle de précompilation.

Conclusion : Il s'gait d'un concensus ... pour justement pouvoir partager entre développeur ... Et je n'ai jamais connu cette phase ...