Discussion :

[Freem]

Comme pour le RAII, le langage nous donne des outils pour mettre en oeuvre l'OLTC : les scopes, la déclaration au milieu de la fonction (ça me manque horriblement en C ! *hop ce message n'est plus hors-sujet, z'avez vu ? *), les return multiples, la move-semantic, les pointeurs, and so on...

Tu as parlé (hop, un biais rapide) d'un code sans commentaire à un moment. J'apprécie, je fais pareil: raisons techniques (commentaire désynchronisés, ce qui inclue les doxycomment).
Pour raccrocher mon wagon à ma quote, au sujet des scope, j'ai énormément de mal à en avoir au milieu d'une fonction (en dehors des test/boucles, obvious)... puisque la moyenne de taille de mes fonctions est, je dirais, a peu près 15-20 lignes.
Pour ce qui est du nombre d'arguments qu'elles prennent (hop, je rebiaise) j'ai souvent constaté qu'il soit possible dans ces cas-là qu'un objet soit caché dans mon objet.

Bonjour,
a -- Je ne suis pas vraiment d'accord avec toi.
b -- [...] je ne vois pas l'intérêt de faire name() à la place de getName() au contraire.

c -- Déjà au niveau de l'auto-complétion [...]

d -- [...]Alors que name() : je peux faire quoi avec le "name" ? Obtenir un "name"? créer un nouveau "name"? passer un "name" à l'objet ? Convertir les données de l'objet en "name" ? Ou avec la surcharge de la méthode faire plusieurs de ces actions ?

e -- je n'ai toujours pas compris/pris conscience de l'intérêt d'éviter à tout prix de les mettre (parce que je pense tout de même qu'il doit y en avoir )

a :: moi non plus

b :: je vais utiliser un argument d'autorité (je sais, pas bien): tu préfères std::string::size(void)const ou std::string::getSize(void)const ? Personnellement, il me semble évident que "size" et "getSize" font strictement la même chose. En C++, les arguments et le const font partie du prototype. "throw()" aussi, d'ailleurs (ah, oui, pardon... noexcept() en C++11, ce me semble.)

c :: Franchement... l'auto-complétion, c'est une raison bassement technique. En plus, je n'en connaît aucune qui tienne réellement la route. Pour finir, quand tes classes sont assez petites, la liste est restreinte. Sauf si tu as une généalogie digne d'un hobbit forcément (vu qu'en ce moment ils sont à la mode... même si je ne suis pas sûr que la plupart des gens saisirons l'ensemble de l'image, clin d'oeil de rôliste).

d :: voire le point b: ne pas oublier la moitié du prototype. Si tu ne lui passes rien et que ça renvoie une valeur, il semble évident que tu souhaites récupérer quelque chose. Pour les points

Obtenir un "name"? [...] Convertir les données de l'objet en "name" ?

il n'y a aucune différence. En quoi est-il important que le contractant (le client, l'utilisateur, l'appelant, ce que tu veux) sache que tu construit une donnée à partir de l'état interne, ou que cette donnée soit déjà stockée?
C'est un détail d'implémentation qui ne regarde que l'expert, c'est à dire l'objet lui-même.

e :: on peut citer, par exemple, le fait que ton getter mentiras si tu considères que stocker une donnée deviens trop coûteux par rapport à la calculer les rares fois ou un client l'utilise, ce qui reprend ma remarque en d. La manière de procéder, les mécanismes internes, doivent rester cachés, afin d'avoir un code plus modulable et évolutif. C'est une question de flemme dans mon cas.

Ah ? Il me semblait au contraire qu'il démontrait qu'il était simple de les éviter avec une telle méthode. Tu peux développer ton point de vue ?

Il me semble que tu citais dans les erreurs (bien vu, d'ailleurs), le problème du '\0' de fin de chaîne.
L'index 0 est bel et bien un facteur d'erreur important, selon moi. Ca m'arrive encore, d'ailleurs, quand j'utilise un langage différent: certains considèrent qu'on commence à 1. Ca m'arrive encore quand je dois configurer du matériel qui n'est pas d'accord avec le logiciel (récemment: une saleté de switch avec nagios... il y avais un décalage de 1, et je l'ai appliqué dans le mauvais sens... shame on me).

Pardonnes moi de ne reprendre que cet exemple.

Tu sembles refuser SOLID, car cela te semble "trop stricte", mais, au final, tu semble pourtant appliquer les principes avec une rigueur particulièrement importante
Heu, de quels flux parles tu

Je crois qu'il à le même problème que moi, en fait, c'est à dire ne pas apprécier d'appliquer un principe sans le comprendre parfaitement
Que notre approche soit bassement pratique ou noblement (oui, je charrie) conceptuelle ne change au final rien au fait que le code est propre, et selon le côté que l'on prend, on applique réellement ces principes, ou ceux-ci deviennent la conséquence de nos habitudes et des leçons tirées des codes précédents.
Toi-même as admis, il me semble, t'être ramassé avant d'avoir découvert ces principes sur un forum comme quoi, l'expérience est nécessaire pour les appliquer (que ce soit pour les comprendre ou pour accepter de les utiliser, selon les gens... sauf s'il y a des moutons qui font sans comprendre et acceptent tout, mais pour un dev, ça relève d'un sacré problème s'il agit comme ça, selon moi)

Oui on peut commencer par du C++ en procédural. Car le débutant serait largué de commencer direct par de la POO.
Mais c'est donner de mauvaises habitudes au programmeur.

Pourquoi?
En quoi l'objet est-il constamment plus approprié que l'impératif?
Perso, il m'arrive de faire des gadgets. Quand je les commence, je commence par la fonction main. J'ajoute des fonctions. Quand elles manipulent les mêmes trucs et que j'ai la flemme de lire tant de lignes, au fil des ajouts, j'en fais une classe.
Pour ces gadget, je pars donc bel et bien d'un bête truc impératif...
Et si les classes avaient déjà existé, je me serai fait un plaisir de rester au niveau impératif, d'ailleurs.

D'ailleurs (attention, troll en approche) c'est une des raisons pour lesquelles je n'aime pas les langages purs OO: ils sont menteurs et trompeurs. Il suffit de voir le bidouillage crado autour de la fonction main: une classe programme, qui ne contiens souvent que la simple méthode statique main!
J'ai pas encore cité de noms, mais tout le monde à compris que je parle au moins de C# et Java, même si je restreint pas mon dégoût (que je surpasse sans problème s'il me faut manger ) pour ce type de mentalités "tout objet". Le pire, c'est que dans ces machins, tout le monde fornique avec tout le monde hérite du grand patriarche, ce qui fait qu'on peut caster une string en objet, puis l'objet en carré!

Ce sont ces quelques raisons, ainsi que les lignes de 200 caractères de large (celle-ci étant la première à m'avoir dégoûté pour java. Pour C#, c'était: nullptr.zero() ou un truc dans le genre), qui font que je préfère de très loin C++ malgré sa librairie restreinte.

[gbdivers]

@germinolegrand
Il me semble que tu oublies un point important (on a déjà eu des discutions équivalentes sur le chat) : l'intérêt d'avoir un vocabulaire commun est de faciliter la discussion. En inventant tes propres sigles, ne penses tu pas que cela peut nuire au travail dans une équipe conséquente ? Imagine si chaque personne de l'équipe utilise ses propres sigles ?

@Taurre
Merci, j'ai corrigé le if(str2) et le +1 dans l'article.

Pour le goto en C, il me semble avoir effectivement entendu que cela restait utile pour la gestion des erreurs, contrairement au C++ qui a d'autres mécanismes de gestion d'erreur

Pour le code que tu donnes, tu avoueras qu'il n'est pas des plus court et simple. Un débutant (ou pas) est quand même susceptible de se tromper à plusieurs endroits (le \0, realloc, oublier free, etc)
Je rappelle que le propos n'est pas de critique le C et montrer ses "défauts" (qui ne sont pas pour moi des défauts, mais plus des spécificités du langage), mais que ces 2 langages sont différents dans leurs approches, dans leurs gestions des erreurs, n'ont pas les mêmes difficultés et que donc leurs apprentissages doit être différent. En particulier, ne pas apprendre le C pour apprendre le C++

ne pas apprécier d'appliquer un principe sans le comprendre parfaitement
(...)
que le code est propre

Je ne reviendrais pas sur l'intérêt de la réflexion sur les principes et l'attitude que l'on doit avoir sur l'utilisation ou non des principes avant de les maîtriser, j'en ai parlé là.

Tes propos me font penser à une autre situation : lorsque l'on parle de gestion de ressources dans un constructeurs sans utiliser le RAII, beaucoup de personnes disent : "cela ne pose pas de difficultés, mon code est propre". Or, on sait que dans la majorité des cas, c'est faux : le code présente des problèmes qu'ils n'imaginent même pas (on le dit assez souvent que faire du exception-safe dans ces conditions peut être très compliqué).
Ne penses tu pas que tu pourrais être dans la même situation et penser faire du code propre alors que ce n'est pas le cas ?

[Neckara]

c :: [...] Pour finir, quand tes classes sont assez petites, la liste est restreinte. Sauf si tu as une généalogie digne d'un hobbit forcément (vu qu'en ce moment ils sont à la mode... même si je ne suis pas sûr que la plupart des gens saisirons l'ensemble de l'image, clin d'oeil de rôliste).

Je pensais surtout à Qt dont les classes ont une quantité impressionnante de méthodes.

d :: voire le point b: ne pas oublier la moitié du prototype. Si tu ne lui passes rien et que ça renvoie une valeur, il semble évident que tu souhaites récupérer quelque chose. Pour les points il n'y a aucune différence.

Lors de la recherche avec auto-complétion, on ne voit pas le prototype.

En quoi est-il important que le contractant (le client, l'utilisateur, l'appelant, ce que tu veux) sache que tu construit une donnée à partir de l'état interne, ou que cette donnée soit déjà stockée?
C'est un détail d'implémentation qui ne regarde que l'expert, c'est à dire l'objet lui-même.

Quand je fais un get, personne ne sais si la donnée est présente dans la classe ou si je la calcule.
Mais pour moi il y a 3 nuances :
- create : on veut créer une instance, elle a surtout un rôle de "factory"
- get : on veut obtenir une information (ex : position d'un élément graphique )
- to : on veut convertir les données de la classe. Ie sur une zone de texte, on peut faire un toString() pour récupérer le texte contenu dans la zone de texte mais on ne fera pas un toSize() pour récupérer la taille de la police.
Après derrière on peut avoir tout et n'importe quoi, le nom dépendant surtout de ce qu'on veut faire.

e :: on peut citer, par exemple, le fait que ton getter mentiras si tu considères que stocker une donnée deviens trop coûteux par rapport à la calculer les rares fois ou un client l'utilise, ce qui reprend ma remarque en d. La manière de procéder, les mécanismes internes, doivent rester cachés, afin d'avoir un code plus modulable et évolutif. C'est une question de flemme dans mon cas.

En quoi le "getter" ment-il si la données n'est pas réellement présente ?
get signifie juste "obtenir", mais rien n'indique qu'il existe et qu'il ne sera pas construit lors de l'appel de la méthode.
D'ailleurs comment l'utilisateur pourra-t-il savoir que la méthode "ment" ?

[stardeath]

outch, on parle de débutant, ça fait longtemps que les débutants ne peuvent plus lire cette discussion XD

b :: je vais utiliser un argument d'autorité (je sais, pas bien): tu préfères std::string::size(void)const ou std::string::getSize(void)const ? Personnellement, il me semble évident que "size" et "getSize" font strictement la même chose. En C++, les arguments et le const font partie du prototype. "throw()" aussi, d'ailleurs (ah, oui, pardon... noexcept() en C++11, ce me semble.)

le problème de size tout seul, selon moi, c'est qu'il casse une possible logique dans le nom des fonctions :
dans getSize (même si get est un mauvais choix) on a verbe + cible
alors que dans size on a seulement la cible.

si on adopte une convention verbe + cible + est ce que ça fait le café, size va clairement à l'encontre de cette convention.

pour des codes qui doivent s'autodocumenter ou sans documentation tout court, ça ne donne pas beaucoup d'indication.

c :: Franchement... l'auto-complétion, c'est une raison bassement technique. En plus, je n'en connaît aucune qui tienne réellement la route. Pour finir, quand tes classes sont assez petites, la liste est restreinte. Sauf si tu as une généalogie digne d'un hobbit forcément (vu qu'en ce moment ils sont à la mode... même si je ne suis pas sûr que la plupart des gens saisirons l'ensemble de l'image, clin d'oeil de rôliste).

l'auto-complétion permet quand même de se passer de la doc, et vu qu'il y en a pas souvent, et que effectivement les ide ne sont pas des devins, avoir une règle de nommage "standard" permet de très vite connaitre les possibilités offertes par une classe ou autre.

d :: voire le point b: ne pas oublier la moitié du prototype. Si tu ne lui passes rien et que ça renvoie une valeur, il semble évident que tu souhaites récupérer quelque chose. Pour les points il n'y a aucune différence. En quoi est-il important que le contractant (le client, l'utilisateur, l'appelant, ce que tu veux) sache que tu construit une donnée à partir de l'état interne, ou que cette donnée soit déjà stockée?
C'est un détail d'implémentation qui ne regarde que l'expert, c'est à dire l'objet lui-même.

e :: on peut citer, par exemple, le fait que ton getter mentiras si tu considères que stocker une donnée deviens trop coûteux par rapport à la calculer les rares fois ou un client l'utilise, ce qui reprend ma remarque en d. La manière de procéder, les mécanismes internes, doivent rester cachés, afin d'avoir un code plus modulable et évolutif. C'est une question de flemme dans mon cas.

pas d'accord, autant le prototype permet d'avoir beaucoup d'info, autant connaitre la logique interne est primordiale, si ta fonction met 5 secondes de temps de calcul, tu ne vas pas t'en servir de la même manière que celle qui retourne une valeur membre instantanément.

c'est d'ailleurs pour ça que tous les conteneurs stl doivent respecter une complexité documentée, tu vas choisir le conteneur (donc les services rendus par l'appel de ses fonctions membres) selon des critères d'implémentations.
la plupart du temps il est vrai que 1s ou 10s on s'en fout, tant que le service est rendu, mais toujours se cacher derrière ça ne fait surement pas amha un bon programmeur.

[gbdivers]

Je pensais surtout à Qt dont les classes ont une quantité impressionnante de méthodes.

Pas forcement un bonne exemple de pratique à suivre

[koala01]

Je crois qu'il à le même problème que moi, en fait, c'est à dire ne pas apprécier d'appliquer un principe sans le comprendre parfaitement
Que notre approche soit bassement pratique ou noblement (oui, je charrie) conceptuelle ne change au final rien au fait que le code est propre, et selon le côté que l'on prend, on applique réellement ces principes, ou ceux-ci deviennent la conséquence de nos habitudes et des leçons tirées des codes précédents.

Que tu apprennes de tes erreurs est presque la moindre des choses, nous sommes tous d'accord.

Mais encore faut il, parfois, accepter l'idée que l'on te présentes un principe pour te permettre de mettre le doigt sur une erreur subtile que tu referas encore et encore autrement.

Rappelles toi, par exemple, certaines discussions concernant LSP, dans laquelle de nombreux intervenants estimaient que si le compilateur acceptait quelque chose, c'est qu'il fallait considérer le principe avec une certaine souplesse.

De plus, il me semble quand même important de rappeler que je n'ai jamais ne serait ce que sous entendu qu'il fallait appliquer les principes sans les comprendre!

Si je n'ai fait que les citer dans cette discussion (du moins au début), ce n'est que parce que j'estime que leur explication n'entre pas forcément dans le cadre du débat

Lors de ma toute première intervention, je disais déjà

Une fois que le déclic se fait dans la tete du récipiendaire que le principe de Liskov est la clé de voute de tout ce qui touche à l'héritage, une fois que sont compris l'ensemble des principes énoncés par S.O.L.I.D.

et même si j'ajoutais par la suite

une fois (surtout) qu'il est clair qu'il ne faut en aucun cas envisager de déroger à ces principe (...)

j'exprimais quand même le fait qu'il fallait les comprendre pour pouvoir les appliquer de manière stricte.

Quelle que soit la discussion, lorsque je parle d'un des principes de SOLID, je ne refuse jamais la moindre explication dessus, car je sais très bien que seule la (bonne compréhension) du principe permettra à celui à qui je m'adresse d'accepter mon point de vue et de le faire sien

Toi-même as admis, il me semble, t'être ramassé avant d'avoir découvert ces principes sur un forum comme quoi, l'expérience est nécessaire pour les appliquer (que ce soit pour les comprendre ou pour accepter de les utiliser, selon les gens... sauf s'il y a des moutons qui font sans comprendre et acceptent tout, mais pour un dev, ça relève d'un sacré problème s'il agit comme ça, selon moi)

J'aurais été mal venu de ne pas admettre une évidence!

Ce serait manquer cruellement d'honnêteté morale que de laisser croire que l'on est arrivé avec la "science infuse" dans le développement

Mais, par contre, j'ai eu "la bonne idée" de me poser les bonnes questions à certains moments, et d'accepter de me remettre en question... Peut etre est-ce là ma plus grande victoire

Et j'espère que tu ne vas quand même pas me reprocher d'essayer de faire profiter les autres de mon expérience

Pourquoi?
En quoi l'objet est-il constamment plus approprié que l'impératif?
Perso, il m'arrive de faire des gadgets. Quand je les commence, je commence par la fonction main. J'ajoute des fonctions. Quand elles manipulent les mêmes trucs et que j'ai la flemme de lire tant de lignes, au fil des ajouts, j'en fais une classe.
Pour ces gadget, je pars donc bel et bien d'un bête truc impératif...
Et si les classes avaient déjà existé, je me serai fait un plaisir de rester au niveau impératif, d'ailleurs.

D'ailleurs (attention, troll en approche) c'est une des raisons pour lesquelles je n'aime pas les langages purs OO: ils sont menteurs et trompeurs. Il suffit de voir le bidouillage crado autour de la fonction main: une classe programme, qui ne contiens souvent que la simple méthode statique main!
J'ai pas encore cité de noms, mais tout le monde à compris que je parle au moins de C# et Java, même si je restreint pas mon dégoût (que je surpasse sans problème s'il me faut manger ) pour ce type de mentalités "tout objet". Le pire, c'est que dans ces machins, tout le monde fornique avec tout le monde hérite du grand patriarche, ce qui fait qu'on peut caster une string en objet, puis l'objet en carré!

Ce sont ces quelques raisons, ainsi que les lignes de 200 caractères de large (celle-ci étant la première à m'avoir dégoûté pour java. Pour C#, c'était: nullptr.zero() ou un truc dans le genre), qui font que je préfère de très loin C++ malgré sa librairie restreinte.

là dessus, je ne peux que plussoter

[Freem]

Ne penses tu pas que tu pourrais être dans la même situation et penser faire du code propre alors que ce n'est pas le cas ?

C'est effectivement très possible.

Je pensais surtout à Qt dont les classes ont une quantité impressionnante de méthodes.

Mon avis sur Qt n'est pas des plus élogieux, en même temps.
Mon avis sur la plupart des framework graphiques que j'aie testé non plus, d'ailleurs.

Lors de la recherche avec auto-complétion, on ne voit pas le prototype.

Est-ce un manque du langage, du source, ou de l'outil?

Mais pour moi il y a 3 nuances :
- create : on veut créer une instance, elle a surtout un rôle de "factory"
- get : on veut obtenir une information (ex : position d'un élément graphique )
- to : on veut convertir les données de la classe.

create: en général, on utilise un constructeur pour ça. Dans certaines situations ou la restriction causée par le nom du constructeur est gênante, il me semble que les gens mettent celui-ci en accès protégé (private/protected) et implémentent des méthodes statiques, qui, elles, appellent ce constructeur.

to: pour convertir, il y a les opérateurs de cast.
Bon, mon précédent argument d'autorité peut ici jouer contre moi, vu que std::string::c_str(void)const n'utilise pas cette technique. Je ne comprend pas pourquoi, au vu de la pénibilité que ça créée, notamment l'impossibilité d'utiliser aisément std::string avec des fonctions C comme printf ou même C++ comme le constructeur de ifstream.
J'imagine que le but est que tout soit explicite, mais je ne sais pas si c'est toujours une excellente chose.
Peut-être est-ce d'ailleurs du à une raison historique du début du C++, puisque explicit n'existe que depuis C++11 ?

En quoi le "getter" ment-il si la données n'est pas réellement présente ?
get signifie juste "obtenir", mais rien n'indique qu'il existe et qu'il ne sera pas construit lors de l'appel de la méthode.
D'ailleurs comment l'utilisateur pourra-t-il savoir que la méthode "ment" ?

Disons que quand je vois "getXXX", les enseignements et le code que j'ai vus procédant ainsi me font penser qu'il existe en interne une variable appelée XXX (ou m_XXX, ou... bref, dont la partie principale du nom est XXX).
Ce n'est pas un mensonge, en fait, plutôt une mauvaise interprétation due à un terme pas si explicite que ça et à mes enseignements passés au sujet desquels mon avis est moyennement positif (C with classes...).

[...]il casse une possible logique dans le nom des fonctions [...]
si on adopte une convention [...]

On est d'accord: si la convention de nommage dit qu'il faut indiquer le verbe, ou si le café est servi, toute le monde dois le faire.
Dans le cas de std::string, je doute que quiconque ait eu besoin, un jour, d'aller voir la doc pour comprendre ce qu'il fait.

l'auto-complétion permet quand même de se passer de la doc, [...] autant le prototype permet d'avoir beaucoup d'info, autant connaitre la logique interne est primordiale, si ta fonction met 5 secondes de temps de calcul, tu ne vas pas t'en servir de la même manière que celle qui retourne une valeur membre instantanément.

J'en déduis que l'auto-complétion ne permet pas de se passer de la doc.
Déduire est un mensonge de ma part, car je pense qu'on ne peux pas se passer de la doc, de façon générale. Il faut la lire au moins une fois, ou risquer des emmerdes longues à déboguer.

Ce que tu as introduit ici, c'est la notion de complexité de l'exécution, mais on aurait pu y ajouter le fait qu'une fonction puisse avoir différents niveaux d'exception safety et être ou pas thread-safe.
Toutes ces informations n'ont rien à faire dans le code, et la doc est la pour ça. S'il n'y a pas de doc (le source est une doc, s'il est lisible, selon moi) alors on peut se permettre d'avoir peur
Aucune auto-complétion ne pourra y changer quoique ce soit.

A moins, bien entendu, que pour pousser à l'absurde, il ne faille écrire: decltype(Data::size) getDataSizeO1TS(void)const noexcept();. Là, rien à dire, l'auto-complétion permet de se passer de doc... si on sait ce qu'est <Data> (note: la syntaxe est sûrement pas bonne, je n'ai pas encore trop joué avec decltype, c'est juste pour l'exemple).
Je me doute que ce n'est le propos de personne, hein, c'est plus histoire de montrer que "l'auto-complétion permets de se passer de doc" est, pour moi, une grosse erreur.
La lire, ne serait-ce qu'une fois pour comprendre les implications de ce que l'on utilise, est toujours utile. Mais je ne le fais pas moi même toujours. Je devrais... et j'ai déjà été embêté par cette mauvaise manie.

mais toujours se cacher derrière ça ne fait surement pas amha un bon programmeur.

C'est l'une des raisons qui font que je ne me considère *pas* comme un bon dev: je n'ai pas assez de connaissances dans le domaine de la complexité (entres autres... il y a aussi les DP que je maîtrise pas assez, et le multi-thread dans lequel je n'ai aucune expérience, rien que pour ce que j'arrive à voir en 20s).
Éventuellement un dev moyen.

Les gens qui se disent de bon dev d'eux-même, en général, je me méfie comme de la peste de ce qu'ils écrivent.

[Freem]

Et j'espère que tu ne vas quand même pas me reprocher d'essayer de faire profiter les autres de mon expérience

Bien sûr que si!
Imagines, si assez de gens faisaient pareil, on risquerait d'avoir des systèmes d'exploitations entièrement libres et de qualité, et je risquerais même de m'en servir!!!
Et quid du développement chiant et ennuyeux qui nous donne notre pain?

Ce serait absolument SCAN-DA-LEUX!


Je déconne bien entendu.
Ce que je voulais dire, c'est que c'est bien d'entendre parler des principes, mais ce n'est que l'expérience qui permet vraiment de s'en servir. Et qu'il arrive alors qu'on aie même oublié qui nous ait fallu les apprendre, tant ça paraît ensuite évident
Et du coup, tout en les appliquant, il est possible que l'on pense tout à fait sincèrement que l'on ne cherche pas directement à les respecter.

[iolco51]

Je vais volontairement jouer le provocateur, mais selon moi penser que le C++ est adapté aux débutants est une idée stupide. Le C++ est un langage complexe et compliqué, que même les experts devraient redouter. Point.
Si vous voulez me convaincre du contraire, soit vous mentez soit vous ne savez pas de quoi vous parlez .

Je ne vais pas rentrer dans les détails, ni plus avant dans le débat, mais pour faire bref le C++ est un beau bordel. C'est au delà des concepts OO et impératifs qui n'ont rien à voir dans mon opinion: surcharge des opérateurs (la pire idée jamais inventée selon moi), moyen bizarre d'utiliser les streams avec des opérateurs non cohérent avec le reste du langage, concept de pointeurs ET de références, heritage multiple (avec la joyeuse pagaille que cela peut engendrer), templates...etc.

En comparaison malgré ses défauts, le C est plutot simple et cohérent, très facile a lire. Le C est aussi une bonne introduction a la programmation système et bas niveau car très proche de l'assembleur en étant parfaitement lisible.

Enfin, si vous pensez que la compréhension de ce qui se basse en bas niveau (processeur, registres, allocation mémoire) est dispensable vous vous trompez. Si je devais conseiller deux langages aux débutants ce serait le C et pourquoi pas le python, mais pas tout de suite le C++.

Je vous invite par ailleurs a lire cet article que j'ai bien aimé:
http://damienkatz.net/2013/01/the_un...ness_of_c.html

[stardeath]

Si vous voulez me convaincre du contraire, soit vous mentez soit vous ne savez pas de quoi vous parlez .

tout ce que tu peux faire en c, tu peux le faire en c++. cqfd

c'est souvent un faux argument qui revient tout le temps, le c++ a des concepts compliqués DONC on est OBLIGÉ de les utiliser, les utiliser mal et sans suivre aucune convention d'écriture.

le c n'a pas ces concepts "compliqués" mais on peut très bien écrire du code inefficace, illisible et compliqué, tout dépendra du programmeur. Point

[Freem]

En comparaison malgré ses défauts, le C [...] très proche de l'assembleur en étant parfaitement lisible.

C'est le seul point auquel j'ai envie de répondre.

De quel assembleur parles-tu?
J'ai déjà vu à quoi ressemble l'asm x86 en mode réel, et le C n'a pas grand chose à voir... pas d'interruptions, pas d'équivalent à SWP, rien de comparable à ROR ou ROL (rotations de bits), la possibilité de ne tester que le flag ZF, pas la possibilité de pousser un argument supplémentaire à une fonction qui ne l'a pas prévu... (oui, je suis au courant pour les variadic arg, je ne parle pas de ça, ici)

Bref, le C est simpliste à côté de l'asm x86. Il y a d'autres, beaucoup d'autres, asm, comme le motorola, mais je ne les connaît pas.

C très proche de l'assembleur? Raté, le troll, rien à voir. Pour quelqu'un qui pense manifestement maîtriser le bas niveau, c'est regrettable de telles erreurs.
Si le C était proche de l'assembleur, il ne serait pas portable. C'est un niveau d'abstraction au dessus, et programmer en asm mode réel est bien plus simple que programmer en C.
Pour le fait que connaître grossièrement la structure interne d'une machine est important, je te rejoins, c'est une excellente chose pour la culture générale.
Ca s'arrête la.

Ou alors, il faudrait aussi enseigner aux gens les subtilités de l'ordonnancement des tâches, de l'allocation mémoire en mode protégé et maintenant les modes introduits par x86_64, les registres et instructions travaillant sur les flottants, la représentation physique d'un flottant...

Tout ces points améliorent certainement la compétence d'une personne, mais sont loin d'être vitaux dans 90% des applications. La preuve, de nombreux programmes Java, Basic et C# marchent très bien, quoiqu'on pense de ces langages.
Et de nombreux programmes C ou C++ plantent aussi très bien. Pas de cause à effet ici, pour moi.

[iolco51]

qui revient tout le temps, le c++ a des concepts compliqués DONC on est OBLIGÉ de les utiliser, les utiliser mal et sans suivre aucune convention d'écriture.

le c n'a pas ces concepts "compliqués" mais on peut très bien écrire du code inefficace, illisible et compliqué, tout dépendra du programmeur. Point

Merci. J'avais dit que je ne rentrerais pas dans le débat mais c'est plus fort que moi.

Je n'ai pas dit cela.

Donc ta logique est de faire débuter avec un langage "compliqué" sous prétexte qu'on peut aussi faire du code pourri avec des langage plus "simples"? Mais je ne vois pas en quoi cela rend le langage adéquat pour débuter.

Crois tu honnêtement qu'un codeur débutant ne sachant pas faire du C un petit peu propre saura faire mieux en C++?

Certes tu peux aborder plusieurs concepts différents avec du C++... Mais quel est l'avantage pour le débutant?
Et si tu n'utilises que le C++ pour débuter, quid de la programmation fonctionnelle?
Et les frameworks de tests en C++... En quoi une syntaxe compliquée va aider le débutant à écrire de bons tests?

Métaphore: un apprenti pilote de ligne doit-il commencer faire ses armes sur un boeing 787 ou sur un petit avion de tourisme, auquel cas les bases de l'aérodynamique s'appliquent de façon évidente a l'appareil et aux commandes du pilote?

[Klaim]

Crois tu honnêtement qu'un codeur débutant ne sachant pas faire du C un petit peu propre saura faire mieux en C++?

Je crois qu'un debutant en programmation a me fait de d'abord comprendre les notions haut niveau de la programmation (conteneurs, strings, comment acheminer et transformer l'information) avant d'avoir des details sur comment ca marche a l'interieur (pointeurs, gestion de memoire etc.)

C'est pas pour rien que le Python est souvent recommande comme premier language.

Certes tu peux aborder plusieurs concepts différents avec du C++... Mais quel est l'avantage pour le débutant?

Il est question de se concentrer sur l'essentiel de ce qu'est la programmation, pas d'apprendre tous les concepts d'un language.

Et si tu n'utilises que le C++ pour débuter, quid de la programmation fonctionnelle?

Quid en C aussi?

Au passage, il y a de la programmation fonctionnelle en C++, d'abord a la compilation (templates), mais aussi via les lambdas (meme si il va falloir attendre la prochaine version du language pour aoivr un truc plus complet).

Note: il se peut que tu confondes programation fonctionelle et programmation procedurale, il faudra que tu confirmes...

Et les frameworks de tests en C++... En quoi une syntaxe compliquée va aider le débutant à écrire de bons tests?

C'est des debutant, depuis quand on apprends directs aux debutants de faire des tests???

En plus des frameworks de test en C++ yen a des tas et ils sont tres efficaces et simples.

Métaphore: un apprenti pilote de ligne doit-il commencer faire ses armes sur un boeing 787 ou sur un petit avion de tourisme, auquel cas les bases de l'aérodynamique s'appliquent de façon évidente a l'appareil et aux commandes du pilote?

Cette metaphore n'a aucun sens parcequ'un pilote d'avion doit savoir toutes les bases du pilotage (theorie) avant de piloter (pratique). En programmation, la theorie et la pratique sont intriquees et on doit apprendre les deux ensemble sous peine de faire les memes remarques que toi (qui apparemment ne comprends pas bien les differences entre C et C++).

[gbdivers]

depuis quand on apprends directs aux debutants de faire des tests???

Ceci dit... ça serait pas une mauvaise chose d'apprendre la validation de code aux débutant (voir de la programmation par contrat et tout ce qui est lié) pour qu'il puisse s'auto-corriger

[stardeath]

Crois tu honnêtement qu'un codeur débutant ne sachant pas faire du C un petit peu propre saura faire mieux en C++?

comme dit un peu partout dans cette discussion, donc pour paraphraser, le c++ avec la stl à tout ce qu'il faut pour éviter les pièges du c.

donc sans les pièges manifestes, le code d'un débutant à beaucoup plus de chance de s'exécuter correctement, et non pas tomber en marche.

[Luc Hermitte]

Je vais volontairement jouer le provocateur, mais selon moi penser que le C++ est adapté aux débutants est une idée stupide. Le C++ est un langage complexe et compliqué, que même les experts devraient redouter. Point.
Si vous voulez me convaincre du contraire, soit vous mentez soit vous ne savez pas de quoi vous parlez .

Donc tu n'as pas lu l'article ou le débat. Tu peux le dire, ça se voit. Aller, je commence les confidences: en 99 j'étais tout autant persuadé que toi de la débilité de voir le C++ avant le C. J'étais jeune, je sortai de l'école et j'avais déjà vu le C (et bien d'autres choses). C'était donc logique de faire comme nos aïeux.

Bref, il était pourtant clair depuis le début que l'on n'a jamais parlé d'enseigner tout le C++ à la place du C. Mais le sous-ensemble impérativo-procédural équivalent au C, mais sans les erreurs et les pièges inhérents au C.

C est un des pires premiers choix possibles à mon avis. Le C++ n'est pas idéal, mais il est moins pire.

Métaphore: un apprenti pilote de ligne doit-il commencer faire ses armes sur un boeing 787 ou sur un petit avion de tourisme, auquel cas les bases de l'aérodynamique s'appliquent de façon évidente a l'appareil et aux commandes du pilote?

Tu as raison, il faut apprendre le latin avant le français. Sans voir d'abord les bases qui ont abouti à ce que nous avons aujourd'hui on ne peut pas s'exprimer correctement.

Une autre analogie fallacieuse ? Pour taper sur le clavier/marcher, nous pensons à bouger chaque muscle précisément et nullement à ce que l'on n'écrit ou où l'on va. Car le bas niveau, il n'y a que ça qui nous permette d'aller plus loin.

[white_tentacle]

pas d'accord, autant le prototype permet d'avoir beaucoup d'info, autant connaitre la logique interne est primordiale, si ta fonction met 5 secondes de temps de calcul, tu ne vas pas t'en servir de la même manière que celle qui retourne une valeur membre instantanément.

c'est d'ailleurs pour ça que tous les conteneurs stl doivent respecter une complexité documentée, tu vas choisir le conteneur (donc les services rendus par l'appel de ses fonctions membres) selon des critères d'implémentations.
la plupart du temps il est vrai que 1s ou 10s on s'en fout, tant que le service est rendu, mais toujours se cacher derrière ça ne fait surement pas amha un bon programmeur.

Tu te contredis un peu.

On a juste besoin de l’information de complexité, pas de la logique interne. Par contre, il est en effet très rare qu’on l’ait. Mais si size() renvoie une valeur directe ou le résultat de trois additions et une soustraction, ça ne change pas grand chose. Si j’en suis à ce niveau, je le verrai au profilage.

iolco51 : trop gros, passera pas

[iolco51]

C très proche de l'assembleur? Raté, le troll, rien à voir.

Non je ne suis effectivement pas expert en programmation bas niveau ni en assembleur, mais tu as probablement raison, le C++ doit être plus proche de l'assembleur. C'est un fait bien connu.
Merci d'attaquer sur mes compétences, je suis certain que tu es plus compétent que moi et que cette attaque élève le débat.


Pour ma part je serai moins catégorique: je pense que tu es simplement malhonnête dans ta façon d’interpréter mes propos.

Ce n'est pas parce que le C est portable qu'il est loin de l'assembleur et des concepts bas niveaux (c'est mon opinion et je peux le prouver).

Tiens faisons un test: dé-compile un programme simple écrit en C, le même programme en C++ (en utilisant les concepts c++ sinon ce serait le meme) , et compare les deux en ASM (celui que tu veux, peu importe la plate-forme) et dis moi sur lequel tu reconnais structurellement le programme tel que tu l'as écrit?

[iolco51]

Note: il se peut que tu confondes programation fonctionelle et programmation procedurale, il faudra que tu confirmes...



C'est des debutant, depuis quand on apprends directs aux debutants de faire des tests???

Non je ne confonds pas fonctionnel et procédural.
La programmation fonctionnelle a un bel avenir et il est selon moi approprié de l'aborder tôt, ce qui éviterait d'avoir a désapprendre un tas de trucs par la suite.

Je te rejoins sur le python.

En revanche je pense qu'un bon programmeur doit apprendre à des débutants à écrire des bons tests, pas toi?

[gbdivers]

Ceci est un échange d'idées, pas un débat télévisé. Merci de rester courtois, les écarts de langages seront supprimés et sanctionnés. Merci