Je suis grosso modo d’accord avec toi. J’aime vraiment beaucoup le C (même si ça vaut pas le C++), mais dire que le C est un langage simple d’utilisation c’est faux.
C’est un langage simple dans le sens qu’il est basique. Comme tu dis il y a 3 concepts qui se courent après et basta. C’est un pur langage KISS justement pour ça une fois que tu as compris le principe il n’y a rien qui viens te perturber. Mais ça n’en fait pas un langage simple. La désallocation mémoire (et la gestion d’une manière générale) peut être un véritable casse tête (lance valgrind sur la plus par des appli en C tu verras), les macros sont une infamie qu’il faut utiliser le moins possible (ou du moins savoir quand l’utiliser et quand ne pas l’utiliser) et surtout faire bien gaffe à la structuration des programmes (tu remarqueras que la plupart des projets en C qui veulent se structurer vont se rapprocher d’un modèle objet hors ce n’est vraiment pas fait pour ça (et surtout autant utiliser le C++ voir l’objective-c ou n’importe quel langage objet), le noyau linux est dans ce cas.
En effet, je me suis mal exprimé, je voulais dire simple dans le sens “KISS”.
Je vais éviter le débat C >< C++, d’une part parce que je n’ai pas de connaissances suffisantes en C++, d’autre part parce que ce débat est sans fin. Cependant écrit comme cela on a l’impression que tu dis que le C++ est meilleur que le C. A mes yeux c’est faux, les deux langages permettent de faire autant de choses , ils fournissent juste des outils et des méthodes différentes afin de les réaliser.
Je suis d’accord avec toi, ce sont en effet des problèmes récurrent en C, néanmoins je me permet de tempéré quelques points :
Les macros sont des outils très efficaces qui peuvent s’avérer gênant, notamment pour le debugages, mais de là à dire qu’il s’agit d’une infamie c’est peut-être allez un peu loin
Concernant les problèmes de gestion de la mémoire, les autres langages ne sont pas dépourvus de ce genre de problèmes, le C++ par exemple. Il a bon disposer de classes comme vector, string ou encore de pointeurs “intelligents” cela n’empêche pas la levée et le traitement de certaines exceptions, qui peuvent parfois s’avérées complexes.
De manière générale, on a bon programmer dans n’importe quel langage on doit être structuré. Maintenant c’est vrai que le besoin s’en ressent d’avantage en C ou dans d’autres langages qui ont tendances à être fort “verbeux”.
Mais disons que si l’on veut disposer d’un code structuré, modulable et facilement maintenable il est préférable de se rapprocher de la méthode OO(enfin, cela dépend des projets). Maintenant il ne faut pas perdre de vue que la programmation OO n’est qu’une façon d’abordé un problème, on peut tout à fait l’appliquer en C.
De manière raisonnable cela donne de la programmation modulaire où un fichier correspond à un module indépendant des autres contenant ses propres fonctions et structures. Je trouve cette solution plaisante et bien adaptée au C.
Si par contre on a besoin d’aller plus loin, je suis d’accord avec toi, il faut changer de langage. Il est inutile de jouer à l’apprentit sorcier avec des macros et autres méthodes tordues pour essayer de pousser les limites du langage.
Je vais forker le sujet à fin de ne pas perturber le fil.
[quote=“Taurre”][quote=“MisterFreez”]
(même si ça vaut pas le C++)
[/quote]
Je vais éviter le débat C >< C++, d’une part parce que je n’ai pas de connaissances suffisantes en C++, d’autre part parce que ce débat est sans fin. Cependant écrit comme cela on a l’impression que tu dis que le C++ est meilleur que le C. A mes yeux c’est faux, les deux langages permettent de faire autant de choses , ils fournissent juste des outils et des méthodes différentes afin de les réaliser.[/quote]
Tu as retiré ma parenthèse du contexte je parlais de mon opinion.
Le problème de typage dans les macro, la pseudo génération de code qu’on peut faire avec, … c’est le genre de truc qui les rendent juste indebugable (Généralement on demande à gcc de sortir le code juste après le passage du préprocesseur).
Les destructeurs c’est magique pour la désallocation et ça simplifie souvent le travail. Ça n’est pas exempte de problème mais je trouve tout de même que ça apporte de gros avantages sans impacter les performances.
Je sais pas si le mot verbeux est le bon, mais oui la structuration est importante et bien plus encore une vrai étape de conception ça change la vie et ça permet de faire les choses proprement.
[quote=“Taurre”][quote=“MisterFreez”](tu remarqueras que la plupart des projets en C qui veulent se structurer vont se rapprocher d’un modèle objet hors ce n’est vraiment pas fait pour ça (et surtout autant utiliser le C++ voir l’objective-c ou n’importe quel langage objet), le noyau linux est dans ce cas.
[/quote]
Mais disons que si l’on veut disposer d’un code structuré, modulable et facilement maintenable il est préférable de se rapprocher de la méthode OO(enfin, cela dépend des projets). Maintenant il ne faut pas perdre de vue que la programmation OO n’est qu’une façon d’abordé un problème, on peut tout à fait l’appliquer en C.
De manière raisonnable cela donne de la programmation modulaire où un fichier correspond à un module indépendant des autres contenant ses propres fonctions et structures. Je trouve cette solution plaisante et bien adaptée au C.
Si par contre on a besoin d’aller plus loin, je suis d’accord avec toi, il faut changer de langage. Il est inutile de jouer à l’apprentit sorcier avec des macros et autres méthodes tordues pour essayer de pousser les limites du langage.[/quote]
Personnellement je pense que le multiparadigme peut vraiment être une très bonne solution. Ça permet de faire de l’orienté objet pour la structuration et du fonctionnel pour les algorithmes.
Ce n’était peut être pas nécessaire, je pense avoir fait le tour de ce que je voulais dire
En effet, c’est un mécanisme intéressant qui évite pas mal de soucis, mais je me demande juste si l’on connait l’ordre dans lequel les destructeurs des différents objets seront appelés ?
En ce qui me concerne je n’ai jamais ressenti le besoin de programmer avec un langage OO, sans doute parce que je n’ai jamais réalisé de projet conséquent, mais c’est vrai que le fait de disposer du choix impératif >< OO est un bon atout.
