Pourquoi le C++ est un langage plus adapté pour les débutants que le C ?

Citation:

---

Envoyé par Squisqui

Je n'avais pas visualisé la chose sous cet aspect précis.

En effet, la science du développement logiciel m'intéresse beaucoup à titre personnel. Le C++ me tâte et risque fortement d'y passer pour un projet qui se profile avec un groupe d'amis.

---

Le fait est que, en C++, tu as un éventail de possibilités qui va pour ainsi dire de la gestion du bit aux aspects les plus évolués que sont les programmations OO et génériques.

Le fait est que, grâce aux possibilités qu'il offre, et toujours sous réserve de se dire que la raison d'écrire tab.push_back(une donnée); sera expliquée par la suite, tu peux décider à tout moment de "creuser" aussi bien un domaine particulièrement "haut niveau" (par exemple l'un de ceux relatifs à la POO) qu'un domaine "particulièrement bas niveau" (par exemple, celui relatif à l'organisation des bits dans une structure) sans qu'il n'y ai réelle obligation de faire passer l'un avant l'autre.

Bon, d'accord, certains aspects apportent très certainement un éclairage nouveau sur d'autre, et facilitent même parfois l'apprentissage d'autres aspects, mais tu finiras sans doute par les avoir tous abordés simplement par "curiosité naturelle" (comprends: le fait de vouloir comprendre le pourquoi d'une solution à un problème particulier qui se pose à toi).

Par contre, en ce qui concerne C, les intervenants ont assez rappelé un fait important: il s'agit d'un langage impératif, non orienté objets.

La "limite haute" de ce qu'il te faudra apprendre pour maitriser C se situe donc à peu près au niveau des principes relatifs à l'encapsulation, et tu seras très rapidement confronté au problème de la gestion de la mémoire et des ressources.

Or, les problèmes relatifs à la gestion de la mémoire ou des ressources sont des problèmes qui ont trait à des domaines particulièrement ardus parce qu'il touche à quelque chose sur laquelle tu n'a aucune emprise: les limites du matériel dont tu disposes.

Tu pourras donc apprendre deux ou trois trucs "tout simple" comme ce qu'est une boucle ou ce qu'est un test et, tout de suite après, tu seras confronté à la nécessité impérieuse d'aborder un domaine des plus complexes, avant de pouvoir reprendre l'apprentissage d'encore deux ou trois trucs plus simples (une fois assimilé le truc complexe, du moins) comme la gestion de structures telles que piles, files et autres listes.

Rien ne t'empêchera, bien sur, de t'essayer à la mise en œuvre a mano de ces structures particulières en C++, mais, comme tu n'as pas forcément besoin de les maitriser pour avancer étant donné qu'elles sont déjà fournies par le standard, tu pourras attendre d'avoir "pris de la bouteille" avant de t'y frotter (ou, peut etre même ne jamais t'y frotter sans que cela ne te pose préjudice ;))

Citation:

---

Envoyé par Freem

Je suis jaloux de ton poste :)

---

Qui a parlé de poste :question:

Faire du C++ de son coté, pour un projet personnel, sur son temps libre, suivre des discussions sur le forum et se faire sa propre opinion, pour l'adapter au besoin de ses propres projets, c'est aussi faire du C++ à temps plein (bon, depuis trois ans, c'est à titre pro ;))

Citation:

---

Envoyé par Freem

Désolé pour le double post, mais flemme d'éditer mon dernier post.... ([edit]et en plus c'est pas un double post... pas mal celle-la[/edit])

---

Citation:

---

Et paf, ça à fait des chocapic.
Le déclic, j'ai compris que
1) les profs de mes souvenirs appliquaient bêtement un principe et le rendaient ainsi caduque, rendant le code plus lourd à manipuler (bah oui, des setter et getter qui ne font que lire ou écrire sans traitement un membre, c'est pire que le mettre en public pour moi). et écrire.
2) la solution, c'est de considérer que le nom des variables interne n'a absolument pas à être connu. "getName()"? Mais quelle horreur! Le nom "name()" est bien meilleur, pour moi. C'est un getter dans le rôle, mais plus dans le nom. Et le setter, c'est "rename(std::string const&)", pas "setName(...)".
3) conséquence de 2, j'ai compris que nombre de getter/setter peuvent juste renvoyer un résultat bâti en direct, sans nécessiter de stockage.
4) ces codes sont plus simples à écrire et maintenir si l'on évite de faire plus d'une chose par méthode/fonction. Conséquence: des fonctions de 20 lignes en moyenne.
5) quand on commence à discerner des jeux de fonctions utilisant des jeux de membres, c'est qu'il y a une classe à créer.

C'est malheureux, mais si j'appliquais bêtement le bourrage de crâne auquel j'ai assisté, plutôt que de merder à pondre du code dégueu un temps, mon code serait encore plus bourré d'anti-pattern et de doctrine qu'il ne l'est actuellement. Bon, ok, a l'heure actuelle, il n'est pas trop endoctriné, par contre je ne parierais pas au sujet des anti-pattern.

---

Et tu connais la meilleure :question: C'est que cela se rapproche finalement d'un autre aspect auquel je tiens beaucoup: la loi demeter :D

Je me fous personnellement pas mal que quelqu'un soit capable ou non de me dire à quoi correspond exactement le O de SOLID ou même qu'il ait déjà entendu parler de la loi demeter...

Si je les cite, c'est parce qu'il est en effet plus facile de les appeler par leur nom que de parler "du truc qui fait que...", et, quelque part, pour donner une chance à celui à qui j'en parle de se renseigner sur le sujet ;)

Ce qui m'importe surtout, c'est que le type ait une réaction correcte lorsque je lui pose la question de savoir s'il ne mettrait pas une fonction setReservoir à sa classe voiture ou quand je l'interroge sur l'opportunité de faire hériter la classe carré de la classe rectangle.

S'il veut parler d'un principe en commençant sa phrase par "c'est à cause du principe qui veut que...", tant mieux pour lui, il ne déméritera, à mes yeux, pas par rapport à celui qui me sortira l'acronyme du principe en question.

Et il vaudra beaucoup mieux à mes yeux que celui qui viendra me parler de n'importe quel principe sans savoir l'appliquer ;)

Finalement, les noms que l'on donne aux différents principes ne sont donné que pour que chacun parle de la même chose ;)

koala1 > J'en suis conscient, merci. C'est bien ce qui me tâte.
En 2ans, depuis ma première ligne de code, je me suis rapidement demandé en quoi consiste le C++. J'ai un peu tiré la gueule en voyant les opérateurs de décalage utilisé pour diriger des flux :aie:
J'ai abordé rapidement les notions les plus courantes, création de class, héritage, namespace, surcharges, polymorphisme... Mais n'ayant rien à faire en C++ pour le moment, j'ai un peu laissé pourrir. La reprise, lorsque mes projets actuels seront achevés très bientôt, abordera très sûrement les références dont je ne saisi pas le principe, suivi de la gestion d'erreurs dont je faisais abstraction à mes débuts.

Citation:

---

Envoyé par koala01

Finalement, les noms que l'on donne aux différents principes ne sont donné que pour que chacun parle de la même chose ;)

---

Bien d'accord. Le souci étant que par exemple, quand tu prends SOLID et que tu regardes GRASP à côté, il disent à peu près pareil.
Et il y en a d'autres...

Je sais que ma liste de points sont l'application de plusieurs principes, dont j'ignore la totalité des noms.

Ce qui m'intrigue, c'est cette manie de coller 20K noms à la même chose. Au final, ça ne fait qu'embrouiller le lecteur.

Pas étonnant que tu retrouves des ressemblances. Grasp sont des pattern (donc des solutions techniques à des problèmes spécifiques de design), SOLID sont des principes (donc des règles à des problématiques générales). On retrouve les SOLID dans les GRASP (puisque les objectifs finaux sont similaires : assurer la qualité du code)

Citation:

---

Envoyé par Freem

Bien d'accord. Le souci étant que par exemple, quand tu prends SOLID et que tu regardes GRASP à côté, il disent à peu près pareil.
Et il y en a d'autres...

Je sais que ma liste de points sont l'application de plusieurs principes, dont j'ignore la totalité des noms.

Ce qui m'intrigue, c'est cette manie de coller 20K noms à la même chose. Au final, ça ne fait qu'embrouiller le lecteur.

---

En fait, GRASP a visiblement une approche très fortement orientée MVC alors que SOLID a une approche exclusivement OO.

Ils parlent en effet de la même chose, mais à des niveau d'abstraction différents ;)

Quand tu regarde, GRASP s'intéresse :

• au controleur (MVC: tès haut niveau d'abstraction)
• à la factory (Desing pattern : très haut niveau d'abstraction)
• à un haut niveau de cohésion (quoi que cela veuille dire, c'est un niveau intermédiaire d'abstraction au minimum car il implique que l'on ait déjà les relations)
• à l'indirection (d'office un niveau d'abstraction supplémentaire!)
• à l'expert de l'information (à qui il faut déléguer la responsabilité : c'est un niveau intermédiaire d'abstraction au minimum car il implique que l'on ait déjà "la classe responsable")
• au couplage faible (cf haut niveau de cohésion ;))
• au polymorphisme (qui ne peut apparaitre que lorsqu'on a déjà des classes dérivée, c'est un niveau intermédiaire d'abstraction au minimum)
• aux variations protégées (qui utilisent plusieurs concepts que je viens de citer)
• à la fabrique pure, qui est un concept d'architecture système (donc, d'un niveau d'abstraction élevé).

SOLID s'intéresse quant à lui à des problèmes de très faible abstraction:

• S (SRP) responsabilité unique : chaque fonction, chaque classe ne fait qu'une chose mais la fait bien
• O (OCP) ouvert / fermé : le code doit etre ouvert à l'évolution mais fermé aux modifications
• L (LSP) substituabilité des types: quand peut on dire qu'un type est substituable à un autre
• I (ISP) ségrégation des interfaces : faire en sorte de travailler sur base d'interfaces, de services rendus et non sur base de données manipulées
• D (DIP) inversion des dépendances : le "haut niveau" ne doit pas dépendre du "bas niveau" (ni l'inverse), mais bien d'une abstraction

Alors, oui, il est clair que l'on retrouve les mêmes choses, vu que l'objectif est identique, mais le point de vue est, tout simplement, situé à un autre niveau (très bas pour SOLID, plutôt "assez élevé" pour GRASP)
[EDIT]Grillé par gbdivers :'(

Salut,

Sans vouloir paraître aggressif, les exemples avancés dans cet article me paraissent tout sauf pertinents et comportent qui plus est des erreurs (en tous les cas pour la partie C).

Citation:

---

Lorsque l’on compile avec un compilateur C, celui-ci ne donne qu’un simple avertissement sur le fait que l’on modifie une variable constante en non constante.

---

Heu... Cet exemple est censé démontrer que plus les erreurs sont détectées tôt, plus la correction de celle-ci est aisée. Or, ce passage démontre justement que le compilateur signale le problème... Là, tu démontres juste que le type qui ne lit pas les avertissements mettra plus de temps à trouver l'origine de son erreur.

Code:

---

1 2 3 4

int len = strlen(cstr); char* str = malloc(len); strcpy(str, cstr);

---

Je suis assez surpris que ce passage n'ait pas encore été relevé. D'une part, la fonction strlen retourne une valeur de type size_t (qui est, pour rappel, un entier non signé), tu as donc un risque d'overflow en l'assignant à une variable de type int. D'autre part, tu as oublié de compter le caractère de fin de chaîne.

Code:

---

1 2 3 4 5 6 7

char* bar(char* str) { char* str2 = realloc(str, strlen(str)*2); if (str) { str = str2; } else { printf("Error de réallocation"); } do_something(str); return str; }

---

Cela ne devrait-il pas être « if (str2) » ?

Citation:

---

Il est de la responsabilité du développeur de penser à appeler destroy() avant chaque return, ce qui peut être facilement oublié.

---

En effet, il est de la responsabilité du programmeur de libérer les ressources allouées. Cependant, en général, dans le cas de l'allocation de plusieurs ressources, on ne s'amuse pas à répéter les libérations à chaque return, on les prévoit une bonne fois pour toutes dans une fonction ou à la fin de la fonction. Un exemple utilisant goto :

Code:

---

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

struct str { char *data; size_t len; size_t max; };   struct str * str_create(void) { struct str *self;   if ((self = malloc(sizeof *self)) == NULL) { goto alloc_self_err; } if ((self->data = malloc(16)) == NULL) { goto alloc_self_data_err; } self->len = 0; self->max = 16; return self; alloc_self_data_err: free(self); alloc_self_err: return NULL; }

---

Citation:

---

Envoyé par germinolegrand

Pour ma part je considère le C comme obsolète. Non seulement parce qu'il n'est rien en C qui ne soit pas faisable aussi efficacement en C++, mais aussi parce que c'est un langage limité face au C++(11 encore plus) qui l'englobe tout en proposant plus de liberté, plus de flexibilité, et plus de paradigmes. En bref c'est comme si on avait le choix entre le tire-bouchon et le couteau-suisse complet.

---

Si je m'en tient à l'acception courante, « obsolète » signifie « Qui n'est plus en usage; tombé en désuétude », or, on en est bien loin en ce qui concerne le C. Sinon, je ne vois pas en quoi le C offre moins de liberté au programmeur que le C++.

Citation:

---

Envoyé par Taurre

Code:

---

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

struct str { char *data; size_t len; size_t max; };   struct str * str_create(void) { struct str *self;   if ((self = malloc(sizeof *self)) == NULL) { goto alloc_self_err; } if ((self->data = malloc(16)) == NULL) { goto alloc_self_data_err; } self->len = 0; self->max = 16; return self; alloc_self_data_err: free(self); alloc_self_err: return NULL; }

---

---

Heu, le fameux débat sur l'utilisation de goto, ca te dit quelque chose :question: Discussion intéressante s'il en est ;)

Mais, hors ce point qui n'est ici qu'un détail, ton code montre bien à quel point il est difficile d'éviter de faire des erreurs en C, surtout en période d'apprentissage.

Et cela confirme finalement le but général de l'article.

Pour rappel, il ne propose pas de ne pas apprendre C, il propose uniquement de ne pas l'apprendre "en prerequis à l'apprentissage de C++"

Bien sur, quelqu'un qui passe de C++ auras un gros effort de "mise à niveau" à faire pour passer à C, mais l'inverse est tout aussi vrai, et très certainement encore plus vrai au vu de l'approche historique qui consiste à envisager C comme un prérequis à l'apprentissage de C++.

Nous n'avons, comprenons nous bien, strictement rien contre le fait que quiconque apprenne le C, pour quelque raison que ce soit, sauf s'il le fait parce qu'il croit que cela lui facilitera les choses pour l'apprentissage de C++ ;)

Bonjour,

Citation:

---

Envoyé par Freem

2) la solution, c'est de considérer que le nom des variables interne n'a absolument pas à être connu. "getName()"? Mais quelle horreur! Le nom "name()" est bien meilleur, pour moi. C'est un getter dans le rôle, mais plus dans le nom. Et le setter, c'est "rename(std::string const&)", pas "setName(...)".

---

Je ne suis pas vraiment d'accord avec toi.
Oui, il vaut mieux ne pas connaitre le nom de variable interne et je ne ferais jamais un setm_name() mais je ne vois pas l'intérêt de faire name() à la place de getName() au contraire.

Déjà au niveau de l'auto-complétion dont les choix sont souvent triées par ordre alphabétique, si on ne connais pas le nom de la méthode mais qu'on sait ce qu'on souhaite faire, ça aide énormément car on saura que notre méthode commencera par "get"/"set"/"is"/"to"/"create", etc...
On a donc pas à rechercher (et se perdre) dans toute la liste des méthodes qui pour certaines classe peuvent être assez longues (cf Qt).

De plus je trouve getName() bien plus explicite que name().
getName() : "get" : je veux obtenir quelque chose. Quoi ? Un "name" => un nom.
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 ?

En conclusion, je pense que mettre "get"/"set" dans les noms de méthodes les rendent plus explicites et plus faciles à retrouver avec l'auto-complétion et 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 :aie: )

Citation:

---

Envoyé par Neckara

Bonjour,

Je ne suis pas vraiment d'accord avec toi.
Oui, il vaut mieux ne pas connaitre le nom de variable interne et je ne ferais jamais un setm_name()

---

Là dessus, nous sommes bien d'accord que ce serait une horreur ;)

Citation:

---

mais je ne vois pas l'intérêt de faire name() à la place de getName() au contraire.

Déjà au niveau de l'auto-complétion dont les choix sont souvent triées par ordre alphabétique, si on ne connais pas le nom de la méthode mais qu'on sait ce qu'on souhaite faire, ça aide énormément car on saura que notre méthode commencera par "get"/"set"/"is"/"to"/"create", etc...
On a donc pas à rechercher (et se perdre) dans toute la liste des méthodes qui pour certaines classe peuvent être assez longues (cf Qt).

De plus je trouve getName() bien plus explicite que name().

---

Je comprend ton point de vue, mais je n'y adhère décidément pas complètement.

J'éviterai de parler des méthodes qui commencent par set étant donné que c'est un débat déjà ancien et que je crois que tout le monde connait ma position concernant les mutateurs ;)

Pour ce qui est des fonctions dont les noms commencent par create, is ou to, j'aurais tendance à être tout à fait de ton avis, dans le sens où le verbe correspond bel et bien à l'identification du service que l'on attend de la part de la fonction.

Mais pour ce qui est des accesseurs (car c'est de cela que l'on parle)... là, je dois avouer que je suis plutôt de l'avis de Freem: Sans même aborder le fameux thème du "est il seulement opportun d'exposer un accesseur :question:" (je crois que tout le monde connait aussi mon point de vue sur le sujet ;)) je crois que l'utilisation de get est, à tout le moins, malheureuse.

Le fait est que le service rendu par un accesseur est de... permettre l'accès à une information, le nom en l'occurrence, selon l'exemple que tu donnes.

Je préfères donc, effectivement, avoir une fonction name que getName.

Si, vraiment, il fallait que je rajoute un verbe pour suivre une logique identique aux fonctions is, to, create, je crois que je préférerais encore e verbe "give", car c'est ce que fait un accesseur: ca donne accès (du point de vue de l'objet utilisé) alors que "get" nous place... du point de vue de la fonction appelante ;)

Citation:

---

getName() : "get" : je veux obtenir quelque chose. Quoi ? Un "name" => un nom.

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 ?

---

Tu pourrais tout aussi bien faire les deux (une version non constante, prenant un argument qui modifiera le nom et une version constante qui renvoie le nom en question, même si je préférerais sans doute que la version non constante s'appelle rename ;)), où serait le problème :question:

Citation:

---

En conclusion, je pense que mettre "get"/"set" dans les noms de méthodes les rendent plus explicites et plus faciles à retrouver avec l'auto-complétion et 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 :aie: )

---

... Mais correspondent cependant beaucoup moins au service qui est rendu :aie:

@koala01 : Merci pour ta réponse.

Je pense avoir compris : "get" veut dire obtenir, le sujet est donc la fonction appelante alors que "give" signifie donner, le sujet est donc l'objet utilisé.
Ce serait donc plus une question de grammaire que de programmation ?

Par contre, quid du fait qu'on a plus l'habitude de voir "get" que "give" ? Ie qu'un programmeur s'attend plus à trouver un "get" qu'un "give" ?
Si je remplace tous mes "get" par des "give", je pense que ça va faire bizarre/que ça va déconcerter la personne qui va me relire :aie:

Et je suppose que c'est le même débat pour "set".
Pour rename(), c'est assez courrant mais pour setFont(), setSize(), qu'est-ce qui serait le plus adapté pour remplacer "set" ? "change" (ou "modify") ?

de toute façon on peut dire ce qu'on veut, on est plus objectif vu qu'on a à peu près passé l'étape de débutant.

Seul un débutant C++ pourrait faire remonter les erreurs qu'il rencontre. Idem C.

Je suis pas convaincu par les pointeurs. La gestion mémoire - est - importante et permet de construire des bases solides. Le bémol, c'est qu'on met plus de temps pour avoir des résultats concrets.

Je suis pas convaincu par la dangerosité (?) du langage. Le débutant que ca le saoule le const, il va caster ou n'importe quoi d'autre. Si le débutant choisit son langage car il peut ignorer les warnings, ..., c'est pas la faute du langage. Et de toute façon si son programme plante. Où est le problème!

Je suis pas convaincu par l'OO dès l'apprentissage. La première chose que tu fais quand tu commences, c'est du concret. Afficher ci, faire telle fonction, regrouper des fonctions dans un fichier...

En revanche: les points n'ont pas été cités mais :
- la doc C++ est plus jolie (C c'est souvent des vielles pages blanches/ecriture noire en courrier new). cplusplus par exemple. La communauté est plus grande : Et c'est TRES important, bien plus que la complexité du langage.
- la STL (on y arrive vite même sans comprendre les template/iterators): lire un fichier, afficher des int/string/char c'est appréciable.


(de manière générale, je pense que C++ est mieux pour débuter pour :
- avoir des résultats rapides : vector, cout, fstream sans se soucier de comment ca marche
- plein d'aide sur le net, ya qu'à juste copier le message de compilation!

Pour ce qui est de SOLID etc...
Je pense effectivement qu'une mise en pratique pendant l'apprentissage serait bien. Mais je dirais d'abord de coder sans la connaissance de ces principes pour en saisir l'intérêt!
Au final, le goto, cast, variables globales, setters, gestion mémoire de pointeurs, c'est en crisant qu'on cerne l'intérêt de ces principes. De préférence à l'école, c'est mieux :lol:

Citation:

---

Envoyé par Neckara

@koala01 : Merci pour ta réponse.

Je pense avoir compris : "get" veut dire obtenir, le sujet est donc la fonction appelante alors que "give" signifie donner, le sujet est donc l'objet utilisé.
Ce serait donc plus une question de grammaire que de programmation ?

Par contre, quid du fait qu'on a plus l'habitude de voir "get" que "give" ? Ie qu'un programmeur s'attend plus à trouver un "get" qu'un "give" ?
Si je remplace tous mes "get" par des "give", je pense que ça va faire bizarre/que ça va déconcerter la personne qui va me relire :aie:

---

On est bien d'accord sur ce fait...

Pourtant, si on applique la logique des to, is, create, il semblerait logique d'effectivement remplacer tous les get par des give (ou provide :question:) ;)

Mais le problème du get n'est pas forcément la manière dont on nomme la fonction, tant que l'utilisateur comprend ce que fait la fonction, le problème est, surtout, de savoir s'il est opportun de donner un accès (fusse en lecture seule) à une donnée membre de la classe ;)

Mais ca, c'est un autre débat ;)

Citation:

---

Et je suppose que c'est le même débat pour "set".
Pour rename(), c'est assez courrant mais pour setFont(), setSize(), qu'est-ce qui serait le plus adapté pour remplacer "set" ? "change" (ou "modify") ?

---

Ben, combien de fois vas tu modifier l'intégralité de la police de caractères :question:

Généralement, tu vas plutôt soit changer la police, mais ni la taille ni les différents attributs (bold, italic, et autres), soit changer la taille, mais pas les autres attributs ni la police en elle-même, soit changer les attribut, mais ni la taille ni la police.

Je verrais donc d'un très bon oeil le fait d'avoir autant de fonctions qui correspondent à autant de service réellement attendus.

Maintenant, que tu les appelles addBold / removeBold ou modifyBold m'indiffère plus ou moins, tant que cela correspond à un service clairement défini ;)

Comme il se doit, commençons donc par une quote de koala :D. Ah, on me souffle dans l'oreillette que si je ne répond à Taure qu'à la fin, il y a de grandes chances qu'il rate ma réponse, je vais donc commencer par cela :aie: :

Citation:

---

Envoyé par Taurre

Si je m'en tient à l'acception courante, « obsolète » signifie « Qui n'est plus en usage; tombé en désuétude », or, on en est bien loin en ce qui concerne le C. Sinon, je ne vois pas en quoi le C offre moins de liberté au programmeur que le C++.

---

Pour moi il a le sens de "dépassé", "remplacé avantageusement par autre chose" ou "le besoin auquel il répond a disparu" (ce dernier n'est pas valable en ce qui concerne le C).

Pour la liberté offerte, vois-le dans l'autre sens, ce n'est pas le C qui en a moins, c'est le C++ qui en a plus. Pour comparer la liberté, je compare les possibilités offertes pour réaliser la même chose (ainsi comparer la liberté offerte par le C et par Java n'aurait aucun sens selon moi).

De ce que j'en pense, le C++11 est un langage haut-niveau. Mais il a une précision aussi fine que le C. Je pense donc que la qualification d'un langage en niveau devrait donc être revue. Premièrement il est déjà une bonne chose de rendre ce niveau relatif : on est haut-niveau par rapport à tel autre langage, pas en absolu. Deuxièmement, je pense qu'il serait utile de ne pas se limiter à un résultat quantique (haut/bas). Il serait plus approprié de parler plage de niveau. Ainsi le C++11 inclue la plage du C par le bas, et s'étend loin au dessus jusqu'à rattraper (voire dépasser, mais ce n'est que mon avis personnel et ce n'est pas le sujet du débat) par le haut la plage du Java.

Citation:

---

Envoyé par gbdivers

Tête de mule. Bon, tant que tu critiques pas Qt, je te pardonne...

---

Je vais pas tomber dans ce piège si grossier :P

Reprenons donc Koala :D :

Citation:

---

Envoyé par koala01

Encore une fois, n'hésites pas à me présenter un ou des principes qui puissent être suivi "selon l'envie" ou de "manière assouplie" en apportant le même degré de certitude, et je serai le premier à changer mon fusil d'épaule.

---

Il n'y a que deux principes dont je connaisse le nom actuellement que j'ai identifié dans mon code. Ce sont deux principes auxquels j'adhère totalement et qui pour l'instant ne m'ont pas encore déçu. Le premier apporte un degré de certitude très élevé, aussi je juge bon d'en faire grande mention ^^.

Le premier, c'est le RAII (attention, je l'applique également littéralement contrairement à ce que je vois dans les codes qui passent sur le forum). Je suis assez rigide dessus (c'est plutôt les méthodes que j'emploie qui sont libres). C'est une des choses qui me manque d'ailleurs le plus en C.

Le deuxième c'est le DNRY. Mais il ne doit jamais ni m'empêcher de suivre le RAII, ni me faire faire des détours que je juge inutiles.

Ah, et un dernier, qui m'est cher mais passe après les deux précédents : le code explicite. Il ne compte pas dans les principes dont je connais le nom malheureusement ^^. J'essaie de me débrouiller pour que mon code se passe de commentaire. Cela ne comprend pas uniquement le nommage explicite. Le RAII contribue fortement à améliorer ceci dans son application littérale.

Voilà, c'est l'heure d'aller manger, je vous laisse peut-être sur votre faim, mais je vais rassasier la mienne :D !

Citation:

---

Envoyé par koala01

Heu, le fameux débat sur l'utilisation de goto, ca te dit quelque chose :question: Discussion intéressante s'il en est ;)

---

Bien entendu, je sais que l'utilisation de goto hérisse les poils de plusieurs programmeurs convaincus par les bienfaits de la programmation structurée et de ses mille et une imbrications. Pour moi, c'est juste ignoré l'efficacité de cette instruction pour la gestion d'erreur sous prétexte du respect d'un principe soit disant bénéfique. Mais bon, ce n'est qu'une question de point de vue et cela ne remet pas en cause l'efficacité de la technique que j'expose.

Citation:

---

Mais, hors ce point qui n'est ici qu'un détail, ton code montre bien à quel point il est difficile d'éviter de faire des erreurs en C, surtout en période d'apprentissage.

---

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 ?

Citation:

---

Envoyé par koala01

Et cela confirme finalement le but général de l'article.
Pour rappel, il ne propose pas de ne pas apprendre C, il propose uniquement de ne pas l'apprendre "en prerequis à l'apprentissage de C++"

---

C'est ce que j'ai compris en lisant ce sujet, mais pas en lisant l'article. Au final, vous démontrez juste qu'un type qui ne lis pas les avertissements du compilateur aura du mal à trouver l'origine de ses erreurs (ce qui me parait assez évident) et vous rappelez le principe du RAII en C++. Bref, je ne vois absolument pas le rapport avec la non nécessité d'apprendre le C avant le C++ (que je ne remets pas en cause).

Citation:

---

Envoyé par germinolegrand

Il n'y a que deux principes dont je connaisse le nom actuellement que j'ai identifié dans mon code. Ce sont deux principes auxquels j'adhère totalement et qui pour l'instant ne m'ont pas encore déçu. Le premier apporte un degré de certitude très élevé, aussi je juge bon d'en faire grande mention ^^.

Le premier, c'est le RAII (attention, je l'applique également littéralement contrairement à ce que je vois dans les codes qui passent sur le forum). Je suis assez rigide dessus (c'est plutôt les méthodes que j'emploie qui sont libres). C'est une des choses qui me manque d'ailleurs le plus en C.

Le deuxième c'est le DNRY. Mais il ne doit jamais ni m'empêcher de suivre le RAII, ni me faire faire des détours que je juge inutiles.

Ah, et un dernier, qui m'est cher mais passe après les deux précédents : le code explicite. Il ne compte pas dans les principes dont je connais le nom malheureusement ^^. J'essaie de me débrouiller pour que mon code se passe de commentaire. Cela ne comprend pas uniquement le nommage explicite. Le RAII contribue fortement à améliorer ceci dans son application littérale.

---

Et tu as bien raison de faire grande mention de ces deux principes, même si RAII est mal nommé ;)

Cependant, DRY est, surtout, une interjection qui se base en réalité sur SRP et ces trois principes, s'il permettent effectivement d'éviter pas mal de problèmes, en laissent malheureusement passer d'autres, qui pourraient être évités dés la phase de conception ;)

Désolé, je n'ai pas vu la réponse avant de publier la mienne :

Citation:

---

Envoyé par germinolegrand

Pour moi il a le sens de "dépassé", "remplacé avantageusement par autre chose" ou "le besoin auquel il répond a disparu" (ce dernier n'est pas valable en ce qui concerne le C).

---

Je ne suis pas de cet avis, je ne vois actuellement aucun langage qui « remplace avantageusement le C », dans ses domaines de prédilections (notamment la programmation système et l'embarqué).

Citation:

---

Envoyé par germinolegrand

Pour la liberté offerte, vois-le dans l'autre sens, ce n'est pas le C qui en a moins, c'est le C++ qui en a plus. Pour comparer la liberté, je compare les possibilités offertes pour réaliser la même chose (ainsi comparer la liberté offerte par le C et par Java n'aurait aucun sens selon moi).

---

À mes yeux, la liberté offerte par un langage c'est ce qu'il te permet de faire, peut importe de quelle manière. En règle générale, plus un langage est de haut niveau (je considère le C et le C++ comme des langages de bas niveau) plus il enferme le programmeur dans un carcant et moins sa liberté est grande. Aussi, pour moi, le C et le C++ offre le même niveau de liberté.

En revanche, le C++ offre effectivement plus d'outils, c'est incontestable.

Citation:

---

Envoyé par Taurre

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 ?

---

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

En fait, tu dois déjà avoir pas mal de connaissance:

1. ce qu'est un pointeur
2. ce qu'est la différence entre la pile et le tas
3. ce que fait la fonction malloc
4. ce que fait le mot clé goto
5. ce que fait la fonction free
6. les risques que tu prend en cas de dépassement de mémoire

Pour tout développeur C un tout petit peu habitué, cela n'a l'air de rien, mais cela implique, pour le type qui veut apprendre C, qu'il doit s'intéresser à une série de concepts très importants (en C du moins) pour arriver à le comprendre.

Ceci étant posé (et je présume que tu ne me contrediras sur ce point ;)), posons nous une deuxième question: quand faudra-t-il que celui qui apprend C s'intéresse au point précédent :question:

La réponse a presque de quoi choquer, car, en gros, c'est "dés que l'étudiant voudra écrire une nouvelle fonction", et, si on reprend purement le code que tu donnes en exemple, c'est encore pire, car la réponse devient "dés qu'il voudra gérer une chaine de caractères ton il ignore a priori la taille".

Autrement dit: très tôt dans l'apprentissage, car il aura à peine eu le temps d'apprendre ce qu'est une boucle et un test

Si l'on trace la boucle d'apprentissage, tu as donc (ce n'est qu'un résumé de ce que j'ai écrit quelques intervention plus haut ;))

• apprendre à écrire la fonction main: ca prend cinq minutes
• apprendre à écrire une boucle: allez, ca prend un quart d'heure pour voir les trois types de boucles
• apprendre à écrire un test: dix minutes pour avoir les tests simple et les tests de type switch case :question:

Jusque là, il n'y a pas grand chose de compliqué, je crois que tu seras du même avis que moi ;)

Puis d'un seul coup, tu va lui dire "oui, mais, attention, il faut gérer les ressources", et tu vas, littéralement, devoir l'assommer avec les notions que j'ai citées au début de mon intervention, c'est à dire avec des notions réellement complexes et particulièrement importantes.

Et après, tu vas reprendre avec des notions comme les structures dynamiques (pile, file et autres) "simples", à condition d'avoir assimilé les notions complexes, "casse gu...le" si, par malheur, il ne les a pas assimilées.

Regardons maintenant la courbe d'apprentissage de C++...

1. on apprend à écrire la fonction main : cinq minutes (elle ne change pas de C, finalement ;))
2. on apprend les différentes boucles : un petit quart d'heure, (idem)
3. on apprend les différentes sortes de test: c'est toujours 10 minutes
4. On a besoin d'une chaine de caratère :question: on introduit std ::string, et il faut même pas commencer à s'inquiéter des fonctions membres
5. Il est plus que temps de pouvoir utiliser des collections!! on introduit celles de la STL ("vous inquiétez pas de push_back, utilisez le, on en parle plus tard ;))
6. Il faut commencer à convertir des données de différents types :question: on introduit stringstream (vous inquiétez pas de str(), ca viendra en meme temps que push_back ;))
7. Le passage d'argument commence vraiment à faire lourd: on introduit les références (c'est un alias de la variable que vous passez en argument, très compliqué, n'est-ce pas :question:)
8. et on pourrait continuer comme cela ;)

Il y a parfaitement moyen de voir en C++ l'ensemble du paradigme impératif sans avoir à s'inquiéter de la gestion des ressources (et la gestion de la mémoire est sans doute la pire bête noir des débutants ;))

Bien sur, on a "laisser quelques trucs de coté", mais, ou est le problème :question:

Le fait que l'étudiant n'ait pas forcément conscience de ce que fait push_back au niveau de la mémoire est il handicapant :question:

Sommes toutes, beaucoup moins qu'on ne pourrait le croire ;)

En plus, on a une transition toute trouvée pour aborder le paradigme OO: "Ah, au fait, il est temps de nous intéresser à push_back et à str... Ce sont des fonctions membres".

Hé oui, C++ est un langage qui utilise le paradigme Orienté Objet: C'est un paradigme qui s'intéresse plus aux services qu'un objet peut rendre qu'aux données qui lui permettent de rendre ce service.

De fil en aiguille, on arrive au besoin d'héritage, bien sur...

Et ce n'est qu'à ce moment là qu'il devient intéressant de parler de pointeur et de tout ce qui s'y rapporte.

Mais les problèmes de syntaxe sont déjà assimilés depuis longtemps, et l'on a meme sans doute eu déjà largement l'occasion de s'habituer à un grand nombre d'erreurs lancées par le compilateur ;)

Il est alors peut etre temps de revenir un peu plus en détail sur des fonctions comme push_back pour leur faire se rendre compte de l'impact d'une telle fonction en mémoire ;)

ET s'il reste encore un peu de temps à l'horaire, on peut envisager d'aborder le paradigme générique ;)

Au final, la courbe d'apprentissage est beaucoup plus souple et régulière que ce que l'on aurait eu en C ;)

Pour moi le SRP quand il apparaît n'est qu'une constatation que je fais quand je relis mon code, et je ne le respecte pas nécessairement (bien qu'au final mon code le respectera très certainement dans sa majeure partie). D'ailleurs, dans mes premières étapes de développement c'est bien un des principes que je respecte le moins ^^.

Tu auras peut-être noté le "littéralement" dans mon dernier message. C'est parce que je considère que le RAII n'est pas aussi mal nommé que tous ceux qui en font mention semblent le dire.

Le contrôle de la durée de vie de mes objets est une de mes plus grandes préoccupations. D'ailleurs cette expression serait plus appropriée pour décrire mon approche au RAII. OLTC : Objets LifeTime Control. Pourquoi ? Parce que je me préoccupe autant du moment où mes objets sont créés que du moment ou ils sont détruits, et met un point d'honneur à les initialiser à leur construction.

Ceci signifie notamment que les méthodes init(), start() et autres, sont absolument ignobles à mes yeux. Cela exclue également un paramétrage post-construction (et par là-même me dispense donc de setters) dans un très grand nombre de cas.

On me pose souvent la question quand je montre un code, on me demande pourquoi j'ai mis plusieurs paires d'accolades à l'intérieur d'une fonction. C'est parce que c'est un élément essentiel qui me permet de contrôler l'ordre de construction et de destruction de mes objets, ainsi que la mémoire avec un degré de précision et de certitude bien plus supérieure, sans pour autant devoir créer une fonction supplémentaire qui prendrait plus de paramètres qu'elle ne serait appelée. Ceci diminue également drastiquement la mémoire utilisée sur la pile.

L'une des seules raisons en dehors du DNRY (j'insiste sur le 'N', sans cela ça veut dire strictement le contraire :aie:) qui me pousse à écrire disons un helper privé (je ne sais pas s'il existe un terme approprié pour décrire ça), c'est lorsque j'ai besoin du return (surtout dans une fonction qui retourne void, cela m'arrive très fréquemment). Ça aussi ça fait partie des choses qui étonnent ceux qui lisent mon code. Pourtant c'est également un outils de contrôle très important qui évite moultes complexifications du code. Et seul l'OLTC me garantie que marquer return; au milieu de ma fonction est efficace et surtout sans bug aucun.

C'est également la raison pour laquelle je critique abondamment la syntaxe des flux en C++ puisqu'on est obligé de construire des objets sans pouvoir les initialiser. J'aimerais beaucoup travailler à un proposal pour améliorer ça car sans ce problème les flux seraient d'une qualité et d'un intérêt sans pareil.

C'est de ce côté là aussi que le RAII m'apporte beaucoup de robustesse (et m'évite énormément de segfaults c'est bien évident). Au final, le RAII (au sens où on l'entend généralement) n'est qu'une composante de ce principe d'OLTC.

Je n'ai pas évoqué les exceptions, mais elles font entièrement partie de ce concept et de l'utilisation que j'en ai, c'est évident.

Bonjour.

Pour apprendre le C++, vaut-il mieux avoir appris le C ?

Je suis d'accord pour dire que non. En effet le C est impératif et le C++ est objet, deux philosophies de développement complètement différentes.

Passer du C au C++ est très délicat parce que plus rien n'est linéaire, tout est dispatché dans les classes. Le développeur C se sent perdu, c'est trop abstrait.

Passer du C++ au C est tout aussi délicat, plus rien n'est en encapsulé, on a l'impression de ne pas pouvoir maîtriser correctement le code, la gestion des chaînes de caractères est un calvaire. Le développeur C++ se sent frustré.

Par contre, je pense que l'apprentissage de la programmation doit commencer par un langage comme le C ou un langage apparenté qui demande de la rigueur et la compréhension des pointeurs. Certe rigueur/compréhension sera très utile lorsque l'on développera avec des langages objets (C++, C# ou Java).

Citation:

---

Envoyé par moldavi

Par contre, je pense que l'apprentissage de la programmation doit commencer par un langage comme le C ou un langage apparenté qui demande de la rigueur et la compréhension des pointeurs. Certe rigueur/compréhension sera très utile lorsque l'on développera avec des langages objets (C++, C# ou Java).

---

Je ne suis pas du tout d'accord avec toi...

Apprends le C si tu veux développer en C, apprends C++ si tu veux développer en C++.

Par contre, le fait d'apprendre C++ avant java ou C# pourra effectivement t'apporter une rigueur plus importante que le fait d'apprendre C# ou java en premier (mais te fera peut etre détester ces langages :aie:)

[EDIT] quant au début de ton intervention, je te conseillerais de relire les miennes: limiter C++ à son aspect OO est par trop restrictif ;)

Citation:

---

Envoyé par koala01

Apprends le C si tu veux développer en C, apprends C++ si tu veux développer en C++.

---

On est d'accord mais le stagiaire demande a être guidé. Dans quel/quels langages va-t-il travailler plus tard ?

Citation:

---

Envoyé par koala01

limiter C++ à son aspect OO est par trop restrictif ;)

---

Quels sont les autres aspects ?

Citation:

---

Envoyé par germinolegrand

Pour moi le SRP quand il apparaît n'est qu'une constatation que je fais quand je relis mon code, et je ne le respecte pas nécessairement (bien qu'au final mon code le respectera très certainement dans sa majeure partie). D'ailleurs, dans mes premières étapes de développement c'est bien un des principes que je respecte le moins ^^.

---

Et pourtant, c'est sans doute le concept qu'il est le plus facile de respecter dés le début, et qui risque de poser le plus de problème pour arriver à le respecter lors d'évolutions.

Mais nous avons déjà abordé ce sujet ensemble, et c'est encore un autre débat ;)

Citation:

---

Tu auras peut-être noté le "littéralement" dans mon dernier message. C'est parce que je considère que le RAII n'est pas aussi mal nommé que tous ceux qui en font mention semblent le dire.

Le contrôle de la durée de vie de mes objets est une de mes plus grandes préoccupations. D'ailleurs cette expression serait plus appropriée pour décrire mon approche au RAII. OLTC : Objets LifeTime Control. Pourquoi ? Parce que je me préoccupe autant du moment où mes objets sont créés que du moment ou ils sont détruits, et met un point d'honneur à les initialiser à leur construction.

---

Et tu as tout à fait raison de le faire.

Cependant, il y a beaucoup plus de risque à mal libérer des ressources qu'il n'y en a à mal les initialiser.

Or, il existe un terme pour parler de l'initialisation et aucun terme pour parler de la libération des ressources, ce qui est franchement dommage, non :question:

Ceci dit, le fait de rapprocher OLTC du RAII est à mon sens une chose des plus saines ;)

Citation:

---

Ceci signifie notamment que les méthodes init(), start() et autres, sont absolument ignobles à mes yeux. Cela exclue également un paramétrage post-construction (et par là-même me dispense donc de setters) dans un très grand nombre de cas.

---

La dessus, nous sommes tout à fait d'accord, et depuis longtemps me semble-t-il ;)

Disposer de services qui ont pour résultat la modification de l'objet est sans doute normal, mais tu connais mon point de vue en ce qui concerne les mutateurs ;)

Mais bon, c'est, encore, un autre débat ;)

Citation:

---

On me pose souvent la question quand je montre un code, on me demande pourquoi j'ai mis plusieurs paires d'accolades à l'intérieur d'une fonction. C'est parce que c'est un élément essentiel qui me permet de contrôler l'ordre de construction et de destruction de mes objets, ainsi que la mémoire avec un degré de précision et de certitude bien plus supérieure, sans pour autant devoir créer une fonction supplémentaire qui prendrait plus de paramètres qu'elle ne serait appelée. Ceci diminue également drastiquement la mémoire utilisée sur la pile.

---

Je ne te poserais pas la question, car je le fais moi-même...

Mais, ceci dit, quitte à avoir une paire d'accolades, j'aime autant qu'elle entoure une fonction particulière ;)

Citation:

---

L'une des seules raisons en dehors du DNRY (j'insiste sur le 'N', sans cela ça veut dire strictement le contraire :aie:) qui me pousse à écrire disons un helper privé (je ne sais pas s'il existe un terme approprié pour décrire ça), c'est lorsque j'ai besoin du return (surtout dans une fonction qui retourne void, cela m'arrive très fréquemment). Ça aussi ça fait partie des choses qui étonnent ceux qui lisent mon code. Pourtant c'est également un outils de contrôle très important qui évite moultes complexifications du code. Et seul l'OLTC me garantie que marquer return; au milieu de ma fonction est efficace et surtout sans bug aucun.

---

Je ne peux qu'approuver, bien sur...

Cependant, quelle différence fais-tu par rapport à SRP :question:

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

Citation:

---

C'est également la raison pour laquelle je critique abondamment la syntaxe des flux en C++ puisqu'on est obligé de construire des objets sans pouvoir les initialiser. J'aimerais beaucoup travailler à un proposal pour améliorer ça car sans ce problème les flux seraient d'une qualité et d'un intérêt sans pareil.

---

Heu, de quels flux parles tu :question:

Pour autant que je sache, tous les flux peuvent être initialisé directement (par contre, aucun n'est copiable, et c'est logique) ;)

Citation:

---

Envoyé par moldavi

Quels sont les autres aspects ?

---

impératif, générique, oo, fonctionnel (de ce que j'ai pu comprendre de ce qu'en dit Flob90), ...

Citation:

---

Envoyé par moldavi

Le stagiaire demande a être guidé. Dans quel/quels langages va-t-il travailler plus tard ?

---

Bon, je reformule:

Citation:

---

Apprend C si tu veux, si tu as besoin de connaitre C, apprend C++ si tu veux, si tu as besoin de connaitre C++

---

Et, ceci dit, le stagiaire, il travaillera de toutes façons avec le langage qu'il préfère, ou celui que lui imposera son patron: faut bien rapporter la bidoche à la maison ;)

Citation:

---

Quels sont les autres aspects ?

---

Tu m'obliges à me répéter sans doute pour la troisième fois sur cette discussion...

C++ est l'un des rares langage multi paradigme que je connaisse.

Il présente aussi bien le paradigme purement impératif ("orienté fonctions") que le paradigme orienté objets, mais il ne faut pas non plus oublier le paradigme générique, qui apporte son lot de possibilités.

Il est, comme je l'ai déjà répété plusieurs fois sur cette discussion, tout à fait possible de se limiter à l'utilisation d'un seul paradigme, même si tout le monde sera d'accord sur le fait que c'est la parfaite intégration des trois qui rend C++ si puissant ;)

Citation:

---

Envoyé par germinolegrand

impératif, générique, oo, fonctionnel (de ce que j'ai pu comprendre de ce qu'en dit Flob90), ...

---

Au début de mon intervention, je dis que le langage C++ est objet. Ce qui est vrai.

Selon toi j'aurais dû dire le langage C++ est impératif, générique, oo, fonctionnel...

Tu comprends, je l'espère, que je fais de l'économie avec mon clavier, pas parce que je ne connais pas l'aspect multiparagdime du C++.

Citation:

---

Envoyé par moldavi

Au début de mon intervention, je dis que le langage C++ est objet. Ce qui est vrai.

---

En effet, c'est vrai...

Mais c'est particulièrement réducteur car cela passe sous silence d'autres aspects, qui rendent la suite de ton raisonnement pour le moins branlant ;)

Quand on pense que vingt minutes avant ta première intervention j'en postais une dans laquelle je précise explicitement qu'il est tout à fait possible d'"oublier" que C++ propose le paradigme objet pendant toute une partie de l'apprentissage et que tu viens nous dire (et je ne fais que te citer)

Citation:

---

En effet le C est impératif et le C++ est objet, deux philosophies de développement complètement différentes.

Passer du C au C++ est très délicat parce que plus rien n'est linéaire, tout est dispatché dans les classes. Le développeur C se sent perdu, c'est trop abstrait.

Passer du C++ au C est tout aussi délicat, plus rien n'est en encapsulé, on a l'impression de ne pas pouvoir maîtriser correctement le code, la gestion des chaînes de caractères est un calvaire. Le développeur C++ se sent frustré.

---

on ne peut que revenir avec un grand "attention, malheureux, tu es trop réducteur dans ce que tu viens de dire" ;)

Je ne fais que répondre à ta question : "Quels autres aspects ?" :aie:

@Koala: je te rédige une réponse après ;)

Citation:

---

Envoyé par koala01

et que tu viens nous dire (et je ne fais que te citer)on ne peut que revenir avec un grand "attention, malheureux, tu es trop réducteur dans ce que tu viens de dire" ;)

---

Certe je ne développe pas le fond de ma pensée (c'est un forum pas un lieu de thèse). Pose-moi plutôt des questions sur ce pourquoi je pense comme cela, plutôt que de travestir ce que j'écris.

Citation:

---

Envoyé par moldavi

Certe je ne développe pas le fond de ma pensée (c'est un forum pas un lieu de thèse). Pose-moi plutôt des questions sur ce pourquoi je pense comme cela, plutôt que de travestir ce que j'écris.

---

Ooh là...

Je n'ai absolument rien travesti de ce que tu as écrit, et j'ai réagis on ne peut plus clairement par rapport à tes écrits.

En plus, tu as demandé à ce que je précise ce que j'entendais par "trop restrictif" et je me suis fendu d'une réponse claire et précise.

Si tu estimes que "j'ai travesti" tes écrits, n'hésites pas à me présenter tes arguments, peut etre ai-je effectivement mal compris ce que tu voulais dire.

En attendant, toutes mes interventions dans cette discussion ont chaque fois veillé à être claire et motivées et, quand ce n'était pas le cas, je n'ai jamais refusé d'approfondir le moindre aspect.

Si donc tu estimes que je n'ai pas compris le sens de ton intervention, ce n'est pas à moi de te demander de l'exprimer plus clairement, c'est à toi de vouloir le faire. N'inversons pas les rôles, veux tu bien :question:

Disons qu'il y a du pour et du contre.

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.

C'est intéressant de faire une cassure entre C = procédural et C++ = objet et autres.
Car c'est l'utilisation qui en est faite le plus souvent.

Sinon, les mecs, par conforts, peuvent programmer en procédural sur du C++, java ou autre. Et se faire rattraper par leurs lacunes.

Citation:

---

Envoyé par LSMetag

Disons qu'il y a du pour et du contre.

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.

---

Ca se discute...

Je ne crois pas que l'utilisation de fonctions libres soit réellement une mauvaise habitude en C++

Finalement, une fonction membre reste quand même une fonction, d'abord et avant tout ;)

Et le fait de passer d'une fonction libre à une fonction membre s'inscrit dans le cadre du "intéressons nous aux comportement que l'on attend de la part de notre objet" ;)

Citation:

---

C'est intéressant de faire une cassure entre C = procédural et C++ = objet et autres.
Car c'est l'utilisation qui en est faite le plus souvent.

---

On privilégie effectivement souvent l'approche OO en C++, mais c'est oublier un peu vite que l'on travaille avec énormément de fonctions libres (essentiellement les fonction "operator")... sans compter une bonne dose de paradigme générique ;)

Citation:

---

Sinon, les mecs, par conforts, peuvent programmer en procédural sur du C++, java ou autre. Et se faire rattraper par leurs lacunes.

---

Surement pas en java, car le seul moyen de faire du pseudo procédural en java serait de passer par des fonction statiques :aie:

Quant au fait de programmer en procédural sur du C++ et de se faire rattraper par ses lacunes, j'aimerais que tu détailles un tout petit peu ce que tu entends par là.

Les gens pourraient, effectivement, avoir des lacunes du coté de l'aspect OO, mais elles ne se feront sentir qu'au moment où ils voudront effectivement utiliser ce paradigme (et recourir, par exemple, à l'héritage).

Et c'est bien pour cela que j'insiste sur le fait que l'apprentissage des tous les paradigmes est important

Mais j'insiste aussi sur le fait qu'il est beaucoup plus cohérent de s'attaquer à chaque paradigme "séparément" et de manière graduelle (comment comprendre la substituabilité si on n'a déjà pas compris la notion de fonction :question:)

@koala01

Justement, il y a plusieurs choses que je veux dire par là :

Il y aurait un mélange des paradigmes assez pourri. En faisant du procédural, le programmeur ne s'apercevrait pas qu'il fait également de l'objet.
Donc, après dur dur de revoir ses acquis dès qu'il fait de l'objet où tout se mélangerait.

J'ai commencé le Java en "pseudo procédural" et ça a duré plusieurs mois.
Si je n'avais pas fait de C++ avant je ne sais pas comment j'aurais réagi.
Mais je suis presque sûr que "static" aurait été un mot clé que j'aurais mis sans comprendre pourquoi, n'ayant aucune notion d'objet. J'aurais mis "static" devant tout et dans le même fichier et puis basta.

Et oui, comme je l'ai dit, le mec aurait beau apprendre l'objet en C++, il n'y aurait pas de cassure au niveau du langage, et il est tout à fait possible que par confort, il continue à utiliser le langage de façon procédurale, sauf si il est obligé. Et il pourraît s'imaginer ensuite qu'on peut faire pareil avec Java, C#,... Bref de mauvaises habitudes. "L'objet c'est un cap, et en gros ce qu'on faisait avant ce n'était qu'une intro". C'est comme ça que je résumerais.

Je vais donc répondre à Koala (en omettant la partie sur les flux qui est un tout autre sujet), dans l'ordre pour une fois :D :

Citation:

---

Cependant, il y a beaucoup plus de risque à mal libérer des ressources qu'il n'y en a à mal les initialiser.

---

Le mal insidieux se cache dans les petits recoins. En effet, une fois qu'on sait se servir d'un destructeur et de pointeurs intelligents, la question de la destruction est somme toute assez vite réglée (ahem :mrgreen:).

Les constructions croisées sont un mal extrêmement ardu à combattre proprement.

Citation:

---

Or, il existe un terme pour parler de l'initialisation et aucun terme pour parler de la libération des ressources, ce qui est franchement dommage, non

---

allocation => initialisation/construction (c'est exactement et strictement pareil)
destruction => désallocation

C'est donc oublier bien vite la différence entre malloc/free et new/delete ^^.
Vouloir faire une fonction init() c'est donc utiliser un new alors qu'il n'aura que la valeur sémantique d'un malloc. Là bizarrement tout le monde commence à être d'accord que init() c'est le mal :mouarf: .

Citation:

---

Mais, ceci dit, quitte à avoir une paire d'accolades, j'aime autant qu'elle entoure une fonction particulière

---

La différence est là en effet ^^.

Citation:

---

Cependant, quelle différence fais-tu par rapport à SRP ?

---

Je crée ce genre de helper pour des raisons techniques, et non conceptuelles.

C'est peut-être là la clé de bon nombre de mes propos, puisque je fais du DNRY pour une raison technique (ie. c'est ch***t de faire du copier-coller et de le maintenir) et non conceptuelle.

Le SRP découle tout seul du DNRY, ce n'est qu'une conséquence des concepts que j'applique.

Citation:

---

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

---

La différence n'est pas le résultat, mais les motivations. C'est bien pour cela que je dis que mon code ne suis pas ces principes, mais que ça n'empêche pas qu'ils soient vérifiés.

Mais on n'a pas parlé de SOLID au complet :
SRP : comme on l'a vu, oui par conséquence ;
OCP : même chose que SRP ;
LSP : là encore c'est la même chose que le SRP, bien que je me fiche pas mal des pre/post conditions... ;
ISP : celui-là je peux te dire qu'il va très souvent aux oubliettes de façon explicite :mrgreen: , ça n'empêche pas qu'il soit parfois vérifié ;
DIP : conséquence possible du DNRY :-°.

Pour l'ISP, je ne sais pas si ça rentre dans ce cadre, mais je suis très attaché au const-correctness, peut-être est-ce une application particulière de ce principe ?

Au final je m’aperçois que je dois ajouter le const-correctness dans ma liste car je n'y déroge jamais ^^.

Citation:

---

Envoyé par LSMetag

@koala01

Justement, il y a plusieurs choses que je veux dire par là :

Il y aurait un mélange des paradigmes assez pourri. En faisant du procédural, le programmeur ne s'apercevrait pas qu'il fait également de l'objet.

---

Je crois comprendre ton point de vue, mais j'ai quand même beaucoup de mal à y souscrire...

Comprend que, même si on ne s'intéresse qu'à l'aspect procédural de C++, il faut quand même être bouché à l'émeri pour ne pas se rendre compte que l'on utilise parfois des fonctions apportées par les objets qu'on manipule (cf l'exemple de push_back que j'ai utilisé dans mes différentes intervention à ce sujet ;))

Il y a donc une nette différence entre les fonctions libres et les fonctions membres, et on s'en rend d'office compte en C++ ;)

Citation:

---

Donc, après dur dur de revoir ses acquis dès qu'il fait de l'objet où tout se mélangerait.

---

Ici, on parle du temps nécessaire à assimiler les bases du langage et les principes "simples"...

Je ne crois pas que cela se compte en plus de trois mois à quelques heures par semaine ;)

Citation:

---

J'ai commencé le Java en "pseudo procédural" et ça a duré plusieurs mois.
Si je n'avais pas fait de C++ avant je ne sais pas comment j'aurais réagi.
Mais je suis presque sûr que "static" aurait été un mot clé que j'aurais mis sans comprendre pourquoi, n'ayant aucune notion d'objet. J'aurais mis "static" devant tout et dans le même fichier et puis basta.

---

En java, le problème se poserait beaucoup plus car, effectivement, il n'y a pas moyen de créer des fonctions libres.

Comme nous sommes bien d'accord sur le fait que le seul moyen de faire du pseudo procédural en java serait de passer par des fonctions statiques, nous serons sans doute aussi d'accord sur le fait que l'utilisation de ces fonctions passera systématiquement par un code proche de

Code:

---

MaClass::maFonction(lesArgument);

---

et, à partir de là, je serai tout à fait d'accord avec toi sur le fait qu'il devient pour le moins difficile de faire la part entre le procédural et l'objet, vu que, de toutes manières, l'appel de fonctions "soi disant libres" passe par l'utilisation d'un objet ;)

Mais, comme je l'ai indiqué plus haut, ce problème n'apparait pas (ou en tout cas, beaucoup moins) en C++ simplement parce qu'il y a une différence flagrante entre une fonction libre et une fonction membre, fut-elle statique ;)

Quelque part, la signification que l'on donne au mot clé static est totalement différente en java qu'en C++:

En java, cela peut (bien que ce ne soit pas le cas) être plus ou moins considéré comme une fonction libre, alors qu'en C++, c'est clairement une fonction qui "dépend d'un type particulier, même si elle ne dépend d'aucune instance de ce type" (bon, d'accord, je prend de très forte libertés en ce qui concerne java, mais c'est le genre d'amalgame qu'un étudiant pourrait etre tenté de faire ;))

Citation:

---

Et oui, comme je l'ai dit, le mec aurait beau apprendre l'objet en C++, il n'y aurait pas de cassure au niveau du langage, et il est tout à fait possible que par confort, il continue à utiliser le langage de façon procédurale, sauf si il est obligé. Et il pourraît s'imaginer ensuite qu'on peut faire pareil avec Java, C#,... Bref de mauvaises habitudes.

---

Je crois que je viens de répondre, je vais juste dire: avec des langages comme java, je t'accorde bien volontiers ce point, mais avec C++, je ne crois pas que ce soit un problème réel, du fait de la possibilité de faire du vrai impératif, et non seulement du "pseudo impératif" basé sur des fonctions membres statiques ;)

Citation:

---

"L'objet c'est un cap, et en gros ce qu'on faisait avant ce n'était qu'une intro". C'est comme ça que je résumerais.

---

Tout à fait, et on peut parfaitement le faire avec C++: si on commence par une approche purement impérative du langage, l'introduction nous permet d'apprendre toute la syntaxe et de déjà bien nous amuser ;)

Par contre, il serait à mon sens criminel de vouloir le faire avec un langage comme java car (décidément, on en revient toujours à cela) on ne ferait pas de l'impératif pur mais du "pseudo impératif, basé sur des fonctions membres statiques" ;)

Quelque part, cela va peut être sembler aberrant ce que je m'apprête à écrire, mais je verrais beaucoup plus l'apprentissage de C comme introduction à celui de java (ou de C#, ne faisons pas de jaloux ;)), histoire de donner à l'étudiant un aperçu du paradigme impératif, que comme introduction à l'apprentissage de C++ qui se "suffit à lui-même" à ce point de vue ;)

Mais, à ce moment là, peut être serait il préférable d'utiliser d'autres langages qui soient moins "perclus" de chausses trappes ;).

Enfin, ca, c'est encore un autre débat, ne vous sentez pas obligés de répondre à cette partie :D

Citation:

---

Envoyé par germinolegrand

allocation => initialisation/construction (c'est exactement et strictement pareil)
destruction => désallocation

C'est donc oublier bien vite la différence entre malloc/free et new/delete ^^.
Vouloir faire une fonction init() c'est donc utiliser un new alors qu'il n'aura que la valeur sémantique d'un malloc. Là bizarrement tout le monde commence à être d'accord que init() c'est le mal :mouarf: .

---

Oh là là, ne me fais pas dire ce que je n'ai pas dit...

J'ai juste regretté que RAII ne s'intéresse qu'à une seule partie du problème: celle de l'initialisation / acquisition des ressources et oublie (ou du moins ne fasse aucune mention) du phénomène qui consiste à les libérer en temps utiles.

Tu as parlé de OLTC (acronyme que tu m'as appris à l'occasion, ce dont je te remercie ;)), et je trouve qu'il est à ce titre presque meilleur que RAII, car il parle de la "durée de vie", ce qui sous entend "de la construction à la destruction".

A la limite, je regrettais surtout de ne pas connaitre cet acronyme :D

Citation:

---

La différence est là en effet ^^.



Je crée ce genre de helper pour des raisons techniques, et non conceptuelles.

C'est peut-être là la clé de bon nombre de mes propos, puisque je fais du DNRY pour une raison technique (ie. c'est ch***t de faire du copier-coller et de le maintenir) et non conceptuelle.

Le SRP découle tout seul du DNRY, ce n'est qu'une conséquence des concepts que j'applique.

---

Je trouve quelque peu dommage que des considérations techniques fassent que tu finisses par respecter des principes conceptuels parce que j'estime que la conception devrait précéder la mise en oeuvre, mais je trouve malgré tout que le fait que, au final, tes motivations techniques permettent de vérifier une grosse partie des considérations conceptuelles a quelque chose de rassurant ;)

Disons que je suis peut etre un peu plus fainéant que toi et que je préfères déchirer un petit dessin que de devoir revenir sur du code :D

Citation:

---

La différence n'est pas le résultat, mais les motivations. C'est bien pour cela que je dis que mon code ne suis pas ces principes, mais que ça n'empêche pas qu'ils soient vérifiés.

Mais on n'a pas parlé de SOLID au complet :
SRP : comme on l'a vu, oui par conséquence ;
OCP : même chose que SRP ;
LSP : là encore c'est la même chose que le SRP, bien que je me fiche pas mal des pre/post conditions... ;
ISP : celui-là je peux te dire qu'il va très souvent aux oubliettes de façon explicite :mrgreen: , ça n'empêche pas qu'il soit parfois vérifié ;
DIP : conséquence possible du DNRY :-°.

Pour l'ISP, je ne sais pas si ça rentre dans ce cadre, mais je suis très attaché au const-correctness, peut-être est-ce une application particulière de ce principe ?

Au final je m’aperçois que je dois ajouter le const-correctness dans ma liste car je n'y déroge jamais ^^.

---

Ben, je viens de répondre, hein :question: :D

Citation:

---

Tu as parlé de OLTC (acronyme que tu m'as appris à l'occasion, ce dont je te remercie ;)), et je trouve qu'il est à ce titre presque meilleur que RAII, car il parle de la "durée de vie", ce qui sous entend "de la construction à la destruction".

A la limite, je regrettais surtout de ne pas connaitre cet acronyme :D

---

Come on, men ! I just invented it !

Je viens juste d'inventer cet acronyme, ravi qu'il te plaise :).

Je suis d'accord avec toi que le mot RAII est assez malmené, puisqu'en plus de signifier l'inverse de sa signification littérale, il ne parle que d'une partie du problème.

Peut-être serait-il approprié de diffuser ce nouvel acronyme ?
En tout cas, je l'adopte définitivement pour mes prochaines discussions/explications/publications.
Il parle de lui-même, on ne peut pas en dire autant du RAII :?.

Citation:

---

Envoyé par moldavi

a- Pour apprendre le C++, vaut-il mieux avoir appris le C ?

Je suis d'accord pour dire que non. En effet le C est impératif et le C++ est objet, deux philosophies de développement complètement différentes.

Passer du C au C++ est très délicat parce que plus rien n'est linéaire, tout est dispatché dans les classes. Le développeur C se sent perdu, c'est trop abstrait.

Passer du C++ au C est tout aussi délicat, plus rien n'est en encapsulé, on a l'impression de ne pas pouvoir maîtriser correctement le code, la gestion des chaînes de caractères est un calvaire. Le développeur C++ se sent frustré.

b- Par contre, je pense que l'apprentissage de la programmation doit commencer par un langage comme le C ou un langage apparenté qui demande de la rigueur et la compréhension des pointeurs. Certe rigueur/compréhension sera très utile lorsque l'on développera avec des langages objets (C++, C# ou Java).

---

a- J'allais dire que ce n'est pas le débat ni le sujet de l'article. On parle de C Vs C++ procédural.
Les discussions ont légèrement dévié ensuite. En réponse je dirai que
- Dans les langages OO maintreams, dans tous les cas on commencera toujours par l'impératif (une instruction après l'autre), puis le procédural (notion de fonctions). Car ces langages ont ces deux propriétés et on ne peut pas passer à la suite tant qu'elles ne sont pas un minimum maitrisées. Après on peut enchainer sur les TAD (jusque là, c'est un cours classique d'algo & Ada), et montrer comment cela se réalise dans le paradigme objet. Puis introduire les notions de services, et montrer comment le SRP ne s'applique pas seulement aux fonctions mais aussi aux objets/acteurs du système.

- Dans tous les cas je préfère les mauvaises habitudes procédurales du C++ en C++, que les mauvaises habitudes du C en C++. Cela fait moins de dégâts.

On en arrive au point b-
b- Je m'inscris en faux. C'est du pipo complet. Oui pour bien faire il faudrait maitriser ce principe de rigueur pour faire du C. Sauf qu'il ne faut pas se leurrer, tout juste un élève sur 100 sera capable de l'appréhender à défaut de l'acquérir. Les cours ne sont pas orientés rigueur. La gestion des erreurs passent à la trappe -- je ne parle même pas de goto, mais de faire un if toutes les deux lignes. realloc est mal utilisé. printf reçoit des pointeurs n'importe comment. Les tailles finissent dans des int. Les casts pleuvent, en particulier entre tableaux et pointeurs (je ne vous dit même pas quand il y a plusieurs dimensions). Un élève qui sort d'un cours de C n'aura pas appris la rigueur (je vous renvois à l'article de Raymond Chen (auquel répondait l'article de Lahman) dont la genèse est justement liée à ces codes dépourvus de rigueur). Il aura appris à écrire des programmes qui tombent en marche -- le pire c'est que seuls les moins prétentieux en auront conscience.

Au moins en C++, pour la partie impérativo-procédurale équivalente, l'élève (qui suit un cours de C++ moderne, et non historique) aura appris à faire du code correct sans même sans rendre compte -- merci la SL et le RAII.
Il pourra ensuite continuer son apprentissage sur les TAD/classes.

---
Autre truc, je ne sais comment comment "haut-niveau" est apparu dans la discussion. Je considère que cela ne veut plus rien dire. Les langages vont supporter des choses appartenant à des familles distinctes et orthogonales (accès hardware, gestion fine de la mémoire, gestion implicite et/ou déterministe des ressources, Prog par contrat, OO, généricité, méta-prog générative, fonctionnel, déclaratif (cf prolog), lib standard minimale, prog concurrente, prog parallèle, réseau, bases de données, web services/bus logiciels, etc). Et pour chacune des familles on peut définir des sortes d'axes (à trous) et attribuer une note de support par les langages.
En fin de compte, on se retrouverait avec un graphe radar: http://fr.wikipedia.org/wiki/Diagramme_de_Kiviat

OLTC ne dit rien quant à comment ça fonctionne -- pourquoi cela ne correspondrait pas à un Life Time Manager comme il y a dans ACE?. De plus c'est restreint aux durées de vie, pas aux ressources (quid d'un pot de peinture à refermer et ranger à sa place sur l'étagère)

RAII se réfère à un principe bien précis (sitôt acquis, sitôt confié), même si la propriété qui nous intéresse le plus dans l'histoire est le RFID (Resource Finalization is Destruction).

OLTC n'a pas pour but de remplacer le RAII... il le complète !

Ma dernière phrase était peut-être ambigüe il est vrai et assez fausse s'il en est comme tu viens de le démontrer :aie: ...

Pour reprendre ton pot de peinture, c'est l'OLTC qui dit quand on doit acquérir le contrôle du pot de peinture (avant ou après le pinceau ?) et quand on doit le rendre (avant ou après le pinceau ?). Le RAII dit comment l'acquérir (on le sort de l'étagère et on ouvre le pot) et comment le rendre (on ferme le pot et on le remet sur l'étagère).

Encore une fois, l'OLTC se retrouve mêlé encore plus au RAII : on ferme le pot avant de le ranger ? ou l'inverse ? (réponse plus haut, assez évidente je pense...).

L'OLTC est déjà largement présent dans le C++ : si on regarde ne serait-ce que l'ordre de construction et de destruction dans une hiérarchie d'héritage, il est clair qu'un énorme travail a déjà été effectué dessus.

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 ? :aie: *), les return multiples, la move-semantic, les pointeurs, and so on... Le C++11 apporte un bon lot de fonctionnalités s'y rapportant. Ce qui contribue évidemment beaucoup à me faire apprécier le langage :D.

Se préoccuper de la durée de vie des objets avec minutie me semble être une bonne approche complémentaire au RAII.