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