Discussion :

[gbdivers]

Bonjour à tous

Un adage bien connu dit qu’enseigner, c’est répéter. Ceux qui fréquentent depuis quelque temps le forum C++ de Developpez le savent très bien : on revoit les mêmes discussions revenir régulièrement. Ce billet de blog va tenter d’analyser un peu les arguments concernant l’apprentissage du C++, en se focalisant plus particulièrement sur les difficultés d’utilisation. En particulier le raisonnement suivant, que l’on entend souvent : « il est préférable d’apprendre le C avec le C++ », ainsi que l’affirmation suivante, souvent pas comprise : « le C++ est un meilleur langage pour débuter que le C ».

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

Au delà de l'aspect volontairement provocateur du titre, le but n'est pas la critique du C, mais bien la comparaison de quelques spécificités de ces langages et leurs conséquences en termes d'apprentissage. Et plus globalement, la question posée est comment doit être abordé l'enseignement du C++ moderne.

Comment pensez-vous que les différences d'approche entre le C et le C++ peuvent impacter leurs apprentissages respectifs ?
Quelles autres spécificités d'utilisation de ces langages peuvent poser des difficultés d'apprentissage ?

[Luc Hermitte]

Pour info, le realloc est mal utilisé et peu aussi masquer une fuite de mémoire.

[gbdivers]

Effectivement, même si l'utilisation de realloc n'est pas le propos, mettre du code pas très propre n'est pas pédagogique.

J'ai corrigé en :

Code :

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

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

C'est mieux ?

Sinon, j'utilise jamais realloc, il est sans problème possible que je l'utilise mal. Mais la question est aussi est ce que c'est pas comme ça que le débutant moyen va l'utiliser ? J'imagine qu'un développeur plus expérimenté ne fera pas l'erreur (et probablement pas les autres erreurs non plus).
Mais on constate quand même que les débutants refont souvent cette erreur (ce qui veut pas dire que les débutants C++ ne refont pas systématiquement les mêmes erreurs aussi )

[Luc Hermitte]

Si tu corriges printf, il faut corriger realloc aussi.
Après, je préfères justement insister à montrer du code correct, cela aide à démontrer quel code est plus facile à enseigner et quel autre (OK, le même) est plus facile à maintenir.

[gbdivers]

Si tu corriges printf, il faut corriger realloc aussi.
Après, je préfères justement insister à montrer du code correct, cela aide à démontrer quel code est plus facile à enseigner et quel autre (OK, le même) est plus facile à maintenir.

je dois avouer que tu m'as perdu. Tu peux préciser comment tu aurais écrit le code avec realloc ?

[Iradrille]

Article sympa.

Je trouve par contre bizarre de comparer C et C++, une comparaison Java et/ou C# vs C++ m'aurait semblé plus approprié (histoire de comparer des langages objets).

Sinon j'ai dans l'ensemble un avis contraire, je pense que le C est plus simple à prendre en main, le concept objet est quand même un gros morceau à apprendre. (Même si les avantages de l'objet en valent le coup )

Le C est un langage plus bas niveau et je pense que c'est une bonne chose quand on apprend : beaucoup moins d'abstraction, on sait exactement ce que le code qu'on écrit va faire (on pourrait presque en avoir une représentation en asm dans la tête, ce qui est bien plus dur en C++).

Concernant le cast de const char* en char*, bah c'est un warning, débutant ou pas si on ignore un warning, il faut s'attendre à des répercutions (-Werror peut aider à pas les ignorer).
Et on pourrait citer un contre exemple:

Code :

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

1
2
3
4
5
int main() {
	char c;
	for(c=0; c<1000; ++c);
	return 0;
}

qui demande de compiler avec -Wextra pour afficher un warning, aussi bien en C qu'en C++.

Les pointeurs, ya toujours une erreur possible faut vraiment faire gaffe mais là pas vraiment de différence entre C et C++.

Pour les std::string (et plus généralement la STL), c'est une répercution d'avoir un langage objet, une couche d'abstraction qui nous permet de ne pas nous soucier de la gestion de la mémoire car gérée en interne.
Ça permet de coder plus rapidement et de manière plus sure, et c'est évidement un gros avantage pour le C++.

Pour les templates qui permettent de tester énormément de choses à la compilation c'est aussi un gros plus pour le C++, mais encore une fois, la prise en main n'est pas aisée.

Quelles autres spécificités d'utilisation de ces langages peuvent poser des difficultés d'apprentissage ?[/B]

- le paradigme objet (ça peut sembler con, mais c'est une façon de penser complètement différente).
- déjà cité mais la gestion de la mémoire, qui est vraiment au cœur de ces 2 langages.

TL;DR: les avantages de l'objet sont indéniables mais c'est des principes pas forcément faciles à maîtriser, ce qui rend, selon moi, le C plus simple à appréhender.

[koala01]

Salut,

Article sympa.

Je trouve par contre bizarre de comparer C et C++, une comparaison Java et/ou C# vs C++ m'aurait semblé plus approprié (histoire de comparer des langages objets).

l'idée n'était pas de comparer les différents langage OO, mais bien de donner une réponse à une question qui est régulièrement abordée: faut il absolument connaitre C si on veut apprendre C++

Sinon j'ai dans l'ensemble un avis contraire, je pense que le C est plus simple à prendre en main, le concept objet est quand même un gros morceau à apprendre. (Même si les avantages de l'objet en valent le coup )

Le fait de ne voir C++ que comme un langage OO est réducteur, et c'est sommes toutes l'erreur que font tous ceux qui croient qu'il faut impérativement passer par C avant de l'apprendre.

C'est oublier un peu vite que C++ est multi paradigme (l'un des rares langages à l'être à ma connaissance) et que, bien que cela le rende plus complexe, ca le rend aussi particulièrement adapté à l'apprentissage.

En effet, l'un des paradigmes qu'il propose est le paradigme impératif: tu peux donc parfaitement l'utiliser comme base pour l'apprentissage des principes de programmation impérative simple (concept de boucle, de test, de fonctions,...)

Si tu dis que tu reviendras "en temps utiles" sur les collections (qui sont un mélange du paradigme OO et du paradigme générique), le récipiendaire peut déjà aller finalement très loin dans l'étude de la programmation impérative sans avoir à aborder le point le plus problématique que l'on trouve en C (de par tout ce que cela peut représenter): les pointeurs.

On peut aller très loin à condition de dire "je vous parlerai de std::vector<UnType>.push_back(); en temps utiles", aussi bien en terme d'apprentissage des principes qu'en terme d'apprentissage du langage lui-même .

Une fois ces principes et la syntaxe correctement assimilés, on peut alors aborder le paradigme OO, et ce n'est qu'à ce moment là que le besoin des pointeurs commencera à se faire sentir.

Mais, à ce moment là, le récipiendaire saura déjà ce qu'est une fonction, aura déjà assimilé des principes comme le SRP, et autres: la transition sera donc bien plus aisée

Cette partie de l'apprentissage peut d'ailleurs se faire avec un introduction du genre "bon, on a vu comment nous pouvions réfléchir en termes de données, maintenant, on va réfléchir autrement: en terme de services rendus".

La courbe d'apprentissage reste donc beaucoup plus douce que ce qu'elle n'est en C

Et, une fois les principes OO assimilés, il n'y a plus que le paradigme générique à aborder, en changeant une fois de plus l'approche que l'on a, sous la forme de "maintenant, essayons de réfléchir non plus en terme de donnée, non plus en terme de services rendus, mais en termes de manière dont on pourrait manipuler les données et les objets, sans savoir forcément quel en est le type".

Tout cela concourt une fois de plus à une courbe d'apprentissage beaucoup plus douce que celle que l'on peut obtenir avec des langages mono-paradigmes, qu'il soient orientés fonctions (comme C) ou pire, orientés objets (comme java ou C#) car la notion de fonction fait malgré tout partie intégrante du paradigme objets

Ceci dit:

La syntaxe et la "grammaire" d'un langage s'apprend en quelques heures à peine : comment déclarer une fonction ou une variable, comment créer une boucle ou un test, ce n'a vraiment rien de bien compliqué.

De même, apprendre la signification des mots clés n'a pas grand chose de compliqué (il y en a quoi? nonante, en comptant ceux apportés par C++11, en C++ ?).

Toute la difficulté de l'apprentissage du développement logiciel vient exclusivement du fait qu'il faut apprendre à mettre un certain nombre de principe correctement en œuvre, qu'il est difficile d'accepter pour quiconque le fait qu'un principe se doit d'être appliqué "au pied de la lettre" et sans tenter d'aucune manière de les adapter en fonction de nos besoins.

Une fois que le déclic se fait dans la tete du récipiendaire que le principe de Liskov est la clé de voute de tout ce qui touche à l'héritage, une fois que sont compris l'ensemble des principes énoncés par S.O.L.I.D., une fois (surtout) qu'il est clair qu'il ne faut en aucun cas envisager de déroger à ces principes, ne serait-ce qu'en essayant d'y apporter la moindre interprétation plus permissive que ce qui est écrit, il n'y a plus aucun langage OO qui puisse poser problème à l'apprentissage.

Et c'est à ce moment là que l'on se rend compte que les langages comme java ou C# ont tendance à favoriser la médiocrité

[germinolegrand]

Je trouve par contre bizarre de comparer C et C++, une comparaison Java et/ou C# vs C++ m'aurait semblé plus approprié (histoire de comparer des langages objets).

Oui, sauf que...
Contrairement au Java/C#, C++ est un langage multiparadigme. Il n'y a pas plus de raisons de le comparer à un langage objet qu'à un langage impératif.

Le C est un langage plus bas niveau et je pense que c'est une bonne chose quand on apprend : beaucoup moins d'abstraction, on sait exactement ce que le code qu'on écrit va faire (on pourrait presque en avoir une représentation en asm dans la tête, ce qui est bien plus dur en C++).

Comme on peut réécrire strictement la même chose au final en restant dans du C++, cet avantage n'en est pas un. C'est même le contraire : en C on est obligé rester ultra-bas niveau, même quand on ne voudrait pas.

Les pointeurs, ya toujours une erreur possible faut vraiment faire gaffe mais là pas vraiment de différence entre C et C++.

Un std::unique_ptr, et le tour est joué, on touche plus au pointeur. Excepté à l'allocation, on peut se balader avec des références : pas de confusion.

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

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.

-------------------
Edit :

Une fois que le déclic se fait dans la tete du récipiendaire que le principe de Liskov est la clé de voute de tout ce qui touche à l'héritage, une fois que sont compris l'ensemble des principes énoncés par S.O.L.I.D., une fois (surtout) qu'il est clair qu'il ne faut en aucun cas envisager de déroger à ces principes, ne serait-ce qu'en essayant d'y apporter la moindre interprétation plus permissive que ce qui est écrit, il n'y a plus aucun langage OO qui puisse poser problème à l'apprentissage.

C'est pas le sujet ici, mais j'ai juste envie de dire : "Non." à ce paragraphe .
Sinon je suis d'accord avec tout le reste de ce que tu as dit ^^

[JolyLoic]

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.

Je ne le dirais pas obsolète, car pour moi il a deux avantages où il bat le C++ sans hésiter :
- Il est tellement simple qu'il est possible de trouver un compilateur C partout, et que ce compilateur ne sera pas trop buggé, voire même sera certifié conforme (important dans certaines parties de code embarqué touchant à la sécurité).
- Il reste un très bon dénominateur commun pour interfacer entre eux des langages divers et variés, alors qu'on ne sait même pas toujours interfacer entre eux deux bouts de programmes C++, même écrits avec le même compilateur (mais des options différentes).

A part ces deux usages, en effet, il faudrait vraiment trouver de très bons arguments pour me faire faire du C.

[Luc Hermitte]

je dois avouer que tu m'as perdu. Tu peux préciser comment tu aurais écrit le code avec realloc ?

Ben... fais remonter l'erreur au cran de la fonction au dessus. Et pense à prévoir comment nettoyer, tout ça quoi.
Tu vois l'enfer ? C'est la plus belle démonstration que le simplisme du C n'en fait pas un langage dans lequel il est simple de développer. C'est pour ça aussi que je ressors régulièrement les exemples de l'article de Lahman qui a été traduit il y a peu.

a- Je trouve par contre bizarre de comparer C et C++, une comparaison Java et/ou C# vs C++ m'aurait semblé plus approprié (histoire de comparer des langages objets).

b- Sinon j'ai dans l'ensemble un avis contraire, je pense que le C est plus simple à prendre en main, le concept objet est quand même un gros morceau à apprendre. (Même si les avantages de l'objet en valent le coup )

c- Le C est un langage plus bas niveau et je pense que c'est une bonne chose quand on apprend : beaucoup moins d'abstraction, on sait exactement ce que le code qu'on écrit va faire (on pourrait presque en avoir une représentation en asm dans la tête, ce qui est bien plus dur en C++).

d- Les pointeurs, y a toujours une erreur possible faut vraiment faire gaffe mais là pas vraiment de différence entre C et C++.

e- Pour les std::string (et plus généralement la STL), c'est une répercution d'avoir un langage objet, une couche d'abstraction qui nous permet de ne pas nous soucier de la gestion de la mémoire car gérée en interne.
Ça permet de coder plus rapidement et de manière plus sure, et c'est évidement un gros avantage pour le C++.

e-
- le paradigme objet (ça peut sembler con, mais c'est une façon de penser complètement différente).
- déjà cité mais la gestion de la mémoire, qui est vraiment au cœur de ces 2 langages.

TL;DR: les avantages de l'objet sont indéniables mais c'est des principes pas forcément faciles à maîtriser, ce qui rend, selon moi, le C plus simple à appréhender.

a- C'est une comparaison qui ne vient pas de nous, mais de débutants qui la posent et demandent leur chemin de temps à autre, et bien plus souvent qu'on ne peut le croire.

b- Ecris des codes robustes aux erreurs et on en reparlera. Et maintenant enseigne des codes corrects et robustes aux débutants en C, et vois à faire la même chose, tout en restant en impératif en C++.
Quel est le langage qui permet d'enseigner correctement (pour montrer des choses justes et robustes et simples) ?

c- Je ne suis pas d'accord. Ada est un excellent langage d'apprentissage, de même que Pascal. Et pourtant ils fournissent des abstractions, non OO, pour les premiers pas -- OK, Pascal moins.
La SL fais parti du langage, ce n'est pas une annexe.

d- Dans une séquence d'apprentissage newbs-friendly, tu n'as pas besoin de perdre les étudiants dès le second chapitre avec les pointeurs en C++. On peut attendre le chapitre sur le polymorphisme pour le faire -- ou du moins le dernier moment avant les classes.
Je renvoie comme d'hab' à /je me lance/ de Francis Glassborrow qui est un bouquin d'initiation pour profil de non-informaticien/geek/technophile avec C++ comme langage support. Le livre n'aborde que la partie impérative du C++ et sa lib standard. Pas un mot (en fait si, une (seule) note de bas page) sur les pointeurs. Pas de classes à écrire, pas des templates à écrire.
Bref, pointeurs ? -> string, vector, RAII, shared_ptr<>, ... Une utilisation idiomatique du C++ utilise les pointeurs d'une façon radicalement différente de celle du C. Et on n'a pas le choix, les idiomes du C ne sont pas applicables à cause des exceptions. Heureusement pour nous le résultat fait que c'est plus facile de coder en C++.

e- Ce n'est pas le sujet. Ce n'est pas la question de "commencer OO ou impératif ?", mais de "C ou C++ pour commencer en impératif ?"

[Iradrille]

d- Dans une séquence d'apprentissage newbs-friendly, tu n'as pas besoin de perdre les étudiants dès le second chapitre avec les pointeurs en C++. On peut attendre le chapitre sur le polymorphisme pour le faire -- ou du moins le dernier moment avant les classes.
Je renvoie comme d'hab' à /je me lance/ de Francis Glassborrow qui est un bouquin d'initiation pour profil de non-informaticien/geek/technophile avec C++ comme langage support. Le livre n'aborde que la partie impérative du C++ et sa lib standard. Pas un mot (en fait si, une (seule) note de bas page) sur les pointeurs. Pas de classes à écrire, pas des templates à écrire.
Bref, pointeurs ? -> string, vector, RAII, shared_ptr<>, ... Une utilisation idiomatique du C++ utilise les pointeurs d'une façon radicalement différente de celle du C. Et on n'a pas le choix, les idiomes du C ne sont pas applicables à cause des exceptions. Heureusement pour nous le résultat fait que c'est plus facile de coder en C++.

e- Ce n'est pas le sujet. Ce n'est pas la question de "commencer OO ou impératif ?", mais de "C ou C++ pour commencer en impératif ?"

@koala01, germinolegrand, Luc Hermitte
Ok, avec ça de précisé je comprend mieux vos réponses, je pensais jusque là qu'on comparait du C++ orienté objet avec du C.
(éventuellement à préciser dans l'article ?)

Du coup c'est sur que comparer du C++ impératif (du C + la STL en gros) à du C, oui le C++ est plus simple.

[gbdivers]

@koala01, germinolegrand, Luc Hermitte
Ok, avec ça de précisé je comprend mieux vos réponses, je pensais jusque là qu'on comparait du C++ orienté objet avec du C.
(éventuellement à préciser dans l'article ?)

Du coup c'est sur que comparer du C++ impératif (du C + la STL en gros) à du C, oui le C++ est plus simple.

Hum, le code présenté est similaire en C et C++. Il n'y a pas du tout d'objet, ni dans le code, ni dans les concepts. Et même si on préfère l'objet en C++ à l'impératif, l'apprentissage de celui ci est nécessaire (comment écrire un objet, sans savoir avant écrire une fonction, déclarer et initialiser une variable, écrire une boucle ?)

Ce qu'il faut retenir, c'est qu'a chaque langage, sa philosophie. Et cela à un impact sur comment doit on enseigner le langage. La démonstration aurait été probablement similaire avec la comparaison de la POO en C++ et Java. L'apprentissage de la programmation ne se limite à l'apprentissage d'un langage et les langages ne sont pas totalement substituables (pas au sens de Liskov pour une fois )

@Luc Hermitte
Ok. Donc c'est bien le propos : c'est plus compliqué que ne le laisse penser la simplicité apparente du langage.

@Autres
Pour ceux qui ça intéresse, l'article de Lahman cité par Luc est Retour de fonctions ou exceptions ?

Edit :

Une fois que le déclic se fait dans la tete du récipiendaire que le principe de Liskov est la clé de voute de tout ce qui touche à l'héritage, une fois que sont compris l'ensemble des principes énoncés par S.O.L.I.D., une fois (surtout) qu'il est clair qu'il ne faut en aucun cas envisager de déroger à ces principes, ne serait-ce qu'en essayant d'y apporter la moindre interprétation plus permissive que ce qui est écrit, il n'y a plus aucun langage OO qui puisse poser problème à l'apprentissage.

C'est pas le sujet ici, mais j'ai juste envie de dire : "Non." à ce paragraphe .
Sinon je suis d'accord avec tout le reste de ce que tu as dit ^^

Je vais prendre une position intermédiaire (oui, je sais, c'est lâche ) : comme probablement tous les principes (informatiques ou non), il doit exister des situations où on peut ne pas les respecter.
L'erreur est d'avoir l’arrogance de penser que l'on peut les rejeter sans une parfaite compréhension de ces principes, de leurs tenants et aboutissants, et être dans une telle situation de non respect légitime

[germinolegrand]

Parce que ce paragraphe ne ressemble à rien d'autre qu'à une dictature de l'esprit .

Alors je réponds simplement que non. Le style SOLID ne me convient pas, je le trouve trop rigide. Parce que je suis persuadé que tout n'a pas encore été inventé, et qu'aucune méthode n'est parfaite. C'est aussi simple que cela.

Ce n'est pas pour autant que je ne respecte aucun de ces principes, bien au contraire. Toutefois, ce n'est qu'une conséquence remarquée, non le résultat d'une règle appliquée. Aussi s'ils sont foulés au pied, cela ne me fait ni chaud ni froid.

Oui, j'ai l'arrogance de me sentir libre dans un vaste univers à peine effleuré, inexploré...

[koala01]

Parce que ce paragraphe ne ressemble à rien d'autre qu'à une dictature de l'esprit .

Mais, mon pauvre ami, tout n'est jamais que dictat...

La seule différence entre une dictature et une démocratie, c'est que la dictature te dira "ferme ta gueule" (et te tuera peut etre pour t'y obliger) alors que la démocratie te dira "cause toujours, tu m'intéresses", sans hésiter à te tuer d'une certaine manière

Alors je réponds simplement que non. Le style SOLID ne me convient pas, je le trouve trop rigide. Parce que je suis persuadé que tout n'a pas encore été inventé, et qu'aucune méthode n'est parfaite. C'est aussi simple que cela.

Il est très certainement rigide, peut etre perfectible, mais en attendant, le fait de l'appliquer de manière stricte et rigide fonctionne à tous les coups.

Beaucoup de (tous les )problèmes que l'on peut rencontrer dans un développement complexe viennent de libertés prises vis à vis de SOLID, à tel point que la solution pour y remédier passe de manière quasi systématique par le fait de s'en rapprocher.

Proposes moi une solution moins rigide qui apporte les même garanties, je ne manquerai pas d'être séduit

Ce n'est pas pour autant que je ne respecte aucun de ces principes, bien au contraire. Toutefois, ce n'est qu'une conséquence remarquée, non le résultat d'une règle appliquée. Aussi s'ils sont foulés au pied, cela ne me fait ni chaud ni froid.

Sans doute prends tu le problème à l'envers:

Ce que je constate, c'est que les projets sur lesquels SOLID est appliqué au pied de la lettre sont beaucoup plus facilement maintenables et évolutifs que ceux pour lesquels des libertés ont été prise vis à vis de ces principes.

Là est la constatation.

Le fait de s'imposer la règle de l'appliquer de manière stricte découle "naturellement" de cette constatation

Oui, j'ai l'arrogance de me sentir libre dans un vaste univers à peine effleuré, inexploré...

Icare a eu la même arrogance, et il s'est brulé les ailes

[Invité]

Juste une petit question comment on peut dire que le C++ est mieux que le C pour commencer!!

Déja le C++, s'appuie sur le C, deplus le C n'est pas un langage objet contrairement au C++. Perso je pense que pour bien appréhender le langage (synthaxe, mot clé, ...) il est préférable de s'affranchire de la couche objet du C++, cela permet de bien maitriser les technique en C pour pouvoir les appliquer au C++.

Certain dirons, peut être, que je suis vieux jeux, mais je pense quand developpement il ne faut pas bruler les étapes!!

[Klaim]

Juste une petit question comment on peut dire que le C++ est mieux que le C pour commencer!!

Déja le C++, s'appuie sur le C, deplus le C n'est pas un langage objet contrairement au C++. Perso je pense que pour bien appréhender le langage (synthaxe, mot clé, ...) il est préférable de s'affranchire de la couche objet du C++, cela permet de bien maitriser les technique en C pour pouvoir les appliquer au C++.

Certain dirons, peut être, que je suis vieux jeux, mais je pense quand developpement il ne faut pas bruler les étapes!!

Et tu as les arguments de l'article?

[gbdivers]

@germinolegrand
Si tu te balades dans les rues de paris et que tu décides de ne pas lire une carte, c'est pas pour autant que tu es dans un "vaste univers à peine effleuré, inexploré", non ?
Pareil pour l'informatique, c'est pas parce que tu ignores les travaux et principes qui t'ont précédé que tu es pour autant dans l'inexploré (juste dans l'ignorance, c'est pas pareil)
L’arrogance n'est pas de sentir libre, c'est de penser que l'on est plus libre que les autres, que l'on peut rejeter ce que l'on a pas fait soit même, comme si les autres étaient moins compétant que soi. L'arrogance, c'est rejeter ces principes que l'on maîtrise pas alors que des personnes plus expérimentées que toi (et que moi par la même occasion) disent qu'ils ont de bonnes raisons de respecter ces principes

Bien sur, mes propos ne s'adresse pas qu'à germinolegrand (qui n'est clairement pas le plus incompétent ici), l'arrogance est une "qualité" très largement partagée, par les débutants et plus expérimentés (moi compris, il peut m'arriver d'être arrogant et pas voir mes erreurs)

[Freem]

Intéressant article.

Par contre, il y a une chose qui m'a fait sauter au plafond (enfin, non, parce qu'ici il est bien à 3m et je suis pas un athlète...):

"std::shared_ptr pour les pointeurs, etc."

STOP!!!!!!!!!!
Par pitié, éviter de citer shared_ptr à tout va comme ça... Cet outil est dangereux: risques de références circulaires que l'on dois combattre avec weak_ptr, empêchements de maintenir parce qu'on ne sait pas qui exactement est responsable, augmentation des ressources consommées du programme (ram et cycles, même si ce n'est pas énorme, sur une ou deux instances, sur quelques milliers, ce n'est pas la même affaire!), ce genre de choses... pas très joyeuses.

Alors qu'a côté, on à un joli unique_ptr, qui consomme bien moins de ressources, évite quelques problèmes architecturaux de responsabilité, et n'a absolument aucun risque de références circulaires.


Pour le reste, c'est marrant de constater qu'a chaque fois que quelqu'un sort l'objet, il sort des principes dans tous les sens, et des acronymes à coucher dehors dont je n'ai jamais entendu parler.
Liskov? Euh, j'ai tenté de lire le truc sur wikipedia, j'ai rien compris... SOLID? J'ai eu la flemme de chercher un mot de ce genre... trop de risques de devoir fouiller 3H.
Cela dis, j'en connais quand même quelques uns aussi: GRASP, et le truc qui dit que si on implémente un Ctor, il faut faire d'autres implémentations... me rappelle jamais le nom...

Pour autant, suis-je un mauvais "dev objet"?
Je n'en suis pas si sûr... quoique si quelqu'un veut me juger, j'en serais heureux (avoir l'avis d'autres confrères n'est jamais une mauvaise chose, il faudra que je cherche du côté des communautés de revue de code, si ça existe)
Ne pas être mauvais ne signifie pas forcément être bon, bien sûr, et je sais que je ne suis pas encore bon, mon arrogance de débutant, j'en ai perdue une grande partie (pas tout, j'avoue) en 10 ans de dev autodidacte.


Et pour finir:

@gcorbineau:
C++ peut être objet, oui. Mais C++ peut aussi être générique, ou impératif, ou n'importe quel mélange de ces paradigmes.
Ta réponse prouve 2 choses:
_ tu n'as pas lu l'article
_ tu n'as pas lu la discussion, ou tu as occulté les gens qui répondaient directement à ta question

L'envie de dire "troll spotted" est donc super forte...

[Gugelhupf]

Je pense que la seule difficulté du C par rapport au C++, c'est la gestion des pointeurs (sachant qu'en C++ on peut s'en passer grâce aux références).
Manipuler les chaines de caractères et faire de l'affichage (exercices que l'on pratique souvent au début) sont aussi plus simple en C++.

Après faut pas abuser, en C++ il y a plus de notion comme la POO (dont héritage, polymorphisme, RAII), les espaces de nom, les flux, les surcharges d'opérateur etc...

[koala01]

Juste une petit question comment on peut dire que le C++ est mieux que le C pour commencer!!

On ne dit pas que C++ est mieux pour commencer (quoi que (*)), on dit qu'il ne faut pas connaitre C pour apprendre C++

(*) A vrai dire, oui, C++ est mieux pour commencer que C car il permet justement de n'avoir pas à s'inquiéter directement de problème dont on ne prend réellement conscience qu'avec un minimum d'expérience.

L'exemple le plus frappant consiste en la gestion dynamique de la mémoire: En C, tu dois aborder les pointeurs et la gestion dynamique de la mémoire dés le deuxième chapitre (tout de suite après avoir vu ce qu'est une boucle ou un test), rien que pour pouvoir concaténer deux chaines de taille inconnue à l'écriture du code.

En C++, tu peux ne commencer à t'inquiéter des problèmes liés aux pointeurs qu'une fois que tu as déjà "pris de la bouteille" car il propose des mécanismes qui rendent la gestion de la mémoire totalement transparente (si tu veux concaténer deux chaines, tu utilises l'opérateur + ou += sur deux std ::string, et "basta", tu utilises push_back sur n'importe quelle collection pour ajouter un élément, sans avoir à t'inquiéter de savoir s'il faut ou non prévoir d'augmenter la capacité de cette collection)

Déja le C++, s'appuie sur le C, deplus le C n'est pas un langage objet contrairement au C++.

A vrai dire, C++ n'a plus rien à voir avec C, même s'il ne renie absolument pas son héritage.

Cependant, si je ne renie absolument pas mes origines, et que j'avoue avoir hérité de certains aspects du caractère de mon père, je refuserai toujours qu'on me confonde avec lui, et même sans doute qu'on tente de m'y comparer.

Il en va de même pour C++: il assume son héritage de C, il assume une certaine compatibilité avec celui-ci, mais il est totalement faut et restrictif de dire que C++ n'est "que du C amélioré".

C'est un langage totalement différent, qui apporte un grand nombre de possibilités totalement nouvelles par rapport au C et qui, surtout, est en mesure d'apporter une sécurisation beaucoup plus importante

Perso je pense que pour bien appréhender le langage (synthaxe, mot clé, ...) il est préférable de s'affranchire de la couche objet du C++, cela permet de bien maitriser les technique en C pour pouvoir les appliquer au C++.

Justement:

Vouloir limiter C++ à son paradigme orienté objets est particulièrement réducteur car il propose trois paradigmes (impératif (orienté fonctions), orienté objets et générique).

Le sens de l'article est de dire que l'on peut s'habituer à la syntaxe et à la grammaire de C++ en se limitant à son paradigme impératif et que cela aura pour principal intérêt de permettre de ne s'inquiéter de certains problèmes que lorsqu'ils se poseront réellement (encore une fois, on n'a besoin de l'allocation dynamique de la mémoire qu'un fois qu'on aborde la programmation OO et l'héritage )

Certain dirons, peut être, que je suis vieux jeux, mais je pense quand developpement il ne faut pas bruler les étapes!!

Je me pose la même question que Klaim : as tu lu l'article avant de répondre

Si ce n'est encore fait, je te conseille de prendre le temps de le lire, cela évitera au moins de devoir répéter ici ce qui est clairement expliqué dans l'article