Discussion :

[maxim_um]

Salut tout le monde;

Ah! Le sempiternel débat C/C++.

Quand je me rends compte qu'il y en a qui en sont encore là, alors que d'autres avancent.
Je pense qu'il faut les voir comme des "langages spécialisés", le C étant particulièrement adapté aux programmes bas nivéaux, et le C++, d'un niveau supérieur donc, est très pertinent pour les développements applicatifs. Le jour où on arrêtera de les opposer, les gens verront peut-être plus clair. Après, bien sûr, dans la pratique, on rencontre des exceptions et l'utilisation de certaines API peut nous imposer dans un code C++ à utiliser par exemple des «char*». Mais en dehors de ces cas particuliers, il convient de ne pas restreindre le langage et au contraire, utiliser ce qu'il offre de plus puissant. Après tout, c'est ça savoir programmer.

[loufoque]

Je pense que le C++ n'est pas un bon langage pour apprendre les techniques générales ; il est plus efficace et intéressant de les apprendre ailleurs puis d'apprendre à les adapter.

Cela est du au fait que le C++ est un outil avec lequel on peut faire ce qu'on veut, et que pour apprendre une manière de programmer mieux vaut un outil dédié conçu pour et autour cette manière exclusivement.

Bref pour former aux techniques de programmation, mieux vaut faire du Fortran, de l'Ada, du Modula 2, du LISP, du ML, du Eiffel, du Scala, du Java, etc. puis transférer tous ces acquis en C++ ; puisque c'est là ça force : on peut tout y faire.

Quand je me rends compte qu'il y en a qui en sont encore là, alors que d'autres avancent.
Je pense qu'il faut les voir comme des "langages spécialisés",

Apparemment, ils avancent pas du tout dans la bonne direction...

[koala01]

Je pense que le C++ n'est pas un bon langage pour apprendre les techniques générales ; il est plus efficace et intéressant de les apprendre ailleurs puis d'apprendre à les adapter.

Cela est du au fait que le C++ est un outil avec lequel on peut faire ce qu'on veut, et que pour apprendre une manière de programmer mieux vaut un outil dédié conçu pour et autour cette manière exclusivement.

Bref pour former aux techniques de programmation, mieux vaut faire du Fortran, de l'Ada, du Modula 2, du LISP, du ML, du Eiffel, du Scala, du Java, etc. puis transférer tous ces acquis en C++ ; puisque c'est là ça force : on peut tout y faire.

C'est un avis qui peut se tenir, mais, alors (je prend l'exemple de Java, ne connaissant que peu les autres), tu risques d'en arriver à ce que l'étudiant s'interroge d'une mauvaise manière sur les méthodes de conception, UML entre autre, et finisse par s'en détourner sous prétexte de

A quoi bon perdre du temps à la conception, si ce n'est quand meme pas pour pouvoir implémenter exactement ce que je conçois avec le langage que j'apprend

(je pense entre autres à l'héritage multiple, mais cela peut s'appliquer à d'autres partie de la conception )

De plus, je me pose la question de ce qui est le mieux au final: apprendre avec un langage offrant une "liberté" absolue, incluant celle de faire de fantastiques boulettes puis, mais provoquant une responsabilisation importante de l'étudiant, ou, au contraire, lui faire apprendre avec un langage lui offrant moins de liberté, mais étant aussi de nature à le "déresponsabiliser" dans une certaine mesure (GC inside )

La question reste ouverte, car chacun verra midi à sa porte

Ceci dit, peut être devrions nous recentrer le débat: à l'origine, il portait sur le fait de savoir s'il faut passer par la connaissance (même partielle) du C pour apprendre le C++, s'il faire un "passage obligé" par le "C with class" entre les deux, ou s'il est préférable d'apprendre C++ de manière indépendante de toute connaissance du C (quitte à ce qu'ils soient tous les deux appris en parallèle).

[maxim_um]

Salut tout le monde;

Quand je me rends compte qu'il y en a qui en sont encore là, alors que d'autres avancent.
Je pense qu'il faut les voir comme des "langages spécialisés",

Apparemment, ils avancent pas du tout dans la bonne direction...

Tu ne peux pas être cruel avec eux et en même temps laisser de côté le reste de la citation, elle est importante.

En fait, le fait de présenter le C et le C++ comme deux langages différents et spécialisés, l'un par rapport à l'autre, évite justement le genre de débat stérile auquel est confronté r0d pendant ses formations. Ainsi, les aberrations où certains cèdent à la facilité ou au réflexe de coder en C alors qu'ils sont dans un contexte C++, ne sont plus justifiées.

à l'origine, il portait sur le fait de savoir s'il faut passer par la connaissance (même partielle) du C pour apprendre le C++, s'il faire un "passage obligé" par le "C with class" entre les deux, ou s'il est préférable d'apprendre C++ de manière indépendante de toute connaissance du C (quitte à ce qu'ils soient tous les deux appris en parallèle).

En effet, c'est là qu'on en arrive à un point crucial, le système éducatif. Je pense que si le C++ était enseigné avant le C, la réalité serait toute autre.

Enfin, j'ouvre une dernière parenthèse au sujet de ce que loufoque a écrit plus haut:

pour former aux techniques de programmation, mieux vaut faire du Fortran, de l'Ada, du Modula 2, du LISP, du ML, du Eiffel, du Scala, du Java, etc. puis transférer tous ces acquis en C++ ; puisque c'est là ça force : on peut tout y faire.

Comme koala01, je pondère aussi cet avis.
Un langage peut effectivement être un support pour former aux techniques de programmation, mais il ne saurait remplacer la pédagogie d'un bon professeur. Une approche algorithmique est à même de combler le vide qu'il pourrait y avoir entre le langage et sa bonne utilisation. Pour les autres sus-cités (exception faite de java), je les mettrais plutôt dans un atelier découverte qui contribuerait à la culture générale du futur développeur et qui par la même occasion, lui ouvrirait de nouveaux horizons. Ensuite, face à la réalité économique et ses plaisirs personnels, libre à lui de les approfondir ou pas.

[loufoque]

Tu ne peux pas être cruel avec eux et en même temps laisser de côté le reste de la citation, elle est importante.

C'était toi (les autres qui avancent) que je critiquais.
C et C++ sont tout sauf spécialisés. "C c'est pour la programmation système" c'est faux, et "C++ c'est pour le développement d'applications" également.

Les deux sont des langages general-purpose, et s'appliquent à tout.

Un langage peut effectivement être un support pour former aux techniques de programmation, mais il ne saurait remplacer la pédagogie d'un bon professeur. Une approche algorithmique est à même de combler le vide qu'il pourrait y avoir entre le langage et sa bonne utilisation.

Les techniques de programmation ont peu à voir avec l'algorithmique, et sont fortement liées au langage de programmation, comme le nom le sous-entend. Une technique, c'est une manière d'utiliser la technologie ; ce qui est plutôt déconnecté de la théorie fournie par l'algorithmique. (il y a un lien avec la théorie, mais c'est la théorie des types, la logique, le lambda calcul, la théorie des catégories, etc.)
Malheureusement, les seules techniques qu'on enseigne (et en plus en M2, quelle rigolade, à ce niveau-là les élèves les connaissent déjà) ce sont les Design Patterns tels que décrits par le GoF, qui sont plus surfaits qu'autre chose.

Mais il y a plein de techniques, par exemple liées à la programmation fonctionnelle, qui sont très intéressantes à connaître et pas forcément impossible à transférer vers d'autres langages, même le C.

je les mettrais plutôt dans un atelier découverte qui contribuerait à la culture générale du futur développeur et qui par la même occasion, lui ouvrirait de nouveaux horizons.

Les mécanismes de typage, les formes de polymorphisme, les paradigmes, etc. sont des éléments fondamentaux dans la culture d'un développeur, il ne s'agit pas juste de bonus "découverte".
L'étendue de cette culture est généralement ce qui différencie un bon développeur d'un mauvais.

Pour ce qui est de l'apprentissage du C et du C++, moi je pense qu'il est mieux d'enseigner le C avant ; il faut juste faire attention à bien présenter le C++ comme un langage différent quand on l'enseigne ensuite, au même titre que tous les autres langages que l'on enseigne.
Cela permet de pouvoir se consacrer uniquement à l'enseignement des choses spécifiques à C++ et pouvoir donc considérer le sous-ensemble C comme acquis.

[Mac LAK]

Cela permet de pouvoir se consacrer uniquement à l'enseignement des choses spécifiques à C++ et pouvoir donc considérer le sous-ensemble C comme acquis.

C'est le cas majoritaire actuellement, et ça produit des "printf" et des "char*" dans le code C++...

[maxim_um]

Les deux sont des langages general-purpose, et s'appliquent à tout.

Quel est l'intérêt du C alors ?

Je ne souhaite pas entretenir le troll. J'ai donné mon point de vue sur la question, qui concerne essentiellement les étudiants. Persister dans une attitude obscurantiste, ne fait qu'amener à des débats où vraisemblablement il faut beaucoup s'investir dans d'autres langages pour en apprendre d'autres, à défaut d'être plus essentiel. En tout cas, à titre personnel, j'aurais préféré y voir de l'assembleur.

Voilà, je terminerais ainsi sur deux citations. Une de Blaise Pascal (qui ne manquera pas de plaire à r0d je l'espère) et l'autre de Mac Lak ().

La vérité est si obscurcie en ce temps et le mensonge si établi, qu'à moins d'aimer la vérité, on ne saurait la reconnaître.

C'est le cas majoritaire actuellement, et ça produit des "printf" et des "char*" dans le code C++...

Je ne sais pas si je fais bien de mettre ces deux citations ensemble, mais la vérité c'est ça, c'est que tant que les attitudes ne changent pas, on fera du sur place.

[koala01]

Quel est l'intérêt du C alors ?

On peut en voir plusieurs (et pas forcément dans l'ordre indiqué):

• Certains sont définitivement fâchés avec le paradigme OO ou le paradigme générique
• Comme pour tout langage existant depuis un certain temps, il existe des millions (des milliards ) de lignes de code encore utilisées, qu'il faut bien maintenir / faire évoluer
• Le C est souvent ressenti comme le "plus petit ensemble commun" permettant d'interfacer "plus ou moins facilement" différents langages entre eux
• Les indirections rajoutées par les langages plus "haut niveau" ont, malgré tout, un cout tant en terme de taille de l'exécutable, qu'en terme de vitesse ou d'utilisation de la mémoire, qui peut, dans certains cas, être considéré comme inadmissible
• Le fait que C++ et C travaillent, dans toute leur splendeur, à des niveaux d'abstraction différents (très proche du système pour le C, beaucoup plus proche de l'homme pour le C++)

[maxim_um]

Salut koala01,

Je suis d'accord avec toi. Le C est important et a une réalité économique. Je ne le renie pas.

Le problème, c'est pourquoi des gens s'entête à utiliser des fonctions C vieillissantes dans des fichiers portant une extension du style ".cpp". Étant donné la puissance actuelle des systèmes de calcul, on ne peut plus prétendre à plus de performance avec le C.

Le C dans un contexte C++ constitue un vrai talent d'Achille. Alors que le C en contexte C, c’est parfait. Je dis juste qu'il faut faire la part des choses entre ces deux langages et que le C n'est d'aucune utilité dans un projet C++, si ce n'est le développement séparé de modules bas niveau, si le projet en nécessite. Et c'est ce que tu dis d'ailleurs. D'où la notion de spécialité. Je conviens que le terme n'est pas très adapté, mais un moment ou un autre, il faut trancher.

Une des parades à ce genre de quiproquo, serait de bannir la notation « C/C++ » et lui préférer « C et C++ ». Maintenant, à titre personnel et pour ne laisser aucune chance au détracteur du C++ vis-à-vis du C (et d'après ce que j'ai lu koala01, tu ne fais pas partie de cela), j'écrirais plutôt « C et ASM/C++ ».

Voilà, j'espère être assez claire. À aucun moment, je ne critique tel ou tel langage, je dis juste qu'il est temps que certains changes d'attitude. À force de défendre bec et ongles le C et vouloir à tout prix justifier l'injustifiable, je dis que ces gens-là passent à côté de l'essentiel, l'amour de programmer bien, l'amour de développez mieux. Bon, si on enlève amour, ça tient aussi .
Mais si on n’était pas un peu amoureux, on ne serait pas là .

M'enfin, c'était les pensées de maxim_um à minuit quarante.

[JolyLoic]

J'ajouterais un argument en faveur du C : On trouve des compilateurs C (et d'assez bonne qualité) partout, même sur les plateformes les plus exotiques.

[maxim_um]

C'est vrai, c'est une réalité, c'est un état de fait établi. On peut même aller plus loin en parlant d'IDE pour microcontrôleurs, par exemple MPLAB de Microchip, pour n'en citer qu'un de suffisamment grand public et accessible pour aborder la notion de firmware.

Cela dit, dans l'absolu, tu ne fais que confirmer, en bien, ce qui est dit plus haut. Bon, je sais, il y a beaucoup de pages et ce n'est pas évident de tout lire et bien cerner le débat, mais sauf erreur de ma part, la question posée n'était pas C versus C++.

[koala01]

Nous sommes bien d'accord, maxim_um...

Bien que je trouve un intérêt certain au C "pur", je fais partie de ces gens qui insistent réellement pour clairement distinguer C et C++ et qui tendent à "bannir" toute approche (que ce soit lors de l'apprentissage ou lors de la mise en oeuvre "réelle") tendant à mélanger les deux.

[Mac LAK]

Bien que je trouve un intérêt certain au C "pur", je fais partie de ces gens qui insistent réellement pour clairement distinguer C et C++ et qui tendent à "bannir" toute approche (que ce soit lors de l'apprentissage ou lors de la mise en oeuvre "réelle") tendant à mélanger les deux.

Je suis plus mitigé : je trouve un intérêt flagrant aux deux langages "purs", et le pragmatisme m'oblige à toujours tenir compte de l'interpénétration des deux langages de façon quasi-systématique.

En l'occurrence, j'apprends à faire avec et à utiliser "ce qu'il faut" en fonction des besoins. Typiquement, si je trouve une routine à base de "printf/sscanf" qui m'intéresse et donc j'ai besoin, tant pis : je l'utilise dans un code C++ quand même plutôt que de perdre du temps à la convertir en flux. Cela ne pose en général pas de problèmes tant que le code est correctement découpé en modules, chose que 99% des débutants ne savent absolument pas faire.

ET J'INSISTE LOURDEMENT SUR CE POINT : ce n'est PAS une démarche que je conseille aux débutants car c'est souvent des causes de bug très pénibles à trouver. Je suis obligé de le faire pour des raisons de planning / budget, et pour corriger des problèmes. Je tiens à préciser qu'en général, le "fautif" initial se prends un tir direct dans la tête, avec les conséquences classiques si le projet prends du retard à cause de ça.

Il faut clairement distinguer ce que l'on est OBLIGES de faire lors de la maintenance / correction de l'existant avec ce que l'on DOIT faire dans un nouveau projet / module.

[koala01]

Effectivement,

J'aurais voulu faire passer un message à peu près similaire, mais, avec la tournure que prenait mon intervention, je n'arrivais pas à exprimer clairement ce point de vue.

Cependant, tu as tout à fait raison: il arrive que l'on n'ait absolument pas le choix, et, dans ce cas, il faut bien faire "contre mauvaise fortune, bon coeur"

Nous pourrions dire qu'il y a la règle absolue de ne pas mélanger les deux, mais que, comme toute règle trop absolue, les circonstances font parfois qu'il est impossible de s'y plier, et que, dans ce cas, la moins mauvaise solution consiste à y déroger

Mais, insistons encore une fois sur le fait que ni l'apprentissage ni les nouveaux projets ne devraient souffrir de telles dérogations .

[Mac LAK]

Mais, insistons encore une fois sur le fait que ni l'apprentissage ni les nouveaux projets ne devraient souffrir de telles dérogations .

Tout à fait. Cela ne s'applique QUE sur la reprise d'existant, et uniquement de la part d'experts plus que confirmés dans les DEUX langages.

Tout débutant faisant ça, ou tout développeur sur un nouveau projet, doit absolument être mis en quarantaine immédiatement avant de contaminer le reste du troupeau...

[CedricMocquillon]

Je suis entièrement d'accord, le fait de mélanger les deux langages doit être une action mûrement réfléchie en fonction des contraintes présentes; je pense à titre individuel qu'il faut beaucoup d'expérience pour être à même de justifier ce mélange.

Les débutants et jeunes développeurs ne devraient pas tenter de mélanger les deux (si ce n'est lors de l'appel de modules externes: par exemple utiliser/passer des char* à des bibliothèques développées en C). Les "jeunes" qui pensent déjà avoir l'expérience de le faire se plantent quasiment systématiquement.

PS: je m'inclue dans les "jeunes" au sens expérience suffisante dans ces deux langages. A titre personnel, je ne maitrise pas suffisamment le C pour être à même de le mélanger dans mon code C++ (faut dire aussi que j'ai la "chance" professionnellement en tant que développeur C++ de ne pas être confronté à du code C ou C with classes)

[screetch]

je pense que quelqu'un qui n'est pas capable de créer sa propre classe de string est pas un bon candidat pour le C++. de plus, ca commence a me courir sur le haricot que l'on demande a tous les nouveaux qui font un exercice en C++ de prendre les outils deja existant du C++ (vus a la lesson 14 alors qu'ils en sont a la 4)
de plus, pas grand monde ne reconnait ici que la classe std::string est tres mauvaise d'un point de vue conception (beaucoup, beaucoup trop de fonctionnalités)

deja d'une maniere generale on est pas la pour juger le cours de monsieur dushnnock dont un élève arrive ici avec une question. si les string sont vues plus tard, elles sont vues plus tard, point.
de plus, quelqu'un qui utilise des std::string au cours 1 les utilise mal, mal mal mal.


en bref, je crois que les intervenants du forum de maniere generale ne devraient pas considerer que toutes leurs connaissances (reunies) est possédée aussi par l'uytilisateur, et que "utilise std::string" est une réponse souvent merdique a un probleme, principalement parce que "utilise std::string" est un cours entier de "apprendre le C++" et plusieurs cours annexes pour tous les concepts.

c'etait ma "mauvaise humeur" du jour

[Goten]

de plus, pas grand monde ne reconnait ici que la classe std::string est tres mauvaise d'un point de vue conception (beaucoup, beaucoup trop de fonctionnalités)

Si si, hein c'est juste que c'est un fait acquis et qu'on fait avec. Entre une interface surchargée (parce que c'est ça son premier problème) et me taper des const char * de partout perso le choix est vite fait.

Pour le reste... désolé mais je comprends pas là où tu veux en venir. Ce qu'on dit justement c'est que les facilités du C++ tel que std::string, std::vector etc sont à apprendre dès le début, sinon on arrive avec des débutants qui se prennent la tête sur des choses qui ne sont finalement pas les plus importantes a maitriser au début. (pointeur / alloc et tout le toutim).

deja d'une maniere generale on est pas la pour juger le cours de monsieur dushnnock dont un élève arrive ici avec une question. si les string sont vues plus tard, elles sont vues plus tard, point.
de plus, quelqu'un qui utilise des std::string au cours 1 les utilise mal, mal mal mal.

Quand je vois des questions de débutant qui ont commencé par AC++, je suis toujours surpris de la qualité de leur code, et de l'utilisation à bon escient de std::string et de ses méthodes . (si t'as pas lu AC++, sache que le premier chapitre rentre direct dans le vif du sujet avec std::string)

[koala01]

Nous sommes tous conscients que std::string dispose de trop de fonctionnalités.

Nous n'avons d'ailleurs jamais dit qu'il fallait impérativement toutes les passer en revue lors de l'apprentissage du C++: le plus souvent, savoir

• qu'elle est défaut constructible (que l'on peut simplement déclarer std::string machin; )
• qu'elle dispose d'un constructeur prenant une chaine litérale (que l'on peut déclarer std::string machin("hello world") ; )
• Qu'elle est comparable (on peut écrire str1==str2, str1=="hello world", str1<str2, ...)
• qu'elle accepte l'opérateur += comme opérateur de concaténation, tant avec une autre std::string qu'avec une chaine litérale)

suffit (en évitant de faire intervenir la notion de pointeurs induite par sa compatibilité avec les chaines "C style", afin de ne parler des pointeurs que lorsque l'on en a vraiment besoin)

Ce que l'on reproche au cours, ce n'est pas forcément de ne pas voir la classe string, c'est de la voir, dans le meilleur des cas, beaucoup trop tard.

Elle devrait être vue, au moins de manière très sommaire, à peu près au même moment que std::cin ou std::cout, c'est à dire, dés les premiers cours, quitte à être approfondie bien plus tard.

De plus, la raison pour laquelle il m'arrive d'écrire un texte proche de

Tu devrais eng... ton prof, car il ferait bien de vous apprendre directement (std::vector / std::string / autres std::machin )

ce n'est pas seulement parce que je le pense réellement, c'est parce que, s'il n'y a qu'un lecteur sur dix (ou même sur cent) qui ose le faire, et qu'il n'y a qu'un prof sur dix (ou même sur cent) qui prend cette remarque en compte, j'aurai atteint mon but: faire évoluer les mentalités de manière a ce qu'on finisse par apprendre directement "le beau C++", en tant que langage strictement indépendant.

[screetch]

Pour le reste... désolé mais je comprends pas là où tu veux en venir. Ce qu'on dit justement c'est que les facilités du C++ tel que std::string, std::vector etc sont à apprendre dès le début, sinon on arrive avec des débutants qui se prennent la tête sur des choses qui ne sont finalement pas les plus importantes a maitriser au début. (pointeur / alloc et tout le toutim).

ben non c'est pas si simple, pour moi quelqu un qui code en C++ doit savoir faire sa propre classe vector, c'est un cours simple de programmation. c'est aussi un exempe qui montre le RAII, le code exception-safe, le passage par référence, et quelqu un qui ne sait pas faire ca n'a pas toute les armes pour faire ses propres outils (ce qui est la base du C++)
exemple : j'ai beau chercher je ne vois pas de std::quadtree, struture universelle en jeux vidéos.