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 ?

[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]

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.

[Taurre]

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

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 :

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

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 :

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

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) » ?

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 :

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

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

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

[koala01]

Code :

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

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

[Taurre]

Heu, le fameux débat sur l'utilisation de goto, ca te dit quelque chose 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.

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 ?

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

[jouana]

Juste pour dire merci, pour S.O.L.I.D je n'en avais pas entendu parler et il est vrai que ce type d'info est toujours bonne a prendre.

Bon article merci.

[LSMetag]

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

Oui on peut commencer par du C++ en procédural. Car le débutant serait largué de commencer direct par de la POO.
Mais c'est donner de mauvaises habitudes au programmeur.

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

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

[koala01]

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

Oui on peut commencer par du C++ en procédural. Car le débutant serait largué de commencer direct par de la POO.
Mais c'est donner de mauvaises habitudes au programmeur.

Ca se discute...

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

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

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

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

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

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

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

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

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

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

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

[LSMetag]

@koala01

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

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

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

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

[koala01]

@koala01

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

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

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

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

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

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

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

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

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

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

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

Code :

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

MaClass::maFonction(lesArgument);

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

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

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

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

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

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

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

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

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

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

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

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

[germinolegrand]

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

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

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

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

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

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

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

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

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

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

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

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

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

Tu sembles refuser SOLID, car cela te semble "trop stricte", mais, au final, tu semble pourtant appliquer les principes avec une rigueur particulièrement importante

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

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

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

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

[koala01]

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

Ben, je viens de répondre, hein