Discussion :

[stardeath]

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.

effectivement, c'est pas très clair, mais la complexité dépend quand même de comment ça a été fait derrière, entre un accès direct et un recalcul systématique, tu ne sais peut être pas comment ça a été fait, mais tu as quand même une idée du temps que tu vas consommer.

le profilage permet de voir ça, ok, mais ne peut on pas éviter d'envoyer l'aviation si un un téléscope suffit?
le profilage a un intérêt quand on a besoin de perf, on pourrait donc très bien se moquer de la complexité de telle ou telle opération dans des conditions normales, mais je suis moyen d'accord, si je peux éviter des calculs intutiles en modifiant que très légèrement mon code, je le ferai.

ça revient à faire un chouia du boulot d'optimisation, ça sert pas à grand chose, mais je me dis que je ne m'amuse pas à faire des trucs pour rien alors que je sais comment éviter.

[iolco51]

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.

... Je suis à court d'arguments: Ma vision de la STL n'est pas exactement le meilleur moyen de débuter en programmation (sauf pour débuter en C++, bien sur, mais ce n'était pas la question).

Si tu penses que dans l'absolu un débutant doit commencer par C++ avec la STL, il est évident que nous n'avons pas la même version de débuter et d'apprendre, et que nous n'arriverons manifestement jamais à un consensus.

Ceci dit je respecte ton opinion.

[koala01]

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.

As tu vu une seule intervention dans laquelle quiconque aurait prétendu que C++ n'est pas un langage complexe

As tu vu une seule intervention dans laquelle quiconque aurait laissé croire qu'il ne faut effectivement pas le pratiquer (très) longtemps avant de prétendre en avoir fait le tour

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

Ou peut être que l'on a, simplement, un point de vue différent de toi

Mais nous pourrions donc (vu que tout se résumerais à une question de point de vue) très facilement te faire les mêmes reproches.

Comme ce serait gaminerie que de tomber dans ce travers, je vais plutôt essayer de discuter en personne sensée

Je ne vais pas rentrer dans les détails, ni plus avant dans le débat

Et pourtant, tu as pris la peine de répondre... Cela dénote au minimum l'envie de rentrer dans le débat

Le problème, c'est que si tu ne veux pas donner de détail, il sera difficile d'avoir un débat constructif basé sur ton point de vue .

Un autre problème est que, à te montrer si catégorique sans vouloir, justement, expliquer ton point de vue, tu perds toute crédibilité (re)

mais pour faire bref le C++ est un beau bordel.

Il est vrai que C n'a absolument rien d'un "bordel" avec ses propres sucres syntaxique, bien sur

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)

A-t-on jamais dit nulle part qu'il fallait surcharger les opérateurs n'importe quand n'importe comment

Chaque fois que la surcharge d'opérateur est à l'ordre du jour, on attire au contraire l'attention sur le fait que cela doit se faire pour de bonnes raisons et de manière réfléchie.

Du coup, on veille à limiter l'usage de la surcharge d'opérateurs à ce qui a sémantiquement lieu d'être

moyen bizarre d'utiliser les streams avec des opérateurs non cohérent avec le reste du langage,

Pourquoi "non cohérent avec le reste du langage"

Parce qu'ils sont aussi utilisé pour le décalage de bits

Que faudrait il penser de l'étoile, gracieusement apportée par C, qui présente deux significations carrément inverse selon le contexte dans lequel elle est utilisée :question;

concept de pointeurs ET de références

En quoi est-ce un problème

Outre le fait d'éviter une copie qui leur est commun, pointeurs et références rencontrent des besoins différents

heritage multiple (avec la joyeuse pagaille que cela peut engendrer)

Encore une fois, où est le problème

Il n'y a rien conceptuellement parlant, qui interdise en quoi que ce soit l'héritage multiple!

Et je remarquais récemment que ce sont, assez bizarrement, les langages qui prétendent l'interdire qui, de par le mensonge de leur concept d'interface en font le plus grand usage

Alors, bien sur, l'héritage multiple est à considérer avec précaution, mais l'héritage l'est "à peine moins"

Et, surtout, l'héritage, qu'il soit multiple ou non, correspond à un besoin qu'il s'agit de pouvoir rejoindre

templates...etc.

Les template sont là parce que c'est un langage multi paradigmes

Bien sur, chaque paradigme que l'on ajoute à un langage apporte un degré de complexité supplémentaire à ce langage, mais, chaque niveau de complexité apporte son lot de souplesse (et sans doute de sécurisation) supplémentaire aussi

En comparaison malgré ses défauts, le C est plutot simple et cohérent,

Mais avec lequel tu dois être attentif à de nombreux points finalement "hors scope" de ton problème réel

très facile a lire.

Heu...

A condition que le code soit bien écrit, de respecter des règles de codage strictes et que l'on n'utilise pas trop de sucre syntaxique.

Ce qui est parfois loin d'être le cas (mais bon, c'est un problème que l'on rencontre dans tous les langages, y compris C++

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.

Sites moi une seule chose que tu pourrais faire en C que tu ne pourrais pas faire en C++

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.

A voir...

Note que, plutôt que de dire que c'est dispensable, nous disons plutôt que cela peut attendre d'avoir assimilé d'autres concepts

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

Ceci dit, je le répète encore une fois, le but de l'article n'est pas de dire qu'il ne faut pas apprendre C, ni même de venir donner un ordre d'apprentissage des différents langages, c'est de tordre le cou à cette idée fausse qui veut que l'apprentissage de C est un prérequis indispensable à l'apprentissage de C++.

C'est donc un débat totalement différent

[stardeath]

Si tu penses que dans l'absolu un débutant doit commencer par C++ avec la STL, il est évident que nous n'avons pas la même version de débuter et d'apprendre, et que nous n'arriverons manifestement jamais à un consensus. .

sans la stl, le c++ perd beaucoup de son intérêt pour le débutant, sans celle-ci on a effectivement que du c avec des concepts compliqués en plus, là je te rejoins totalement.

après je ne dissocie jamais la stl du c++, il y a des incohérences monstrueuses dedans, certes, mais c'est une des premières choses qui me vient à l'esprit quand on me demande les "avantages" du c++ par rapport au c.

[iolco51]

sans la stl, le c++ perd beaucoup de son intérêt pour le débutant, sans celle-ci on a effectivement que du c avec des concepts compliqués en plus, là je te rejoins totalement.

Est-ce que nous commencerions à converger?

[Freem]

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?

Je relève le défi.

Mais ce que les gens essaient ici de te faire comprendre, c'est qu'un des sous-ensembles du C++ est quasi-identique au langage C.

Quel concept C++ veux-tu que j'utilise?
L'objet?
Mais C++ n'est pas objet, il est orienté vers l'objet, et ses concepts sont, à ma connaissance, nombreux:
_ ne payer que ce qu'on utilise. Ca, c'est le coeur de C++. Printf est du C++, pour ceux qui ne veulent pas utiliser la RTTI intégrée par les flux, par exemple. Idem pour les exceptions, on peut les activer ou pas. Entres autres.
_ pouvoir faire de l'objet
_ pouvoir faire du structurel
_ pouvoir faire du générique

Maintenant que j'ai résumé quelques-uns des concepts C++, donnes-moi ton code C et l'assembleur qui va avec, je ferai la même chose en C++ et te montrerai les 2 sources asm et cpp.
Je te demande juste de te limiter un peu, j'ai pas envie de me palucher 1K LoC de code à écrire pour prouver une évidence.


Pour ma malhonnêteté... clairement, j'ai été mesquin et bas, mais tu t'amènes, sans argument, foulant des pieds tout ce qui à été dit avant, traitant les gens de menteurs ou d'incompétents.
Comment veux-tu que les gens réagissent, si ce n'est en te considérant comme un bon gros troll velu?

Quant au C++ plus bas niveau que le C... non, il est aussi bas niveau, et en même temps plus haut niveau.
Et, oui, si le C était proche de l'assembleur, il ne serait pas portable, car il n'aurait pas l'abstraction nécessaire.
Plus on abstrait le langage, plus on s'éloigne du matériel, et plus c'est portable. Du moins, c'est mon avis, corroboré par les gens qui emploient Java et HTML5, par exemple: ils prônent la portabilité plus importante que celle des binaires C et C++. L'artifice étant de passer par une machine virtuelle, qui elle spécialise l'abstraction.

[gbdivers]

corroboré par les gens qui emploient Java et HTML5

Hum, interdit de lancer un débat sur la portabilité du Java par rapport au C++, je garde ça pour une prochaine fois

[iolco51]

Et pourtant, tu as pris la peine de répondre... Cela dénote au minimum l'envie de rentrer dans le débat

...

Ceci dit, je le répète encore une fois, le but de l'article n'est pas de dire qu'il ne faut pas apprendre C, ni même de venir donner un ordre d'apprentissage des différents langages, c'est de tordre le cou à cette idée fausse qui veut que l'apprentissage de C est un prérequis indispensable à l'apprentissage de C++.

C'est donc un débat totalement différent

Merci pour cette longue réponse que ma provocation ne méritait pas vraiment.
C'est vrai, je me suis laissé prendre dans le débat bien que ce n'était pas dans mon intention initiale.

A lire ta tirade, je constate que nous ne serons manifestement jamais d'accord.
Je reconnais bien des vertus au C++. S'il y a toutefois une seule vertu que je ne reconnaitrai jamais à ce langage, c'est son adéquation pour enseigner aux débutants (avant le C puisque tu tiens à le préciser). Et je suis plutot surpris d’être le seul à penser ainsi sur ce forum d'experts (notez que je suis absolument sincère et je ne considère pas en faire partie).

Pour les amoureux du langage (et les autres aussi), voici un article que j'ai beaucoup apprécié sur la beauté du code de doom3 en C++ (mais je pense que vous l'aurez déjà lu, et que vous ne serez pas toujours d'accord avec l'auteur).
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
.

[koala01]

... Je suis à court d'arguments: Ma vision de la STL n'est pas exactement le meilleur moyen de débuter en programmation (sauf pour débuter en C++, bien sur, mais ce n'était pas la question).

Peut etre devrais tu te poser la question de savoir ce qu'est la STL et quel est sont but réel

Toute la STL n'est jamais qu'une abstraction de concept dont on te bassine dans n'importe quel cours d'algorithmie.

Son but réel est juste de prendre en charge de manière transparente et correcte tout ce qui, autrement, te détournerait des problèmes réels que tu dois résoudre.

Ainsi, l'ensemble des conteneurs qu'elle fournit (par exemple) ne sont ils que l'expression de concepts clairement définis, qui répondent à certains besoins clairement définis mais qui, si tu devais les implémenter par toi-même te feraient te heurter à certains problèmes complexes dont la gestion correcte de la mémoire et de l'allocation dynamique de celle-ci.

Si tu penses que dans l'absolu un débutant doit commencer par C++ avec la STL, il est évident que nous n'avons pas la même version de débuter et d'apprendre, et que nous n'arriverons manifestement jamais à un consensus.

Oui, bien sur...

Il ne doit pas, bien évidemment, commencer par décortiquer ce que fait l'ensemble des fonctions membres membre de tel ou tel conteneur, mais si tu lui indique comment l'utiliser, il pourra apprendre ce qui l'intéresse vraiment (comment arriver à demander dix nombres différents à l'utilisateur et à les maintenir au sein d'une collection, par exemple) sans avoir à s'inquiéter de "oui, mais aurai-je assez d'espace mémoire pour le faire" ou de "oui, mais que se passera-t-il si je veux passer à 12 ou à 13 ", chose dont il devrait s'inquiéter en C

Faut il te rappeler en outre que, classiquement, le premier programme que l'on écrit est un "hello world" et que ce premier programme attaque de manière systématique au moins un aspect de ce que l'on peut appeler "la bibliothèque standard" (quel que soit le langage envisagé) qui est: la sortie standard

[koala01]

Je reconnais bien des vertus au C++. S'il y a toutefois une seule vertu que je ne reconnaitrai jamais à ce langage, c'est son adéquation pour enseigner aux débutants (avant le C puisque tu tiens à le préciser). Et je suis plutot surpris d’être le seul à penser ainsi sur ce forum d'experts (notez que je suis absolument sincère et je ne considère pas en faire partie).

Mais la question n'est pas son adéquation à l'apprentissage pour un débutant, ni de savoir s'il vaut mieux l'apprendre avant ou après tel autre langage (C, en l'occurrence).

J'aurais d'ailleurs tendance à dire que l'apprentissage de C et de C++ devrait se faire en même temps (mais dans des cours clairement distincts), mais c'est un autre débat

La question est de savoir si la connaissance de C est un prérequis indispensable à l'apprentissage de C++, et là, la réponse est clairement: non

Pour les amoureux du langage (et les autres aussi), voici un article que j'ai beaucoup apprécié sur la beauté du code de doom3 en C++ (mais je pense que vous l'aurez déjà lu, et que vous ne serez pas toujours d'accord avec l'auteur).
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
.

J'ai effectivement très apprécié cet article, et, effectivement, je ne suis pas d'accord avec certains points, mais, contrairement à ce que tu pourrais croire à me lire, cela n'a rien à voir avec l'utilisation du C++ "pur" ou non: plutôt quelques détails par ci par là

[germinolegrand]

Allez, on reprend les discussions après une longue journée () de sommeil.

Comme d'habitude ça va me prendre 3h puisque vous avez eu le temps de remplir deux pages complètes (!). Vais essayer de prendre dans l'ordre.

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

C'est encore un autre débat (très intéressant), mais l'aborder ici serait totalement hors-sujet (je veux dire, encore plus que toutes mes interventions ici ).

c :: Franchement... l'auto-complétion, c'est une raison bassement technique.

Les raisons bassement techniques sont parfois les meilleures... taper machin.get c'est taper m_ ça permet d'accélérer je dirais d'un facteur x10 la vitesse d'écriture.
Quand on a à écrire un vrai getter, autant l'appeler par son nom. Il ne sert à rien de se voiler la face.

De plus prendre std::string en exemple ainsi que size() tel qu'il existe dans la STL est une mauvaise idée, car cela fait partie des choses les plus critiquées dans la STL.

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

Qu'on ne se méprenne pas : comme dit plus haut, je comprends bien les principes en questions, et les approuve comme étant d'excellentes analyses d'un code terminé. Ce à quoi je n'adhère pas c'est de les appliquer.

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

Je ne peux que plussoyer.

--------------

@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 ?

Contrairement à d'habitude, je n'invente rien ici, j'essaie seulement de combler un manque de vocabulaire !
Dois-je à chaque fois que je parle du contrôle de la durée de vie des objets réexpliquer en détail de ce dont je parle ? Cf le message de luc sur l'utilité des sigles.
Existe-t-il un terme pour parler de ceci ? si tu en connais un, je serais ravi de pouvoir l'utiliser. Dans le cas contraire, diffuser un nom commun pour en parler ne me parait pas une nuisance, au contraire.

Je ne vais pas parler d'OLTC à quelqu'un qui l'entend pour la première dois sans dire ce que c'est, ce serait stupide de ma part, c'est comme parler dans le vent. Mais pour ceux qui savent déjà de quoi je parle, eh bien il est tout simplement plus rapide de noter OLTC dans la conversation, d'ailleurs tout le monde s'est empressé de s'emparer de cet acronyme pour me répondre.

-----------------

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

De l'outils selon moi.

-----------------

As tu vu une seule intervention dans laquelle quiconque aurait laissé croire qu'il ne faut effectivement pas le pratiquer (très) longtemps avant de prétendre en avoir fait le tour

Stroustrup lui-même n'en a pas encore fait le tour .
Pour continuer dans la même logique, je préfère un langage qui me donne la possibilité d'en apprendre toujours plus qu'un langage limité.

-----------------

S'il y a toutefois une seule vertu que je ne reconnaitrai jamais à ce langage, c'est son adéquation pour enseigner aux débutants

S'il y a bien une vertu que je reconnais au C++11 (attention pas au C++03), c'est celle-là. Ce langage est outrageusement () débutant-friendly.

-----------------

La question que je me pose à chaque fois dans ce genre de discussions, c'est "de quelle version du langage parle-t-on ???", j'aimerais utiliser les arguments du C++11 correctement, mais comme il n'est pas encore assez répandu, j'ai peur de répondre à côté...

[koala01]

Qu'on ne se méprenne pas : comme dit plus haut, je comprends bien les principes en questions, et les approuve comme étant d'excellentes analyses d'un code terminé. Ce à quoi je n'adhère pas c'est de les appliquer.

Et cela ne te donne pas l'impression de "travailler à l'envers"

Que se passe-t-il, par exemple, si tu te rend compte qu'un principe n'est pas respecté lorsque tu analyse ton code terminé

A- Tu t'en fous, ca fontionne, c'est ce qui importe, et "on verra plus tard" en cas de besoin

B- C'est embêtant, corrigeons maintenant tant que c'est frais dans mon esprit

A titre perso, la réponse A me met très mal à l'aise, car je suis persuadé que j'aurai eu le temps d'oublier un détail ou l'autre d'ici à ce que le problème se pose, et que je vais donc perdre un temps bête à essayer de me souvenir de ce détail...

Cela revient à "reculer pour mieux sauter", et j'ai horreur de ca

La réponse B ne me convient pas d'avantage, car cela signifie que je dois revoir mon code, et sans doute modifier pas mal de truc pour arriver à respecter les principes qui ne le sont pour l'instant pas.

Et comme je l'ai dit, je suis fainéant: j'ai horreur de faire deux fois ce que j'aurais pu faire correctement dés le départ

Car soyons simplement pragmatiques et logiques: si j'avais pris le principe en compte avant d'écrire mon code, je ne devrais pas modifier mon code pour le prendre en compte maintenant, non

La question que je me pose à chaque fois dans ce genre de discussions, c'est "de quelle version du langage parle-t-on ???", j'aimerais utiliser les arguments du C++11 correctement, mais comme il n'est pas encore assez répandu, j'ai peur de répondre à côté...

AMHA, toute occasion est bonne pour faire la promo de C++11...

Pour l'instant, faut juste penser à préciser que ce que l'on dit y est spécifique

[Taurre]

Commençons par le plus simple: quelle connaissance dois tu avoir pour comprendre la structure et la fonction, selon toi (...)

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.

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

Je pense que mes propos ont été mal interprétés, aussi, je me permets de clarifié mon point de vue.

Tout d'abord, je n'ai pas d'avis concernant la question de savoir quel langage entre le C et le C++ est le plus adapté pour débuter la programmation. À mes yeux, il y a des arguments pertinents des deux côtés et il est, je pense, évident qu'il n'y a pas de solution universelle. D'après mon expérience, je pense que si je n'avais pas commencé par le C, je n'aurais pas accroché à la programmation.

Ensuite, je ne remets pas en cause le fait que le C n'est pas un prérequis à l'apprentissage du C++. Cela me paraît d'autant plus vrai maintenant que les deux langages se distancient de plus en plus. De même, je ne nie pas que le C++ fourni des outils qui facilite la gestion d'erreur et de la mémoire.

Là où je m'insurge, c'est sur le fait que les arguments avancé par l'article me paraissent fallacieux et non pertinents. En effet, il ne me semble pas convaincant de prétendre qu'il y a moins de risque d'erreur pour un débutant en C++ parce que certains comportements indéterminés en C engendrent des erreurs à la compilation et non des avertissements. De même, l'argument précisant qu'il y a des risques d'oubli de libération de ressources ne me semble pas approrié, cela pouvant également arrivé en C++ (il faut bien écrire des destructeurs par exemple). Bref, il me semble qu'il avait moyen de donner des exemple plus probant.

Enfin, l'article me semble au final faire l'apologie du C++ comme premier langage de programmation plutôt que d'exposé la non nécessité d'apprendre le C avant le C++.

[Neckara]

@Freem @germinoland : Oui c'est l'outils qui fait cela.
Ce n'est qu'une fois la méthode sélectionnée que le prototype apparaît.

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.

Dans un design pattern Factory, on aura une classe dont le but est de créer des instances (et d'initialiser) d'une autre classe.
Elle aura donc bien une méthode create() ou équivalant.

to: pour convertir, il y a les opérateurs de cast.

Dans certains cas, le cast ne suffit pas.
Certes on peut définir un opérateur de conversion implicite operator(Type) mais parfois on souhaite que cette conversion ne se fasse que de manière explicite.
Or il ne me semble pas qu'il soit possible de définir un tel opérateur (?)

[Luc Hermitte]

a- Allez, on reprend les discussions après une longue journée () de sommeil.

Comme d'habitude ça va me prendre 3h puisque vous avez eu le temps de remplir deux pages complètes (!). Vais essayer de prendre dans l'ordre.

b- De plus prendre std::string en exemple ainsi que size() tel qu'il existe dans la STL est une mauvaise idée, car cela fait partie des choses les plus critiquées dans la STL.

a- eh eh. Ca me le fait aussi ^^'

b- Ce qui est une mauvaise idée reconnue, c'est que cela soit membre et non libre. Alors tu imagine un peu la complétion sur std::size(monvecteur).
Et ma foi, où est le problème? C'est la même chose que les propriétés dans les autres langages (d'ailleurs les accesseurs sont le moyen d'avoir des propriétés en C++). Quand tu accèdes à ta propriété pour la complétion, tu connais son nom et commences à taper ses premières lettres. Où est le soucis avec les getters? C'est exactement pareil.
Si par contre, tu ne sais plus t' retrouver car tu as trop de choix pour compléter ... ne serait-ce pas que les SRP s'en serait pris plein la tête (comme les std::string quoi) ?

[Luc Hermitte]

Là où je m'insurge, c'est sur le fait que les arguments avancé par l'article me paraissent fallacieux et non pertinents.
a- En effet, il ne me semble pas convaincant de prétendre qu'il y a moins de risque d'erreur pour un débutant en C++ parce que certains comportements indéterminés en C engendrent des erreurs à la compilation et non des avertissements.
b- De même, l'argument précisant qu'il y a des risques d'oubli de libération de ressources ne me semble pas approprié, cela pouvant également arrivé en C++ (il faut bien écrire des destructeurs par exemple). Bref, il me semble qu'il avait moyen de donner des exemple plus probant.

a- pourquoi pas

b- là, pas d'accord. Ce n'est pas un risque d'oubli, mais une certitude d'oubli. Les cours de C ne passent pas le test de R.Chen (un if toute les deux lignes).
De plus, les destructeurs ne sont pas le sujet ici. Quand tu commences à les aborder, tu as déjà plusieurs semaines de cours sur le procédural, limite des mois, à jouer avec des tableaux et des chaines qui se libèrent tous seuls.

[koala01]

Là où je m'insurge, c'est sur le fait que les arguments avancé par l'article me paraissent fallacieux et non pertinents. En effet, il ne me semble pas convaincant de prétendre qu'il y a moins de risque d'erreur pour un débutant en C++ parce que certains comportements indéterminés en C engendrent des erreurs à la compilation et non des avertissements.

Le fait est qu'il y a quantité de choses qui ne peuvent pas être repérées à la compilation (ne serait ce que l'accès à un indice supérieur au nombre d'éléments d'un tableau) et que les comportements indéterminés sont :

1. ceux qu'il est le plus facile d'obtenir si l'on n'y prend pas garde
2. ceux qu'il est le plus difficile de corriger quand ils surviennent

Quand on en arrive au (2), c'est déjà trop tard: on va s'arracher les cheveux pour essayer de les résoudre, il faut donc essayer d'éviter au maximum le (1)

(je présume que tu ne pourras que plussotter à cette analyse )

Or, le nombre de choses qu'il faut assimiler pour éviter de se retrouver face au (1) est particulièrement important en C, je crois que tu ne me contredira pas sur ce point non plus

A l'inverse, C++ fournis des abstractions qui permettent justement d'éviter un grand nombre de ces comportement non définis de manière tout à fait transparente.

Bien sur, tu auras toujours un problème si tu essayes d'accéder à l'élément N alors qu'il n'y en a que N-1 dans ton tableau, mais on pourra se contenter de rappeler que les index basés sur 0, et l'on évitera, surtout, le risque lié à une tentative d'accès hors range en écriture (car, justement, push_back aura comme résultat d'augmenter la taille du tableau en cas de besoin).

Le fait de disposer de l'abstraction adéquate en C++ permet donc à l'étudiant de s'intéresser à son problème réel, sans avoir à s'inquiéter de problèmes dont il n'a finalement que faire (du moins dans un premier temps)

De même, l'argument précisant qu'il y a des risques d'oubli de libération de ressources ne me semble pas approrié, cela pouvant également arrivé en C++ (il faut bien écrire des destructeurs par exemple).

Oui, mais quand est-ce véritablement nécessaire

• Pour indiquer qu'il est virtuel: il est souvent vide, et ce n'est que pour s'assurer que l'objet de type dérivé sera détruit s'il vient à passer pour le type de base dans le cadre de l'héritage
• pour indiquer qu'il est protégé et non public: idem
• veiller à libérer correctement certaines ressources: avec la "RAIIsation" des pointeurs que permet les pointeurs intelligents (surtout en C++11, ou, à défaut, avec boost), c'est de moins en moins nécessaire
• Parce que l'on souhaite que le destructeur en fasse "un peu plus" que simplement détruire l'objet (ex: du logging):Bah, en première analyse, un destructeur n'est jamais qu'une fonction, même si elle a une utilisation particulière

Alors, oui, d'accord, le risque d'oublier de libérer une ressource reste présent, mais c'est bien pour cela que l'on incite le plus possible les gens à éviter les pointeurs nus et à leur préférer les pointeurs intelligents

Bref, il me semble qu'il avait moyen de donner des exemple plus probant.

Sur ce point, je ne peux pas forcément te donner tord

[koala01]

b- Ce qui est une mauvaise idée reconnue, c'est que cela soit membre et non libre. Alors tu imagine un peu la complétion sur std::size(monvecteur).
Et ma foi, où est le problème? C'est la même chose que les propriétés dans les autres langages (d'ailleurs les accesseurs sont le moyen d'avoir des propriétés en C++). Quand tu accèdes à ta propriété pour la complétion, tu connais son nom et commences à taper ses premières lettres. Où est le soucis avec les getters? C'est exactement pareil.
Si par contre, tu ne sais plus t' retrouver car tu as trop de choix pour compléter ... ne serait-ce pas que les SRP s'en serait pris plein la tête (comme les std::string quoi) ?

+1

[germinolegrand]

Ce qui est une mauvaise idée reconnue, c'est que cela soit membre et non libre. Alors tu imagine un peu la complétion sur std::size(monvecteur).

eheh, si bien je plussoie totalement.
edit: ma réponse ne veux rien dire désolé ^^', en clair je te donne raison, et mon argument ne tiens pas en ce qui concerne les fonctions libres .

Certes on peut définir un opérateur de conversion implicite operator(Type) mais parfois on souhaite que cette conversion ne se fasse que de manière explicite.
Or il ne me semble pas qu'il soit possible de définir un tel opérateur (?)

C++11 est la solution à ton problème, suffit de rajouter explicit devant

Et cela ne te donne pas l'impression de "travailler à l'envers"

Que se passe-t-il, par exemple, si tu te rend compte qu'un principe n'est pas respecté lorsque tu analyse ton code terminé

A- Tu t'en fous, ca fontionne, c'est ce qui importe, et "on verra plus tard" en cas de besoin

B- C'est embêtant, corrigeons maintenant tant que c'est frais dans mon esprit

A titre perso, la réponse A me met très mal à l'aise, car je suis persuadé que j'aurai eu le temps d'oublier un détail ou l'autre d'ici à ce que le problème se pose, et que je vais donc perdre un temps bête à essayer de me souvenir de ce détail...

Cela revient à "reculer pour mieux sauter", et j'ai horreur de ca

La réponse B ne me convient pas d'avantage, car cela signifie que je dois revoir mon code, et sans doute modifier pas mal de truc pour arriver à respecter les principes qui ne le sont pour l'instant pas.

Et comme je l'ai dit, je suis fainéant: j'ai horreur de faire deux fois ce que j'aurais pu faire correctement dés le départ

Car soyons simplement pragmatiques et logiques: si j'avais pris le principe en compte avant d'écrire mon code, je ne devrais pas modifier mon code pour le prendre en compte maintenant, non

Je garde le meilleur pour la fin .

Je vais répondre C : je n'analyse pas le code. Le seul code que j'analyse est celui des autres quand on me demande mon avis, ou à défaut pour ce que j'écris le code qui n'est pas destiné à la production (typiquement une composante générique destinée à rejoindre ma PSTL (STL personnelle, on en a tous une normalement ^^)) ou qui est académique.

Je n'analyse pas le code, j'analyse seulement les problèmes.

Mais mon approche est en fait une conséquence de mon impossibilité à trouver un outils externe me satisfaisant pour concevoir mon programme avant de le coder. Conclusion, mon outils de conception c'est le C++11 lui-même. Et je le trouve déjà très performant .

Comment conçois-tu tes programmes ? En jetant le schéma à la poubelle et en recommençant autrement ? Je fais pareil. Sauf que mon schéma c'est le code. Et j'ai la possibilité de tester si mon schéma est correct : si le compilo m'insulte, il me donne l'emplacement exact du problème à corriger.

SOLID, les DP, sont des techniques de conception sur papier/UML. UML j'essaye de temps en temps, à chaque fois j'en arrive à la même conclusion : il ne rend compte de rien du tout dans mon code. Alors je remplace ces techniques de schéma par des techniques de codage telles que le RAII, le const-correctness, l'OLTC, le codage explicite, ou le DNRY intuitif-progressif.

J'espère que ce paragraphe n'est pas incompréhensible (si oui, dites-le moi je reformulerai).

C'est pour cette raison que je juge les commentaires de documentation à la doxygen inutiles (pour un programme final j'entends, pas pour une bibliothèque où je les considère comme très important).

En C (oui, toujours l'art d'échapper au hors-sujet ) on vous répond RTFM. On essaye de combler par un manuel les déficiences du langage au niveau de la relecture. En C++11 je répondrai read the f*cking source code.

Voilà voilà, ce message appelle bien évidemment des réponses afin de débattre des nombreux sujets qui y sont abordés .

[koala01]

Mais mon approche est en fait une conséquence de mon impossibilité à trouver un outils externe me satisfaisant pour concevoir mon programme avant de le coder. Conclusion, mon outils de conception c'est le C++11 lui-même. Et je le trouve déjà très performant .

Oui, je comprends ce point de vue...

Moi aussi, je cherches désespérément un outil qui transforme mes diagrammes uml en code, me prépare le café et me l'apporte avec un petit gateau et un sourire

Mais, si on oublie le café, le gâteau et le sourire, bouml est pas si mal dans son genre

Comment conçois-tu tes programmes ? En jetant le schéma à la poubelle et en recommençant autrement ? Je fais pareil. Sauf que mon schéma c'est le code. Et j'ai la possibilité de tester si mon schéma est correct : si le compilo m'insulte, il me donne l'emplacement exact du problème à corriger.

Jusqu'à un certain point, en effet...

Mais il y a des décision de conceptions qui ne sont pas forcément opportunes et que le compilateur ne pourra pas vérifier (cf la discussion sur LSP que j'ai déjà citée )

SOLID, les DP, sont des techniques de conception sur papier/UML. UML j'essaye de temps en temps, à chaque fois j'en arrive à la même conclusion : il ne rend compte de rien du tout dans mon code.

Pourtant, si tu t'y prends correctement, la conception (de tes classes comme de tes algorithmes) devrait pouvoir être de "traduction automatique"...

Peut être t'y prends tu simplement pas "correctement"

C'est pour cette raison que je juge les commentaires de documentation à la doxygen inutiles (pour un programme final j'entends, pas pour une bibliothèque où je les considère comme très important).

Hummm...

Il y aurait beaucoup à dire sur le sujet, mais c'est un autre débat