Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Je ne confond pas. Je ne fais que répondre aux questions posées dans le PO (et accessoirement dans le titre de la discussion).Envoyé par koala01
En plus, il me semble bien avoir écrit "des choses qui à mon sens ne devraient pas être possible".
Peace &
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Mea Culpa...Je ne confond pas. Je ne fais que répondre aux questions posées dans le PO (et accessoirement dans le titre de la discussion).
En plus, il me semble bien avoir écrit "des choses qui à mon sens ne devraient pas être possible".
Je voulais en fait écrire "c'est là qu'il est temps de distinguer clairement ce qui est interdit de ce qui ne devrait à ton sens pas être autorisé".
Car cette distinction est primordiale dans le sens où ce n'est effectivement pas parce que quelque chose n'est, a priori, pas une bonne idée qu'elle ne puisse être considérée, dans certaines circonstances, comme "la moins mauvaise solution"
A méditer: La solution la plus simple est toujours la moins compliquée
Je ne comprends pas bien cette volonté de normer un language. C était un language parfaitement normé au début. C++ est venu mettre le souk mais rien n'empèche de respecter votre norme
Pourquoi diable voulez vous interdire ? Le principe fondateur des langages de cette génération est d'AUTORISER et non pas interdire.
Ensuite un langage comme C est fait pour manager un processeur et non pas un programmeur ! Les langages comme C# consomment du CPU pour faciliter la tache du dev et c'est pourquoi C est plus rapide à l'exécution (les développeurs ARM apprécieront)
Le C n'est pas le langage qui gâche C++ , c'est son ancêtre et à la reflexion , son frère siamois. Le C permet des choses que C++ ne permet pas et ils sont effectivement indissociables. C/C++ est un terme parfaitement recevable.
Enfin, Si vous trouvez le C++ trop brouillon , passez en managé ! dotnet fera la garbage collection à votre place et vous pourrez oublier de libérer les ressources comme en C# ou Java.
Objective-C est le language C système de MAC OS ? en tout cas celui de l'iPhoenet iPad , comme MSC est celui de windows et GCC celui de linux. Ces compilateurs sont basés sur les mêmes préceptes à quelques détails près.
Il ressort de vos messages que vous seriez plus heureux en C# ou en Java qu'en C++ (c'est mon cas sous windows). Pourquoi s'acharner sur un langage qui n'a pas besoin de vous pour exister ? le plus complexe de tous ? Les fameux 5% d'éditeurs américains qui font 80% du CA IT ne parlent pas français et vous diront la même chose ! Ils ont des équipes supérieures à 5 000 développeurs , et vous ? Si vous ne faites pas de QT ni d'iPhone, que Linux vous laisse froids et que vous voulez faire des applis aussi belles qu'en C++ , 3 fois plus vite, 10 fois moins galère à debugger, qui renvoient les messages que vous attendez quand vous les attendez, utilisez le langage qui vous a inspiré ces réflexions (Java, C#) et oubliez C++ qui va blanchir votre teint, vous faire abuser du café et vous rendre irritables ...
Encore une fois , C++ et C sont des standards absolus, mais il y a beaucoup de business dans les autres langages. C++ est réservé aux experts , plutôt célibataires, capables de manger de la pizza froide à 3h du mat et qui s'acharnent 70h par semaine minimum sur leur job.
Quant à la POO, je suggère un entrainement sur les générateurs de visual Studio C# qui donnent une bonne idée du minimum vital en matière d'objet.
Ensuite en réfléchissant , Vous verrez le parti que vous pouvez en tirer.
En ce qui me concerne , je me passe très bien des objets qui sont absents en embarqué (C), je fais exactement la même chose avec que sans ! Mais ce que je ne sais pas faire en procédural , c'est supprimer un mégabyte de variables globales ! En fait c'est impossible, et si l'objet sert à une chose , c'est bien à ça ! Le reste , vos études, votre pays vous l'ont inculqué mais certainement pas les langages qui ne vous forcent pas à faire de l'object maniac , vous vous l'imposez.
Si vous voulez absolument mettre des tonnes d'objets, votre programme aura des problèmes. L'objet permet surtout d'optimiser la mémoire, pour le reste , c'est un peu une histoire de confort mais C++ et le confort, selon moi , ça fait 2
Rien n'empêche de faire un code insipide et pas du tout objet en Java également, ou dans tout langage orienté-objet (un autre bon exemple étant Python, que j'ai vu utilisé bien souvent en faisant fit de tout ses concepts objets).
C'est juste que n'ayant pas le passé du C++ et étant bâti sur une bibliothèque standard fortement orienté objet et très bien documentée, pédagogiquement Java est bien meilleur sur ce point. Vous remarquerez d'ailleurs que vos professeurs de Java sont bien plus enclins à vous faire découvrir de nouveau Design Patterns par exemple, alors que les profs de C++ se bornent en général à vous faire faire de l'algorithmie.
Ce qui à mon goût n'est pas toujours un mal en soit quand on à la chance d'avoir eu des cours dans les deux langages.
C'est effectivement une affaire de choix personnel. Pour ma part, je ne vois aucune raison de faire en C++ ce que je peux faire en C, et inversement ( et généralement, le compilateur C n'est jamais bien loin du compilateur C++). Ma frontière "conceptuelle" entre ces deux langages est assez nette pour savoir de quel coté je me trouve. Le franchissement est quelque chose que je m'interdis dans la mesure du possible (et que j'interdis aux autres, dans la mesure où j'ai mon mot a dire).Mea Culpa...
Je voulais en fait écrire "c'est là qu'il est temps de distinguer clairement ce qui est interdit de ce qui ne devrait à ton sens pas être autorisé".
Car cette distinction est primordiale dans le sens où ce n'est effectivement pas parce que quelque chose n'est, a priori, pas une bonne idée qu'elle ne puisse être considérée, dans certaines circonstances, comme "la moins mauvaise solution"
Appelez ça bonne pratique, ou règle de programmation. Je trouve juste dommage que le langage lui-même ne soit pas plus strict sur ce point. Pour un langage "industriel", je le trouve un peu trop permissif.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Simplement parce que, comme C, il est arrivé un temps où plusieurs sociétés produisaient leur propre compilateur en "tirant dans tous les sens" et souvent de manière non portable.
Nous en arrivions donc à des situations dans lesquelles un code jugé tout à fait correct et valide par un compilateur était totalement incompréhensible par un autre.
Le fait d'écrire une norme pour un langage de programmation permet de s'assurer que, si un code qui respecte cette norme est écrit, il sera compilé de manière similaire par tout compilateur qui la respecte également.
Tu sais, les normes font partie de la vie courante, et pas seulement en informatique
C'est parce qu'il y a des normes que tu peux brancher sans peine n'importe quel appareil électrique dans n'importe quelle prise adéquates
C'était vrai au départ, lorsque C++ s'apparentait beaucoup plus à du "C with classes"Le C n'est pas le langage qui gâche C++ , c'est son ancêtre et à la reflexion , son frère siamois. Le C permet des choses que C++ ne permet pas et ils sont effectivement indissociables. C/C++ est un terme parfaitement recevable.
Actuellement, s'il reste toujours possibles d'utiliser les possibilités issues de C en C++ car C++ ne renie pas ses origines et a inscrit dans sa "constitution" ce souhait de compatibilité, l'approche "moderne" consiste à utiliser en priorité les possibilités propres à C++ et à déconseiller l'utilisation de celles issues de C.
Une grosse part de la justification de cette approche vient de la sécurisation accrue des possibilités propres à C++ et à une utilisation finalement plus facile et plus sereine.
Ainsi faite, ta remarque a quelque chose de très désobligeant...Encore une fois , C++ et C sont des standards absolus, mais il y a beaucoup de business dans les autres langages. C++ est réservé aux experts , plutôt célibataires, capables de manger de la pizza froide à 3h du mat et qui s'acharnent 70h par semaine minimum sur leur job.
Je ne suis surement pas le seul "C++iste" à ne pas me reconnaitre du tout dans cette description
Si au moins tu avais dit que c'étaient des langages plutôt destinés à ceux qui veulent garder le contrôle complet sur ce qu'il font et sur les décisions qu'ils prennent, j'aurais sans doute réagit différemment
Chaque langage défini une politique qui lui est propre et en tire les conclusion qu'elle impose.Quant à la POO, je suggère un entrainement sur les générateurs de visual Studio C# qui donnent une bonne idée du minimum vital en matière d'objet.
Il ne me semble pas opportun de relance un débat (qui existe par ailleurs) C++ Vs C#/java ici, mais le minimum vital que les générateurs pourront proposés risquent, à mon sens, d'être très fortement bridés par la philosophie propre au langage
De plus, j'ai déjà eu l'occasion à maintes reprises de constater que ceux dont l'apprentissage objet était basé sur des langages comme java ou C# n'avaient souvent qu'une approche... trop inspirée par les philosophies respectives de ces langages, et passaient à coté de d'un certain nombre de principes, simplement parce qu'ils étaient difficilement applicables en tant que tels (sans avoir subi une adaptation rendue nécessaire par la philosophie du langage).
Pas forcément...Si vous voulez absolument mettre des tonnes d'objets, votre programme aura des problèmes.
Un projet exclusivement orienté objet ne posera pas forcément plus de problème qu'un projet exclusivement procédural, ni l'inverse d'ailleurs.
Seule l'incompréhension et / ou la mauvaise mise en oeuvre de certains principes risque de poser problème... Mais c'est valable pour n'importe quel paradigme
C'est très réducteur comme approche...L'objet permet surtout d'optimiser la mémoire, pour le reste , c'est un peu une histoire de confort
Mais je ne t'en voudrai pas de préférer rester à la programmation procédurale, si tu te sens plus à l'aise avec ce paradigme
Absolument pas...mais C++ et le confort, selon moi , ça fait 2
Simplement, il te permet de choisir le confort dont tu as besoin et pour lequel tu es d'accord de payer le prix.
Si vim ou emacs te suffisent, libre à toi de les utiliser... mais n'empêche pas les autres de choisir d'autres éditeurs
Soyons clair...
Je tend également à limiter au maximum les points de jonction entre du code C et du code C++, et je me retrouve pleinement dans cette optique d'interdire "autant que faire se peut" les franchissements de frontière.
Cela ne m'empêche par contre pas de constater que ces franchissements sont régulièrement nécessaires, ne serait-ce que par l'utilisation de bibliothèques écrites à l'origine en C, et donc par la nécessité de s'accorder certaines latitudes.
Comme je l'ai déjà dit, c'est malheureusement le prix à payer pour garantir la compatibilité maximale.Appelez ça bonne pratique, ou règle de programmation. Je trouve juste dommage que le langage lui-même ne soit pas plus strict sur ce point. Pour un langage "industriel", je le trouve un peu trop permissif.
Ce n'est pas près de changer, il faut donc "faire avec" et, surtout, cette permissivité est parfois indispensable pour certains projets
Il y a confusion. J'ai écrit mon message avant de lire le tiens et il se trouve qu'il a été placé juste après le tiens, mais il ne t'était pas destiné
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Concernant ce type de casts, ce n'est pas pour rien que les casts à la C++ (static_cast, dynamic_cast, etc.) ont été créés ! Dans le genre « bonne pratique », on est bien loin de la prise de tête.Oui et non. Le C++ génère surement un warning pour ce problème (en fait, j'en sais rien). Mais le C++ génère des warning pour tout un tas de choses qui à mon sens ne devraient pas être possible (c'est a dire interdites par les specs du langage). Par exemple transformer un pointeur sur objet en void*
Cette remarque me rend perplexe. Normaliser un langage permet de rendre compatibles plusieurs implémentations de compilateurs, d'analyseurs de code, d'outils d'assistance à l'ingénierie informatique en général.
On peut même comparer cela à l'un des grands principes de la POO : le principe d'inversion des dépendances. On se rend dépendant d'une interface (la norme) et non d'une classe d'implémentation (un compilateur en particulier).
Totalement faux : avant sa normalisation, on comptait quasiment autant d'implémentations du langage que de plateformes.C était un language parfaitement normé au début.
De quelle façon ?C++ est venu mettre le souk mais rien n'empèche de respecter votre norme
Je partage avec Koala l'idée qu'aujourd'hui, le C++ traine la rétro-compatibilité vers le C plus comme un boulet qu'autre chose.Pourquoi diable voulez vous interdire ? Le principe fondateur des langages de cette génération est d'AUTORISER et non pas interdire.
Pour reprendre mon exemple du début du message, si l'on interdisait l'utilisation des casts à la C (de la forme « (type)variable ») pour imposer l'utilisation des casts à la C++ (static_cast, dynamic_cast, etc., bien plus expressifs sur le type de conversion et transtypage que l'on souhaite autoriser), le langage s'en trouverait amélioré (si l'on oublie les avantages que présentent la rétrocompatibilité vers le C, bien sûr).
Ce type d'interdictions ne bride en rien le contrôle du programmeur sur son code.
D'accord, mais on parle du langage C++, ici, pas du langage C. Une comparaison C vs C# n'a absolument pas lieu d'être.Ensuite un langage comme C est fait pour manager un processeur et non pas un programmeur ! Les langages comme C# consomment du CPU pour faciliter la tache du dev et c'est pourquoi C est plus rapide à l'exécution (les développeurs ARM apprécieront)
Pas d'accord, mais je crois qu'on en a déjà débattu dans un autre topic.Le C n'est pas le langage qui gâche C++ , c'est son ancêtre et à la reflexion , son frère siamois. Le C permet des choses que C++ ne permet pas et ils sont effectivement indissociables. C/C++ est un terme parfaitement recevable.
EDIT : Celui-ci, mais c'était avec une autre personne.
S'il est un langage où la gestion des ressources est à la fois propre, efficace et sans prise de tête, c'est bien le C++. Merci la RAII et les pointeurs intelligents…Enfin, Si vous trouvez le C++ trop brouillon , passez en managé ! dotnet fera la garbage collection à votre place et vous pourrez oublier de libérer les ressources comme en C# ou Java.
Prétendre l'inverse est une méconnaissance flagrante du langage.
Oh que non.Il ressort de vos messages que vous seriez plus heureux en C# ou en Java qu'en C++ (c'est mon cas sous windows).
Complet oui, complexe non. Du moins lorsque l'on sait s'en servir.Pourquoi s'acharner sur un langage qui n'a pas besoin de vous pour exister ? le plus complexe de tous ?
Distinguer les pratiques respectives du C et du C++ est un bon début pour ne pas tomber dans la confusion.
Heureusement que tu es là pour parler en leur nom.Les fameux 5% d'éditeurs américains qui font 80% du CA IT ne parlent pas français et vous diront la même chose !
Quel rapport ?Ils ont des équipes supérieures à 5 000 développeurs , et vous ?
Curieuse remarque là encore…Si vous ne faites pas de QT ni d'iPhone, que Linux vous laisse froids et que vous voulez faire des applis aussi belles qu'en C++ , 3 fois plus vite, 10 fois moins galère à debugger, qui renvoient les messages que vous attendez quand vous les attendez, utilisez le langage qui vous a inspiré ces réflexions (Java, C#) et oubliez C++ qui va blanchir votre teint, vous faire abuser du café et vous rendre irritables ...
Utiliser Qt n'est pas une fin en soi, mais un moyen comme un autre.
Quel rapport avec l'iPhone ? Si tu penses aux applications iPhone, il s'agit d'Objective-C et non de C++.
Quel rapport entre le C++ et Linux ??
Si tu es productif avec Java et C#, grand bien t'en fasse. Pour ma part je le suis en C++ et je deviens irritable surtout lorsqu'on me force à utiliser les langages que tu cites.
Que répondre à une telle ineptie ? Cette affirmation est d'un pathétique…Encore une fois , C++ et C sont des standards absolus, mais il y a beaucoup de business dans les autres langages. C++ est réservé aux experts , plutôt célibataires, capables de manger de la pizza froide à 3h du mat et qui s'acharnent 70h par semaine minimum sur leur job.
Qui a dit le contraire ?Ensuite en réfléchissant , Vous verrez le parti que vous pouvez en tirer.
En ce qui me concerne , je me passe très bien des objets qui sont absents en embarqué (C), je fais exactement la même chose avec que sans ! Mais ce que je ne sais pas faire en procédural , c'est supprimer un mégabyte de variables globales ! En fait c'est impossible, et si l'objet sert à une chose , c'est bien à ça !
J'adhère effectivement à l'idée que coder en objets n'est pas une fin en soi. Le tout-objet de Java me semble hautement impertinent. Mais là encore je ne sais pas trop à qui tu t'adresses…Le reste , vos études, votre pays vous l'ont inculqué mais certainement pas les langages qui ne vous forcent pas à faire de l'object maniac , vous vous l'imposez.
Si vous voulez absolument mettre des tonnes d'objets, votre programme aura des problèmes.
Les goûts et les couleurs…L'objet permet surtout d'optimiser la mémoire, pour le reste , c'est un peu une histoire de confort mais C++ et le confort, selon moi , ça fait 2
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Comme je l'ai précédemment dit le langage D permet de réconcilier tout ce beau monde
Les messages d'erreur sont très pertinent et explicite ce qui n'est pas le cas en C++
On garde la performance du C++ tout en gagnant en productivité.
Chère collègue j'étais spécimiste y a peu par rapport a ce langage, après avoir installé:
- LDC compilateur D (frontend LLVM)
- tango runtime (bibliothèque standard)
j'ai était surpris de la facilité, bien sur comme tout nouveaux langage que l'on apprend faut lire la doc et les exemples, que l'on trouve ici:
- http://www.dsource.org/projects/tango/wiki/
- http://www.dsource.org/projects/tango/docs/stable/
- irc freenode: #ldc #d #d.tango
Sincèrement essayer le, les personnes venant du C++ s'adapte très bien a ce langage car relativement proche.
Il en est de même pour ceux venant de C# et Java
Pour moi l'avantage du D au C++ c'est qu'il ne garde pas la rétrocompatibilité du C en revanche on peut inclure du C de l'asm et bientot du C++
avec le mot clé extern ( ça vous dites quelques choses)
Ce n'est pas une question d'optim.Ça rend la relecture vachement simple, quand on veut savoir à quoi sert une variable en milieu de programme, on remonte au début de la fonction et elle est là (commentée bien entendu
C'est une question d'invariants : il n'y a avec cette façon de procéder, nulle part dans le code un seul endroit où la variable aura un état qui ne rime à rien (i.e. non initialisé). Si c'est ça que tu appelles propreté, alors oui j'en veux.
Et le code est trop dur à lire ? Tu as alors deux problèmes :
- fonctions trop longues (on ne le répète jamais assez)
- mauvais outil de développement (vu qu'il ne propose pas de moyens de sauter directement à l'endroit de la déclaration de la variable, ni de moyens pour mettre en couleur toutes ses occurrences)
@adeptes du D: j'attends que le langage s'étoffe en bibliothèques avant de pouvoir le considérer pour faire du développement pro. Je ne doute pas un seul instant qu'il puisse me plaire.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Et quel est le rapport avec la discussion actuelle
S'il s'agit d'attirer les intervenants vers une discussion dans laquelle on parle des mérites comparés de D et de C++, il est préférable de créer une autre discussion (quoi que celle-ci pourrait faire l'affaire
Si l'idée est de mettre en concurrence C++ avec les autres langages, d'autres débats sont déjà ouverts par ailleurs: N'hésite pas à visiter la section débats du forum.
Ici, il est plutôt question de permettre aux gens qui le souhaitent d'indiquer ce qui, à leurs yeux, ne va pas "comme il faut" en C++...
Cool !! je sais que le topic est que reprocher à C++ mais franchement les objects maniac ont besoin d'autre chose . D me semble très pertinentsComme je l'ai précédemment dit le langage D permet de réconcilier tout ce beau monde
Les messages d'erreur sont très pertinent et explicite ce qui n'est pas le cas en C++
On garde la performance du C++ tout en gagnant en productivité.
Chère collègue j'étais spécimiste y a peu par rapport a ce langage, après avoir installé:
- LDC compilateur D (frontend LLVM)
- tango runtime (bibliothèque standard)
j'ai était surpris de la facilité, bien sur comme tout nouveaux langage que l'on apprend faut lire la doc et les exemples, que l'on trouve ici:
- http://www.dsource.org/projects/tango/wiki/
- http://www.dsource.org/projects/tango/docs/stable/
- irc freenode: #ldc #d #d.tango
Sincèrement essayer le, les personnes venant du C++ s'adapte très bien a ce langage car relativement proche.
Il en est de même pour ceux venant de C# et Java
Pour moi l'avantage du D au C++ c'est qu'il ne garde pas la rétrocompatibilité du C en revanche on peut inclure du C de l'asm et bientot du C++
avec le mot clé extern ( ça vous dites quelques choses
Au fait , j'ai une certification ISO 9001 à mon nom ce qui me donne le droit de travailler avec toutes les sociétés certifiées ISO 9001 aussi
Les vraies normes , s'interdisent d'imposer quoique ce soit excepté une clarté dans le communication et une transparence de méthodologie
J'ai aussi une certif EDI mais c'est comme toutes les normes mondiales , elle se ressemblent toutes, une fois que tu en as une.....
vous etes trop object maniacs pour moi. Si vous postulez chez moi un jour, il faudra surveiller ça...
PseudoCode : okay la pizza n'est pas obligatoire : tu peux préférer le chocolat chaudpar contre je suis célibataire et il m'arrive de faire 90h/semaine
Aurais tu une réalisation visible ? une spec ou des copies d'écran d'un projet dont tu t'es occupé ?
Es tu mathématiques ou itératif ?
Un résumé ? même si ce n'est qu'un concept , ça m'intéresse ici ou en MP
Dernière modification par Invité ; 20/07/2010 à 19h58.
Bien parléIci, il est plutôt question de permettre aux gens qui le souhaitent d'indiquer ce qui, à leurs yeux, ne va pas "comme il faut" en C++...
Pour en revenir au sujet initial, voici un défaut du C++ qui m'a un peu gêné il y a quelques temps :
J'ai eu besoin, dans un projet, de déclarer un ensemble de deux-cents types distincts. Tous ces types étant très similaires, il s'agit en fait de typedefs d'instances de templates (il n'y a que 5 templates de classe à la base, donc le code ne compte aucune redondance).
Le problème, c'est que ces deux-cent types sont pour la plupart dépendants les uns des autres. Le diagramme de dépendances est un vrai sac de nœud ! Des dépendances cycliques à la pelle…
Lorsque deux classes (A et B) sont dépendantes l'une de l'autre, c'est pas bien compliqué : une déclaration anticipée de B avant la définition de A et c'est réglé.
A.hpp
B.hpp
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12#ifndef A_HPP #define A_HPP class B; class A { //… B* b; }; #endif
A.cpp
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12#ifndef B_HPP #define B_HPP #include "A.hpp" class B { //… A a; }; #endif
B.cpp
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7#include "A.hpp" #include "B.hpp" A::A() { //… };
Le hic, c'est qu'il est impossible de faire une déclaration anticipée d'un typedef. Du coup, j'ai été obligé d'utiliser l'idiome pimpl pour résoudre les dépendances cycliques. Heureusement, le préprocesseur m'a permis d'éliminer toute redondance dans le code, mais c'est quand même beaucoup d'efforts pour résoudre quelque chose qui ne fait pas partie de la problématique principale du projet.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7#include "B.hpp" #include "A.hpp" B::B() { //… };
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
En c++, je ne fais pratiquement que de la programmation orientée objet, et j'ai justement découvert à quel point il était le langage idéal.
La question c'est "a-t-on vraiment besoin de garantir la compatibilité ad vitam eternam ?". Je pense que la période de transition C / C++ (only) a été assez longue.Comme je l'ai déjà dit, c'est malheureusement le prix à payer pour garantir la compatibilité maximale.
Ce n'est pas près de changer, il faut donc "faire avec" et, surtout, cette permissivité est parfois indispensable pour certains projets
Pour moi, il est temps soit de mettre en désuétude certaines pratiques du mixing C/C++, soit au contraire d' "objectifier" la pratique du C à l'intérieur du C++.
Je finis par me demander si l'apparente complexité du C++ est liée à sa puissance ou si elle est "le prix a payer" pour garantir la compatibilité.
C'est pas moi qui ai parlé de pizza. Y a erreur sur la personne je pense.PseudoCode : okay la pizza n'est pas obligatoire : tu peux préférer le chocolat chaud
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Je rêverais que les membres du comité tirent les mêmes conclusions !La question c'est "a-t-on vraiment besoin de garantir la compatibilité ad vitam eternam ?". Je pense que la période de transition C / C++ (only) a été assez longue.
Je rêverais que les rétrocompatibilités provenant du C (le typage faible des types primitifs, NULL, les casts à la C et j'en passe) soient mises à la trappe et que l'utilisation de code C ou legacy doive être explicitée à coups de « extern "C" » ou encore « extern "C++98" ».
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Je ne suis pas sur qu'il faille parler de "transition".La question c'est "a-t-on vraiment besoin de garantir la compatibilité ad vitam eternam ?". Je pense que la période de transition C / C++ (only) a été assez longue.
Après tout, la compatibilité va plus loin que le simple fait de permettre l'utilisation de bibliothèques externes qui pourraient, à moindre frais, être "bindées" en C++
Il s'agit, ni plus ni moins, de permettre l'interfaçage de projet volumineux écrits en C avec un langage plus "haut niveau".
Et tant que des développements se feront en C, le besoin d'interfaçage restera présent
Pour moi, il est temps soit de mettre en désuétude certaines pratiques du mixing C/C++, soit au contraire d' "objectifier" la pratique du C à l'intérieur du C++.L'apparente complexité de C++ est, à mon sens, beaucoup plus due au fait que c'est un langage multi paradigme qu'à ce qui garanti la compatibilité avec C:Je finis par me demander si l'apparente complexité du C++ est liée à sa puissance ou si elle est "le prix a payer" pour garantir la compatibilité.
Le se fait de pouvoir décider de travailler selon trois paradigmes distincts, alors que d'autres langages ne donnent pas cette possibilité de choix, suffit déjà à provoquer une certaine complexité.
Et ca, c'est le prix à payer pour pouvoir apporter des solutions plus particulières à des problèmes particuliers
Je considère en effet, à l'instar de nombreux C++istes, que l'orienté objet ne résout pas tous les problèmes, et qu'une approche multi paradigme permet facilement de contourner les problèmes propres à chacun d'eux.
pour répondre a koala01, la langage D est multi paradigme un peu plus que le C++ notamment par l'intégration native des delegate et plein d'autres choses et il est pourtant moins complexe.
Pour moi ayant travailler pas mal en C++ un de ses grand défaut sont les messages d'erreur et ceux avec n'importe quelle compilateur c++. A force on s'y fait et on voit ou est le problème, cela reste un gros soucis.
Je penses, au contraire, que c'est avec des raisonnements si définitifs que tu risques de te trouver assez rapidement dépassé par l'évolution.
Comprenons nous bien: le paradigme orienté objet présente un grand nombre d'avantages, nous sommes tous d'accord là dessus.
Mais il présente également un certain nombre de faiblesses qui, comme c'est étrange, peuvent être contournées grâce aux paradigmes procédural et générique.
C++ a l'énorme avantage d'intégrer parfaitement ces trois paradigmes, alors, mélange les, enlace les jusqu'à plus soif. Cela t'ouvrira des perspectives que tu ne pourrais imaginer en restant bloqué sur l'orienté objet
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager