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