le future de C++

Question

Salut les gars,
Bon, en tant qu'ancien programmeur C++, je trouve ce langage vraiment manifique.
Par contre, il n'est pas super productif, plus facile de mal gerer la mémoire avec (en oubliant de détruire les objects), relativement difficile à prendre en main, et pour faire des applications windows, MFC, c'est vraiment nul...
La mode aujourd'hui est aux languages avec un runtime (Java, C#, ...) et un framework défini.
Pire encore, dans le prochain Vista, ils vont introduire des nouveautés et SEULEMENT les programmeurs .net vont pouvoir DIRECTEMENT (sans COM et compagnie) en profiter.

Alors, dans cette perspective, comment vous vous sentez?
Allez-vous migrer vers .net ou rester sur C++? Quelles sont vos raisons?

On serait bientot rendu au moment ou les programmeurs .net peuvent faire des trucs que vous ne pouvez pas faire.

P.S. : mon but n'est pas de débuter un débat inutile mais d'avoir votre opinion sur le future de C++.
P.S. : J'ai omis de parler du managed C++ parce que je le connais pas trop.

[:D] @++

nightlord666 · Answer

Ben toute facon je pense que des programmeurs intelligents vont vite sortir quelques librairies pour utiliser ces fonctions de Vista avec COM, et ça sera encore plus rapide que le .NET en vitesse d'éxécution.

Moi, je ne vois aucune raison de passer au .NET tant que je n'y voit pas de vrais avantages. Pour le moment, je ne vois que des inconvénients (vitesse d'éxécution, moins de controle du code, compatible uniquement Windows, dépendance à Microsoft)... 

Le jour ou Microsoft décidera de passer le Framework .NET payant (si ça arrive), et ben les programmeurs .NET l'auront dans le ***...

//Libère ma mémoire que j'ai utilisé
this->GetCurrentConversation()->FreeAllocatedMemory(REASON_UNUSED);

SAKingdom · Answer

Le .NET au C++ est comme une F1 auquelle on aurait attaché un 747. Le .NET n'apporte rien de vraiment indispensable. Comme dit nightlord, vitesse d'execution réduite, dépendence à Windows, code non portable. J'ai entendue parler de Vista et .NET. Si tu veux savoir ce que je pense, alors voilà. À partir du moment ou Vista sera devenue un OS inévitable et que tout les logiciels compatible avec Windows ne fonctionne qu'avec Vista et bien, je me convertie complètement à Linux. Pas question de faire seulement du .NET et d'attacher un boulet de 3 tonnes à mes programmes.

Ceci dit, ce genre de question trouverait très bien sa place sur Le Bar et non sur le forum de cppfrance. Fait attention la prochaine fois ;)

C++ (@++)
___________________________________________
Les plus grands esprits trouvent toujours une solution

http://programmationdebat.discutforum.com

nightlord666 · Answer

Au niveau du classement dans le forum, je le trouve adapté içi, car ça ne concerne que les utilisateurs C++, et le bar est un espace multi-sites.

//Libère ma mémoire que j'ai utilisé
this->GetCurrentConversation()->FreeAllocatedMemory(REASON_UNUSED);

MorbhAck · Answer

NAN NAN NAN !!!!!!!!        PAS LE .NET !!!!!!!!!!!!!!!!!!!!!
N**** LE .NET !!!!!!!!!!
le .NET moi je dit sa sent movais !
Moi chui pret a faire une manif si il le faut ! 

[auteurdetail.aspx?ID=617077 SAKingdom] TA TOTALEMENT RAISON !!!

nightlord666 · Answer

"La mode aujourd'hui est aux languages avec un runtime (Java, C#, ...) et un framework défini."
>> La STL n'est-elle pas un peu le "framework" du C++ ?

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

steve_clamage · Answer

La STL (ou ex-STL) est un sous-ensemble de la bibliothèque standard
(depuis qu'elle à été normalisée) mais on peut dire que la bibliothèque
standard joue ce rôle. Seulement la bibliothèque standard du C++ est
assez abstraite (flux, conteneurs et algos génériques) et peu complete
(d'ou l'inclusion de la bibliothèque C). Par exemple on ne peut pas
faire d'interface graphique en C++, ou du son, de la video, gérer des
entrées autrement que par un flux. Les principales raisons de ces
limitations c'est d'abord que le C++ est encore en pleine évolution,
écrire un module pour la bibliothèque standard et trés long, et doit
etre décidé par le commité C++. L'autre grande raison c'est le souci
d'avoir un langage le plus portable possible à l'image du C et pour ca
il faut etre sur que chaque ajout à la bibliothèque standard ne posera
pas de probleme d'implémentation. La bibliothèque boost présente une
évolution possible de la bibliothèque standard, certains modules sont
trés pratique, portables et 100% compatibles avec l'actuelle
bibliothèque standard. Ils feront partis des ajouts pour le prochain
standard (c++0x). Il me semble que l'intégration d'une bibliothèque gui
est en projet, mais le travail s'annonce conséquent, ce ne sera sans
doute pas pour le prochain standard.

nightlord666 · Answer

Le problème est en fait que l'interface graphique est dépendante de l'OS, c'est pour ça qu'il faut utiliser l'API fournie par le système d'exploitation. Le mieux serait d'inclure une librairie comme GTK dans la bibliothèque standard du C, ce qui permettrait d'avoir un outil pour faire les interfaces utilisateur.

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

steve_clamage · Answer

"
                
                Le problème est en fait que l'interface graphique est dépendante de l'OS"


On peut même dire tout. Par exemple la lecture/écriture de fichier
dépend de l'OS (CreateFile sous Windows, open  sous UNIX, ...)
mais avec la bibliothèque standard ca se fait indépendamment de l'OS
avec fstream.


"Le mieux serait d'inclure une librairie comme GTK dans la bibliothèque standard du C"


C'est l'idée, enfin pas pour le C mais pour le C++.Seulement une telle
bibliothèque n'existe pas, c'est pour ca que ca risque de prendre du
temps.

nightlord666 · Answer

En fait si j'ai bien compris l'architecture d'un système est comme ça : (pardonnez la qualité du schéma)

Corrigez moi si c'est pas ça.

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

BruNews · Answer

C'est carrément une utopie, un OS évolue et ne fournit pas forcément les mêmes services qu'un autre.


Les biblis de surcouche seraient toujours en réécriture.

ciao...
BruNews, MVP VC++

nightlord666 · Answer

Je pense que c'est possible (Java le fait bien), mais il faudrait faire une sorte de OSAL (OS Abstraction Layer), qui permettrait d'émuler des fonctions d'un OS.

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

steve_clamage · Answer

Il n'y a pas d'utopie, c'est ce qui ce fait. C'est moins couteux de
réécrire l'implémenation de la couche la plus basse et de conserver la
même interface plutot que de réécrire toutes les applications.

vecchio56 · Answer

De toutes facons il n'y a pas de miracle; il me semble évident qu'il langage devant fonctionner sous plusieurs OS ne bénéficiera que des services disponibles sur tous les systèmes, et au final c'est au détriment de la qualité du logiciel. S'il faut utiliser une couche d'abstraction ce n'est pas satisfaisant, car on ne veut pas de ca quand on code en C++.

_____________________________________
Un éditeur de ressources gratuit pour Windows

cs_badrbadr · Answer

535688 
nightlord666 a dit :


Moi, je ne vois aucune raison de passer au .NET tant que je n'y voit pas de vrais avantages. Pour le moment, je ne vois que des inconvénients (vitesse d'éxécution, moins de controle du code, compatible uniquement Windows, dépendance à Microsoft)...

Premièrement, le C++ est à peine plus rapide que le code executé par le CLR dans certains cas et cela ne fait aucune différence pour une grande majorité d'applications. Et en passant, l'assembleur et le C, ne sont-ils pas plus rapide que le C++?
Pour le controle du code, le C# (et d'autres languages .net) n'est pas un nouveau VB. On a un controle quasi-complet sur ce qu'on veut faire avec la possiblité d'utiliser directement l'api Win32.
Pour la compatibilité avec Windows, j'y vois personnellement un avantage. Cette plateforme est optimisé pour Windows. Il y'a toujours le projet Mono et Platform.net qui ont développer un runtime pour Linux.
nightlord666 a dit :
Le jour ou Microsoft décidera de passer le Framework .NET payant (si ça arrive), et ben les programmeurs .NET l'auront dans le ***...
Et le jour que Microsoft décidera de passer le SDK de l'api Win32 payant, vous serez pas dans la ***de? Soyons raisonable, cela ne se produirait jamais !!! 
=617077 SAKingdom a dit:
Pas question de faire seulement du .NET et d'attacher un boulet de 3 tonnes à mes programmes.

La plateforme en soit n'est vraiment pas lourde. Elle est super rapide, ben plus rapide que Java et ne cesserait dans le future d'etre davantage rapide puisqu'elle serait integrée au coeur de l'os et continuellement optimisé.
___________________________________
Bon, pour conclure, je vous demande d'être plus ouvert.
Les programmeurs C++ sont généralement très habile et il vous faudra moins d'une semaine pour apprendre le C#. Sa syntaxe, sa clareté, la gratuité de son IDE (et son intellisense) vont rapidement vous séduire.
En plus, toute la structure de palteforme .net est un délice pour les curieux d'entre vous. Tellement sophistiqué et si simple à utiliser !!!
Et finalement, n'oublier pas que ce language est le produit d'une synthèse parfaite de plusieurs autres languages (C++, Java, ...). On a repris leurs forces et ignorer leurs défauts.

SAKingdom · Answer

Tu voulais avoir notre opinion. C'est ce que l'on a fais. Je continue toujours à croire que le .NET ne fait que diminuer la flexibilité, la vitesse et la portabilité d'un code. D'accord, il est plus "simple" de faire du .NET car tout est regroupé mais les inconvenient sont encores trop importants. D'ailleurs, je ne vois pas l'utilité du .NET en C++. Je reprend un bout de phrase que le professeur Tanenbaum à envoyer à Linus Torvalds: "C'est comme prendre un programme écrit en langage C et qui fonctionne, et le réécrire en Basic". Voilà comment j'interprette le .NET dans le C++.

Je conclus en disant: à chacun son opinion sur le .NET. Moi je trouve que c'est un boulet. Personne ne me fera changer d'idée. Si vous aimez le .NET, je ne vous juge pas. C'est votre choix et je ne critiquerai jamais quelqu'un qui a fait son programme en C++ .NET plutôt qu'en C++. Ce que je pense ne concerne que moi et ceux qui sont en accord.

C++ (@++)
___________________________________________
Les plus grands esprits trouvent toujours une solution

http://programmationdebat.discutforum.com

MorbhAck · Answer

Moi aussi, pour moi le .NET il est carré au fond de mon C*** et il le resteras jusqu'a que je crève !

racpp · Answer

Salut,
badrbadr >> Pour la gratuité de l'IDE (et l'intellisence) avec  C/C++, il y'a Visual C/C++ 2005 Express. Ce n'est pas la syntaxe facile d'un laguage qui séduit mais plutôt le résultat final. J'ai vu des codes C# utilisant des APIs. Ils doivent déclarer  toutes les APIs avec leurs DLLs dans le code avant de pouvoir les utiliser. C'est comme en VB. Vous appelez ça syntaxe facile? Et je me demande si l'EXE final sera vraiment autonome.
La politique de Microsoft est actuellement d'essayer d'imposer le .Net pour concurencer JAVA. Le principe est le même. Donc pour les performances, ce n'est pa la meilleure solution. Tous les trucs qu'on peut faire avec .Net on peut les faire avec C/C++, et en mieux. C'est vrai que c'est moins facile. L'utilisation des interfaces COM ne doit pas faire peur. Tout est question d'habitude.
Chacun choisit le langage qui lui convient selon ses priorités.

cs_badrbadr · Answer

Lol
C'est drole comment les mentalités sont différentes d'un site à l'autre dans le réseau CodeS-SourceS.
Sur CppFrance, PhpCs, JavaFr, l'attitude est très OpenSource et la portabilité est une valeur qui vous tient à coeur. C'est une philosophie très développer.
Par contre, sur des sites dans le genre CSharpFr, AspFr, ils sont très Microsoftien et très professionel. La pensée rationnel est de rigueur : productivité et cout sont des règles d'or.
En revenant ici, je me suis heurté à cette différence de culture.

[:D] @++

SAKingdom · Answer

La portabilité est un facteur. Un des avantages du C/C++ est ça capacité à générer des codes petit et rapide. Il ne faut pas négliger la taille et la rapidité d'execution d'un logiciel peut importe son langage. Le problème avec le C++.NET c'est qu'il attache un Framework au programme qui pourrait être très facilement évité (en C/C++). Passer par un Framework sera toujours plus lent que d'apeller le système directement et ça, tout professionnel te le dira. Le C a d'abords été fait pour faire des systèmes d'exploitations mais pas pour devenir un langage interprété et, tu sera probablement d'accord avec moi, un programme dépendent d'un RunTime ou un Framework (codé avec un langage interprété) sera toujours plus lent qu'un code natif. Ok faire un code en .NET est plus rapide mais au grand sacrifice des performences du produit final et ça c'est désolent. Voilà. J'espère que vous allez comprendre mon point de vue.

C++ (@++)
___________________________________________
Les plus grands esprits trouvent toujours une solution

http://programmationdebat.discutforum.com

BruNews · Answer

"très professionnels" sur les sites d'interprété, hé hé là je rigole un max !!!
Il y a un bout de temps que j'y passe quasi chaque jour pour voir si tout va bien, ben j'en sors édifié par les propos tenus. A part qlqs uns, quasi personne ne sait ce qui se passe en mémoire ni autre chose, c'est le domaine de l'ignorance complète de l'informatique. Rien de vraiment surprenant ni choquant vu que ces pseudos langages sont faits pour de la production en masse d'applets par des non informaticiens mais il faut tout de même appeler un chat un chat.

monLaïus.finiched = True
ah oui que je me sens pro...

ciao...
BruNews, MVP VC++

racpp · Answer

Personnelement, la portabilité n'a jamais été une priorité pour moi. J'ai choisi le système le plus répandu dans le monde : Windows. 
Penser à la productivité c'est bien, mais pas au prix de la qualité de la production. Avec VB la productivité est inégalable mais souvent les résultats ne sont pas satisfaisants. Les meilleurs logiciels sont faits en C/C++. Ca a commencé depuis l'apparition de ce langage et ça continue toujours et continuera encore très longtemps.
Un jour Microsoft décidera de remplacer .NET par une autre technologie. Ce sera une catastrophe pour les .NETtistes. Alors qu'avec C/C++ on est tranquille. Par rapport au autres langages, le C/C++ est le seul (avec l'assembleur) avec lequel on peut tout faire en programmation. Même les futures fonctionnalités de Vista, on saura les utiliser.

BruNews · Answer

racpp rappelle ce qui est évident et va normalement sans dire, mais ça va aussi bien en le disant.

ciao...
BruNews, MVP VC++

cs_badrbadr · Answer

Y a pas de grands sacrifices de performances. À peine je te dis! Je me rappelle d'avoir lu que le C++ était 10% plus rapide en comparaison avec .net 1.1.
Et puis maintenant que j'y pense, la question devrait etre Quelle est l'avenir du C++ sur Windows en tant que language de conception d'applications Windows?
Parce que je suis convaincu que le C++ est là pour rester mais, sur Windows, il deviendrait moins utiliser pour la conception d'application Windows!
___________________________________________
racpp a dit:
J'ai vu des codes C# utilisant des APIs. Ils doivent déclarer  toutes les APIs avec leurs DLLs dans le code avant de pouvoir les utiliser. C'est comme en VB. Vous appelez ça syntaxe facile? Et je me demande si l'EXE final sera vraiment autonome.
Tu me sors un cas spécial qu'on n'utilise pas souvent : celui de l'utilisation de l'attribut DllImport pour faire des appels de fonctions. Je te parle de la syntaxe générale.
En C# (et autres languages .net), on n'utilise plus les pointeurs. On n'a des namespaces et non des includes. Le code est safe et la gestion de mémoire est automatisée avec un collecteur de poubelle optimisé. Le débogage est plus simple qu'en C++ (malheur si vous travaillez avec des objets com). L'intellisence est plus efficace pour les languages .net et accélère le développement. On utilise des énumérations et non des #define. Les variables sont plus lisibles (pas de DWORD, pas de D3DRS_CULLMODE) et de syntaxe dégueux. ....et j'en passe!!!
C'est de ça que je parlais.

[:D] @++

racpp · Answer

Tout à fait d'accord avec toi Brunews, ce sont des langages faits pour les non-informaticiens.

cs_badrbadr · Answer

Vous, vous êtes des durs de durs, je vous l'accorde. La programmation que vous faites est de loin plus complexe et nécissite plus d'habileté.
Et alors, y a quoi de mal à se simplifier la vie?
Et t'as raison BruNews, quand j'ai dit que c'était professionel, c'est justement pour la production en masse! (professionel ne veut pas dire super bon mais simplement lorsque c'est un métier - profession)

[:D] @++

racpp · Answer

badrbadr >> L'utilisation des pointeurs est l'un des points forts du C/C++. Leur manipulation est certes délicate pour les non habitués mais le gain en performance est énorme. J'utilise souvent les objets COM. Aucun problème pendant le débogage. Tout se passe toujours comme prévu.

vecchio56 · Answer

Ah ben tu as de la chance :) Moi je commence un peu a toucher aux objets COM, et rien ne se passe comme prévu.
Pour ce qui est de débat, 100% d'accord avec racpp. Le C++ a été mon premier langage et depuis j'en n'ai jamais trouvé un qui me puisse autant me satisfaire

_____________________________________
Un éditeur de ressources gratuit pour Windows

SAKingdom · Answer

badrbadr>>Il n'y a pas de mal à se simplifier la vie. Mais il faut que tu soi concien des inconvénients. Tu peux toujours programmer en C# même si d'ordinaire tu programmes en C++. Ce que BruNews veux dire c'est que les programmeurs programment uniquement en langages interprété ne savent pas ce qui ce passe dans la machine. Si une érreure relative à la mémoire survien, ils sont fichuent car ils ne connaisent pas comment fonctionne la mémoire. En C/C++, on ce doit de le savoir sinon, c'est le plantage assuré. C'est probablement ça que BruNews à voulu dire par non informaticiens. Le fait qu'il ne connaisse pas la machine sur laquelle ils sont entraint de faire un programme.

De plus la syntaxe en C/C++ n'est pas dégueulasse et est parfaitement compréhensible quand on connait bien le langage. Le débuggage y est aussi très performent et permet même de regarder le code agir directement en mémoire. Rien de mieu pour comprendre ce qui ne fonctionne pas quand des problème surviennent.

C++ (@++)
___________________________________________
Les plus grands esprits trouvent toujours une solution

http://programmationdebat.discutforum.com

nightlord666 · Answer

"En C# (et autres languages .net), on n'utilise plus les pointeurs. On
n'a des namespaces et non des includes. Le code est safe et la gestion
de mémoire est automatisée avec un collecteur de poubelle optimisé."
>> C'est justement le fait que toute la gestion de mémoire soit automatisée qui rend le C# ou les autres langages lents. Les pointeurs est surement l'outil le plus pratique et rapide fournit par C/C++, et tu es pour le fait qu'ils ne soient plus utilisables en C#...

"Les variables sont plus lisibles (pas de DWORD, pas de D3DRS_CULLMODE) et de syntaxe dégueux. ....et j'en passe!!!"
>> Si tu trouves que DWORD n'est pas lisibles, c'est vraiment que tu devrais réviser ton informatique... DWORD, comme son nom l'indique, est un double-word codé sur 4 octets, donc le typedef d'un int/long. D3DRS_CULLMODE est lui, une constante de Direct3D (D3D), utilisée pour la fonction RenderState (RS) signifiant l'utilisation du CULLMODE (et pourtant je n'y connait rien en Direct3D, je suis plutôt OpenGL...). Si tu ne trouves pas ça lisible, je ne peut rien pour toi...

"(professionel ne veut pas dire super bon mais simplement lorsque c'est un métier - profession)"
>> Pour ton information, un professionnel est quelqu'un qui exerce bien son métier.

"On utilise des énumérations et non des #define."
>> Je pense qu'il y a aussi des énumérations en C++, et l'avantage du #define est que la valeur est directement remplacée à la compilation, soit encore un gain de temps.

"le C++ était 10% plus rapide en comparaison avec .net 1.1"
>> 10%, c'est rien du tout, mais dans une fonction appellée 100 fois par seconde, ça fait beaucoup quand-même.

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

racpp · Answer

vecchio56 >> Tout ce passe comme prévu pendant le débogage. C'est à dire en débogant, je finis souvent par trouver d'ou vient le problème.

steve_clamage · Answer

+1 avec nightlord666

Ca ne sert à rien de raconter n'importe quoi sur le C++. Il y a des
domaines, comme le calcul scientifique, ou le C++ ne se porte pas trop
mal, j'aimerais bien savoir ce qu'il en est du C#.


Les namespaces non rien, mais vraiment rien, à avoir avec les #include,
et pour la gestion automatique de la mémoire il y a de quoi faire en
C++ avec l'idiom RAII, les smart pointer et même des garbage collector
mais personnelement je pense que ce n'est même pas nécéssaire.

cs_badrbadr · Answer

Olala, vous êtes en train de me casser les gars  et je me demande pkoi j'ai pas le support des .Netiens? Ah oui, ils sont encore en train de blogger!!! 
Bon, essayons de sauver les meubles :
nightlord666 a dit:
C'est justement le fait que toute la gestion de mémoire soit automatisée qui rend le C# ou les autres langages lents. Les pointeurs est surement l'outil le plus pratique et rapide fournit par C/C++, et tu es pour le fait qu'ils ne soient plus utilisables en C#...
La gestion automatique de la mémoire est considérée par beaucoup de monde comme étant un avantage. Le programme final est plus sûr et protéger contre les fuites de mémoire. En C++, lorsqu'une application possède 500 000 lignes de codes et qu'une fuite de mémoire se déclare, il est très difficile de trouver l'objet qu'on a oublier de supprimer. La conséquence est tjrs la même : plus de temps de développement et plus d'argent.
En passant, on peut tjrs utiliser les pointeurs en C# sauf que c'est considéré comme du code unsafe (non sûr). En d'autres termes, le CLR te demande de te débrouiller avec tes allocations.
Si tu trouves que DWORD n'est pas lisibles, c'est vraiment que tu devrais réviser ton informatique... DWORD, comme son nom l'indique, est un double-word codé sur 4 octets, donc le typedef d'un int/long. D3DRS_CULLMODE est lui, une constante de Direct3D (D3D), utilisée pour la fonction RenderState (RS) signifiant l'utilisation du CULLMODE (et pourtant je n'y connait rien en Direct3D, je suis plutôt OpenGL...). Si tu ne trouves pas ça lisible, je ne peut rien pour toi...
Ok, là, j'admets que j'y suis un peu plus fort en disant que c'est dégueux. Ça reste une question de gouts.
Je pense qu'il y a aussi des énumérations en C++, et l'avantage du #define est que la valeur est directement remplacée à la compilation, soit encore un gain de temps.
C'est pour ça que l'intellisense pour le C/C++ est vraiment nul. C'est fou comment on peut facilement se perdre dans une mer de Define chacun renvoyant vers un autre.
Tu peux apprendre le C# rient qu'en utilisant son Intellisense. Chaque fonction est documentée et c'est vraiment un language qui s'exprime bien.
10%, c'est rien du tout, mais dans une fonction appellée 100 fois par seconde, ça fait beaucoup quand-même.
C'est vrai mais c'est le 10% ne change pas. Genre, dans un jeu, au lieu de 33 images par secondes, t'auras 30 fps (théoriquement)
À vrai dire, il est très difficile de comparer les performances des deux langages (Il faut les comparer sur des points bien précis).

[:D] @++

vecchio56 · Answer

Pouvez vous dire d'ou sort ce chiffre de 10%?

_____________________________________
Un éditeur de ressources gratuit pour Windows

cs_badrbadr · Answer

C'est un post que j'avais lu il y a de ca longtemps. La valeur (10%) est à titre indicatif. Le message est que : Oui, les languages .net sont plus lents mais pas tant que ça!

[:D] @++

vecchio56 · Answer

A mon avis ce chiffre est faux. Certaines application peuvent peut être laisser croire à un faible écart, mais dans des application effectuant beaucoup de calculs, la différence est énorme. Je pourrais pas faire de comparaison car je ne code qu'en C++ mais je m'attendrais plutot à une variation du simple au double du temps d'exécution. Ne serait-ce qu'à l'initialisation d'un programme écrit en .net, il se passe quelques secondes là ou un programme natif démarre immédiatement

_____________________________________
Un éditeur de ressources gratuit pour Windows

steve_clamage · Answer

"En C++, lorsqu'une application possède 500 000
lignes de codes et
qu'une fuite de mémoire se déclare, il est très difficile de trouver
l'objet qu'on a oublier de supprimer. La conséquence est tjrs la même :
plus de temps de développement et plus d'argent."




Encore une fois, en C++ ce probleme n'existe pas si on connait bien le
langage. Par contre la complexité du langage est un inconvénient.

cs_badrbadr · Answer

T'as raison vecchio56.
Les calculs avec les virgules flottantes peuvent montrer des écarts plus importants.
Si je trouves qqchose la-dessus, je vous ferais signe.

[:D] @++

cs_badrbadr · Answer

J'ai une blague à partager avec vous, c'est vraiment drole :
Le C# soit trop lent pour réaliser un jeu face aux performances du C++ ? On atteint ici le paroxysme de l'incultance. Le dépassement de l'imaginure. C'est le genre de phrase qui peut nous venir trop vite à la tête si on y réfléchit pas assez. Quels sont les avantages du C++ ? Une vitesse 5% plus rapide il est vrai, puis ... bah rien ! C'est tout. Quels sont les avantages du C# ? Une vitesse 5% moins rapide. Eh oui ! Cette infime perte de vitesse paye un langage bien plus moderne, une réelle évolution "C Object", une sécurité à tout épreuve (là ou un programme en C++ reste un trou noir), offrant au programmeur une pléthore de de fonctionnalités aux avantages certains dans l'élaboration d'une application multimédia. Là ou un codeur C++ créera des fonctionnalités lourdes, incertaines et difficilement debuggable faites de tests, de gestion mémoire qu'il se doit de gérer lui même, le C# offrira au programmeur les même fonctionnalités sécurisées, lui laissant toutes mains libres pour créer des alorithmes performants qui plaieront sans problèmes les 5% qui procure au C++ le seul avantage qu'on peut lui trouver. (et vlan) (ça me manquait les parhenthèses).

Franchement à regarder comme ça, on croirait un jeu pro non ? :)

P.S.: cela ne représente aucunement mon opinion....quoique 

[:D] @++

cs_badrbadr · Answer

Ça vous dirait d'élaborer un petit test de performance (non officiel).
Le test est un test de calcul. Genre afficher PI avec 22 décimales ou qqchose du genre.
Vous faites le programme en C++ et je trouve quelqu'un qui peut le faire en C# (je suis en voyage actuellement). Vous en pensez quoi?
Qui est partant?
[:D] @++

MorbhAck · Answer

Il ne faut pas oublié que le .NET est decompilable avec un Decompileur dont je ne dirai pas le nom !

vecchio56 · Answer

Effectivement, il s'agit d'une bonne blague. On pourrait très facilement inverser les mots C++ et C# à partir de la moitié du texte. Aucun des arguments n'est justifié. L'auteur a sans doute eu une mauvaise expérience :)

_____________________________________
Un éditeur de ressources gratuit pour Windows

MorbhAck · Answer

Celui la c'est plus connut, mais j'ai jamais utiliser de decompiler

Lutinore · Answer

Un sujet sur le futur du C++ et personne ne parle du D !?

steve_clamage · Answer

C'est vrai, mais ca ressemble plus à un troll Java/.NET vs C++. D
serait plus du coté C++ et il me semble qu'il n'est pas encore beaucoup
utilisé bien qu'il soit certainement bien mieux foutu que C++.
J'attends de voir le prochain standard C++ qui devrait etre pour 2009
au plus tard.

BruNews · Answer

Le nbr 10% n'a absolument aucune réalité, inutile de chercher d'où il vient, c'est juste une "pub rédactionnelle" pour faire plaisir aux VBistes qu'il fallait convertir au .net, rien de plus.
Office 2007 ainsi que tous les autres VRAIS progs qui sortiront bientôt sont écrits comme il se doit en natif.
ATI vient d'annoncer le remplacement de son gestionnaire de config vidéo, insupportable grosse daube en .net, par le même mais en vrai code natif.

Essaie donc de n'obtenir que 10% d'écart avec ces qlqs exemples:
http://www.cppfrance.com/code.aspx?ID=31892
http://www.cppfrance.com/code.aspx?id=11151

Avec celui-ci
http://bnmvp.free.fr/SortInt.zip
le meilleur après plein de tests sur vbfrance a obtenu un écart de 22%.

ciao...
BruNews, MVP VC++

Lutinore · Answer

VB.NET c'est pas C#, regardes la version unsafe en C# de ce snippet :



http://www.codyx.org/snippet_inverser-chaine-caracteres_10.aspx


Hormis l'instruction fixed ça ressemble comme deux gouttes d'eau à du C, l'instruction fixed a quand même un coût en terme de CPU mais je pouvais m'en passer et allouer une chaine sur le tas non-managé et là on serait bien en dessous des 22%.. bon ok après on peut plus appeller ça du code managé.


Cela dit, c'est évident que le C est plus rapide vu que le runtime .NET en plus du Garbage Collector qui tourne en background il gère la compilation du code, la sécurité, le dépassement de capacité des tableaux etc.. Mais le C# est super productif, à mon avis autant maîtriser les deux, ou le C++/CLI ( quoi que, j'ai un doute sur la syntaxe de ce langage ^^ ).

n4w4k · Answer

Au sujet de la performance relative de C++ vs. C#, il est évident que le runtime nécessaire à du C# a un coût en terme de performance. Cela dit, la rapidité de développement et d'optimisation pour un développeur expérimenté est à ce qu'on dit clairement en faveur de C# (Note: Je suis programmeur en C, et de temps en temps C++). Le C# a aussi un avantage net sur la gestion de la mémoire, sources de nombreux bugs en C/C++.
Exemple:
Raymond Chen est un développeur hyper expérimenté en C/C++ qui travaille chez Microsoft, connait tous les détails de l'API Win32 etc, et qui dans son temps libre écrit un blog (http://blogs.msdn.com/oldnewthing/) sur la programmation Win32, les erreurs classiques des programmeurs, l'historique de Windows etc.. Dans un de ses articles, Raymond a créé un programme "chargement de dictionnaire anglais/chinois" (départ ici: http://blogs.msdn.com/oldnewthing/archive/2005/05/10/415991.aspx) afin d'avoir une base de discussion sur le sujet de l'optimisation. Sa version 1 est la version naïve du dictionnaire, c'est à dire codé "fonctionnellement" mais sans penser au point de vue perfo de chacune des actions du programme. Ensuite d'article en article, il a amélioré le programme en optimisant. Bref un blog classique de programmation.
Là où c'est intéressant c'est qu'un de ses collègues, gourou en C#, s'est amusé à transcrire son 1er programme (non-optimisé) en C# quasiment mot à mot (apparemment la syntaxe est très proche), et a lancé un benchmark de la version C++ vs. la version C#
Résultat: La version C# était 10 fois plus rapide!! (Les benchs de toutes les versions sur http://blogs.msdn.com/ricom/archive/2005/05/19/420158.aspx)
D'optimisation en optimisation, Raymond a rattrapé la version C# en 5 versions (avec 1 bug introduit puis corrigé!). Bon il aurait sans doute pu sortir sa v5 en un coup (il faut se souvenir que c'était pas un concours mais une démo des étapes d'optimisation pour les lecteurs) mais n'empêche que la somme de travail d'optimisation était bien là!!! Sans compter qu'en optimisant, il y a eu un bug d'introduit!! Le collègue a ensuite optimisé très rapidement la version C# et l'a rendue 25% plus rapide!!
Dans sa version 6, Raymond a mis les bouchées double et a finalement sorti une version C++ optimisée deux fois plus rapide que la version C# non optimisée et 30% plus rapide que la version C# optimisée! En sus, la version C++ était devenue plus rapide que le temps d'initialisation du runtime .NET => imbattable.

Mais pour moi la conclusion importante de cet exemple c'est:
Le code non optimisé C# est très facilement beaucoup plus rapide que du code C++ peu ou pas suffisamment optimisé!!
Et le coût d'optimisation du C++ est très important, sans parler du risque d'introduire des nouveaux bugs!
Seul des experts en C++ peuvent arrivent à faire des applications beaucoup plus rapide que du C#, et à un coût beaucoup plus élevé! Pour une boite qui fait du développement ça a son importance!!
Et il faut penser que beaucoup de programmes ne sont pas écrits pour être performants, dans ce cas, l'écriture naïve du code en C# est beaucoup plus facile qu'en C++ et les risques de bugs liés à la mémoire moins importants! En prime la version C# risque d'être plus rapide!!

vecchio56 · Answer

Résultat assez étonnant pour la première version je dois bien avouer. Je retrouve aussi ce facteur 10 que je trouve complètement inexplicable. La seule chose que je vois est la différence de la gestion des objets. Un copie de référence est plus rapide qu'une copie d'objet complète en C++, mais même en utilisant dans pointeurs en C++ on reste plus lent...
Est-ce une mauvaise implémentation de la STL? Car étant donné que c'est effectivement un copie conforme je ne comprends pas du tout. Pour les connaisseurs, peut-on considérer que ArrayList de C# et vector de C++ on le même rôle? (je trouve pas de méthode d'accès à un élément pour l'ArrayList)
Pour finir je pense que l'idée du dico est pas mal pour comparer mais ce serait bien de tester aussi le temps de recherche une fois que le dictionnaire est chargé

_____________________________________
Un éditeur de ressources gratuit pour Windows

Lutinore · Answer

L'ArrayList est vraiment lent, c'est une classe qui maintient un tableau de type Object, Object est la classe de base de tous les types managés, même int float etc.. On accède aux éléments via l'opérateur d'indexation [ ], comme si on avait surchargé cet opérateur. Il y a donc un cast en entrée vers le type Object et un cast en sortie est necessaire pour retrouver le type réel, il y a même du boxing/unboxing pour les types valeurs ( sur la pile ) En .NET 2.0 on aurait utilisé les génériques, bien plus rapides..

steve_clamage · Answer

C'est lent surtout parce que ce sont des références qui sont stockées,
polymorphisme oblige. En C++ on manipule des valeurs, et bien sur le
template std::vector contient des valeurs, idem pour les génériques en
C# qui, j'imagines, doivent etre l'équivalent des templates C++.


C'est comme en C, il y a deux facons de faire un conteneur générique.
Soit ont fait un conteneur de void * avec tout ce qui s'en suit
(mémoire fragmentée, double indirection pour l'accés, avantage du code
unique) ou soit on utilise le cpp pour faire généré le code à partir
d'une macro parametrable.

cs_badrbadr · Answer

En C#, on utilise de préférence les génériques comme l'a dit Lutinore (v2.0).
Le boxing et l'unboxing est relativement lent.

[:D] @++

cs_Joky · Answer

Moi je comprend rien à ce que vous dites donc je vote BLANC !

Joky Président !

Mais sinon, je suis 100% pour le code natif, même si j'ai pas d'arguments comme vous.*
Bonne soirée ;)
ULARGE_INTEGERJokyQi=QI("Joky"

Pamaury · Answer

"C'est l'idée, enfin pas pour le C mais pour le C++.Seulement une
telle bibliothèque n'existe pas, c'est pour ca que ca risque de prendre
du temps."

La raison est très simple(d'après moi):
-(tous ?) les OS actuels comme Windows, Linux, Mac ont la m^mee notion de ce que peut être un ficgier et de comment y accéder:
->on peut l'ouvrir
->on peut le lire
->on peut l'écrire
->on peut se déplacer dedans
->on peut le fermer
A partir de là, on peut implémenter une bibliothèque C indépendante de l'OS puisqu'il sont tous "d'accord" .

Maintenant, si on prend le problème de la GUI et qu'on regarde les bibliothèques mises à disposition par les dévelppeur d'OS ou par d'autres comme L'API Windows, X, GTK, wxWidget, QT,...
et bien on ne trouve rien de vraiment comparable, chacun l'implémente un peu à sa sauce avec ses propres solutions . Difficile donc d'implémenter une bibliothèque indépendante de l'OS ou alors il faut en choisir une parmis celle existante...
Rien déjà que au niveau de la gestion des messages: tous n'ont pas les même !!
On peut toujours abstraire les messages de bas niveau et en faire des messages de haut-niveau .
Ensuite, au niveau des types de widget(ou fenêtre pour Windows) disponibles: certes il y a toujours les boutons, les checkbox... mais certains sont *spécifiques* à certains OS et/ou bibliothèques, chacun implémente ceux qui lui plaisent . Et bien sur il y a aussi la question de savoir quelles méthodes exportent chaque type de widget pour les contrôler(il suffit de comparer l'API Windows avec une autre pour s'en rendre compte) .
Et puis il y a un autre problème:
est-ce que chaque fenêtre doit être positionnée à une position (x,y) ou comme dans GTK par rapports à d'autres ?
On peut implémenter les deux mais là encore c'est un niveau d'abstraction en plus !

Evidemment on peut toujours augmenter encore et encore le niveau d'abstraction mais il y a un point où cela devient inintéressant .

A m a u r y

Pamaury · Answer

Je pense aussi que le C++ a encore de l'avenir au moins dans un domaine:
dans les système d'exploitation !
Et oui, je vois déjà les critiques venir: "c'est une infime partie des programmes C++" .
MAIS: Windows fait 30 Millions de lignes de C ou C++ et sans ces deux languages il n'y aurait de .net .
Et puis la bibliothèque .net est faite en C++ .
Il va s'écouler encore un bout de temps avant que les OS soit codés en autre chose que en C ou C++ .
A moins que le D ne prenne la relève .

Et puis j'aimerais poser une question à nos fan de .net: pourquoi les jeux sont-ils codées en C++ et pas en .net ???? Après tout, vous vous acharnez à démontrer que le .net est utilisable mais aucun jeux commercial ne l'utilise, faut-il y voir une stupidité de la part de l'ensemble de l'industrie du jeux-vidéo professionnel ?

A m a u r y

nightlord666 · Answer

En fait, c'est la troisième fois que j'en entend parler içi : c'est quoi ce langage D ? Quels sont ses avantages et ses inconvénients ?

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

Lutinore · Answer

Dhttp://www.digitalmars.com/d/index.html

Comparaison entre C, C++, C#, Java

http://www.digitalmars.com/d/comparison.html

Lutinore · Answer

En ce qui concerne les jeux, je pense que c'est un peu la faute à la version managée de DirectX qui à mon avis n'est pas une grande réussite, DirectDraw était pas mal, DirectInput beaucoup moins bien et je connais pas assez Direct3D. Ca devrait changer vu qu'il n y aura pas de Managed DirectX 2.0 mais XNA framework, qui si j'ai bien compris fera tourner le même code managé sur PC et XBOX.

cpprooky · Answer

Voici l'avis sur le C++ d'un humble jeune developpeur C++ anciennement developpeur sur VB6 :
Voila maintenant plus de 10 que je developpe en VB. J'ai ensuite prévu de changer de langage de programmation.J'en avais assez de la lenteur des exe produit avec VB6 ! A la sortie de VB.NET, je me suis donc tout naturellement pencher sur la cas de VB.NET ! Et je peux vous dire qu'un code VB.NET (du moins avec le framework 1.1 que j'ai utilisé à l'époque) est bien plus lent qu'un code VB6 ! Le programmeur en .NET produit effectivement son code 2 fois plus rapidement qu'avec la version 6 de VB, mais ses utilisateurs sont eux ralenti !! Etant developpeur pour des produits interne uniquement, la productivité la plus importante n'est pas la mienne, mais celle des utilisateurs de mes programmes ! Je me suis alors penché sur le cas C# ! Vraiment pas mieux ! Voila pourquoi je me tourne vers le C++ "pur" !
Donc, a mon avis (qui est celui auquel j'ai le plus tendance à me ralier !), le langage le plus véloce est l'assembleur, suivi de près par le C et le C++.
Le plus productif (pour le programmeur) est de la famille .NET : VB.NET, C#, etc ...
Le plus portable est sans conteste le C/C++ : Reste que la portabilité n'est pas le souci de tout le monde !
Le meilleur compromis pour moi est le C++.
Pour ce qui est des facilité type intellisense, etc ... ils sont plus lié à l'IDE plutot qu'au langage à mon avis, non ? On peut très bien faire du C# sous notepad, et la ... ce ne sera pas mieux que du C++ notepad !

C++ Rooky

cs_badrbadr · Answer

Les languages .net ont les mêmes performances. Entre le C# et le vb.net, tu verras pas de difference (idéalement). Ceci du au fait que le resultat du compilateur C# et du compilateur vb.net est à peu près le même en language intermédiaire (C'est notre assembleur à nous :)
Ton cas (cpprocky) est très interressant parce que, contrairement à beaucoup d'autres, t'as essayer la plateforme .net et tu ne l'as pas aimer.
Et moi qui pensais que l'essayer, c'est l'adopter à coup sûr :)

Maintenant, pour l'intellisense, je dirais pas qu'il est seulement lier à l'IDE. En .net, on a un mécanisme qui s'appelle la reflection (introspection) qui rend l'intellisense beaucoup plus évolué qu'avec d'autres languages. Avec ce mécanisme, on est en mesure de connaitre tous les types et les membres dans une assembly ainsi que d'acceder à des descriptions relatives à celle-ci.
Et si je me trompe pas, en C/C++, l'intellisense se base sur des fichiers d'entêtes (*.h). 

Pour la discussion concerant ce langage D, il semble être super équiper comme langage.

[:D] @++

nightlord666 · Answer

Et por répondre à la question qui se pose, je crois que le .NET n'est pas utilisé pour les jeux à cause de la facilité du désassemblage et de la décompilation, qui donne pratiquement un code identique qu'a la compilation... Pas très pratique pour un jeu je pense...

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

cs_badrbadr · Answer

C'est loin d'être la raison. Pour éviter que ton code se désassemble, il y a une solution : un bon obfuscateur.
Et puis, même des jeux en code natif, se font hacker.

Divisons les jeux en deux catégories: jeux OpenGL et DirectX.
Quand tu utilises l'api OpenGL, tu travailles avec une API portable et ton jeu est mieux en C++ (qui est très portable aussi). Les performancecs sont excellentes alors je ne vois aucune raison d'utiliser un autre langage. En plus, pour utiliser l'OpenGL en C#, c'est pas très très élégant.

Maintenant, quand tu utilises DirectX, il faut utiliser la version managed pour travailler en C#. Même si cette version est beaucoup plus agréable que la version original, elle est légèrement moins performante. En plus, les compagnies de jeux vidéos ont une grande experience avec les moteurs 3d en C++ et ils n'ont aucun avantage à migrer vers un autre langage et/ou plateforme.
Il y a beaucoup de réutilisation de code chez eux d'un jeu à l'autre.

Finalement, oublie pas que certains utilitaires (dans l'équipe Flight Simulator par exemple) sont développer en .net afin d'aider à la production du jeu final qui lui, est en code natif.

La force de .net est plus dans le domaine du développement web, des applications distribués et de la programmation des bases de données. Les jeux vidéos vont s'ajouter plus tard, si, comme le disait Lutinore, la plateforme XNA est un succès.

nightlord666 · Answer

Par contre, je veux bien admettre que le .NET a un point fort : la facilité de création des interfaces graphiques. Sur ce point la, même avec les MFC, le C++ ne le bats pas.

Le C++ est aussi beaucoup utilisé dans les jeux videos car sa vitesse de résolution d'algorithmes (pathfinding, collisions) et beaucoup plus rapide que celle du .NET (et là, même sans tests, j'en suis sur).

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

cs_badrbadr · Answer

Je te l'accorde.
Tu préfères quoi, utiliser MFC ou directement Win32?

nightlord666 · Answer

Moi je suis un anti-MFC en force, j'utilise Win32 ou GTK quand je fais du portable.

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

SAKingdom · Answer

Moi je trouve que la MFC n'a pas sa place dans le C/C++ ni d'ailleurs le .NET (je ne parle pas du C#) mais peu importe.

Le D? Ouais ça a l'air pas mal du tout comme langage mais ce langage est pour de la POO (comme C++) non? Il est certain qu'il doit aller plus vite dans certain domaine mais toute ces fonctionnalité intégré doive nuire quelque part. Je pense par exemple au ramasse-miette. Ceci doit prendre beaucoup de temps processeur pour localiser les objets inutilisé. Ok le D sera peut-être suppérieur au C++ mais qu'en est t-il du C? Le C, comme vous le savez, est completement sans POO ce qui permet de générer des codes légés et rapides. Mais le D sera t-il capable de générer un code équivalent à un code sans POO ou c'est strictement un "langage objet"?

C++ (@++)
___________________________________________
Les plus grands esprits trouvent toujours une solution

http://programmationdebat.discutforum.com

steve_clamage · Answer

Non ce n'est pas un langage strictement objet. D et C++ ne sont pas des
langages orientés objets, ils sont avant tout multi paradigmatiques.
C'est juste qu'ils en offre le support, contrairement au C. En ce qui
concerne le ramasse-miette, ce n'est pas dit que ca ralentisse le
programme (on peut s'attendre a tout), j'attends de voir des tests de
performance. Pour le reste, si le D s'inspire de C++ en oubliant
certain de ces défaut et en permettant d'avoir un code plus sur et plus
proche du probleme, le compilateur aura sans doute plus de possibilité
pour optimiser le code.


L'utilisation du paradigme objet n'est pas forcément couteuse en
C++,  tant qu'il n'y a pas de table virtuelle. Et le C, étant trés
proche de l'assembleur de part l'absence de mécanismes cachés et le
controle du code, ne permet pas toujours de produire facilemment un
code performant. Dans le domaine du calcul scientifique le C n'est pour
le moment pas à la hauteur de fortran et C++.

Pamaury · Answer

Pour ce qui est du ramasse-miette en D, je tiens à préciser qu'il n'est en aucun cas obligatoire(on peut gérer les allocations manuellement comme en  C++) .
Je trouve que le language D est une très bonne évolution du C++ en supprimant des possibilités parfois trop complexes mais en offrant d'autres bien utiles . Je pense par exemple aux "contracts" ou au classes/fonctions imbriquées, à la gestion intégrée des tableaux, chaîne de caractères, nombres complexes et hash map et bien d'autres très utiles .

A m a u r y

MuPuF · Answer

Le D a l'air bien pour apprendre progressivement à programmer ouais. Au debut on utilise tout en safe, et progressivement on descent jusqu'aux bits finaux lol

cpprooky · Answer

badrbadr < Pour ce qui est de l'équivalence stricte entre les langages .NEt, je m'en suis effectivement apercu après mon test du C#. Pour ce qui de l'adopter rien qu'en l'essayant, j'en suis effectivement très loin ! Il faut tout de même dire qu'avant de developper en VB, j'ai developper en ASM (ZX80, i8086 et MC68000), en Cobol, en ADA, en C, en Pascal et en différents Basic (QBasic, Basic des Atari ST/STE, des Spectrum, etc ...) Je suis donc un "vieux de la vieille" en terme de programmation : J'ai commencé la prog il y a presque 25 ans et ai touché à bcpde langage très différents les uns des autres !! Et pour mettre une pointe d'ironie dans mes propos, je dirais que ce n'est pas un peu de "poudre aux Yeux sauce .NET" qui me fera tourner la tête !
Après mes tests des langages .NET il en est ressorti que ce sont de très bons langages (que ce soit VB.NET ou C# !) mais qui ne correspondent pas à ce que je recherche dans un langage de programmation ! Je fait aussi bien en VB6 et avec l'expérience que j'en ai, je le fait aussi vite qu'un developpeur newby le ferait en .NET ! ET parès un peu de pratique en VB.NET, je n'ai pas eu l'impression de gagner suffisamment en productivité pour justifier de perdre plus de temps à sauter le pas : Quand on dit qu'un developpeur VB6 migrera à VB.NET sans douleur, je ne suis absoluement pas d'accord !!! On prend des habitudes (sans doute des mauvaises !) en VB6, et VB.NET n'apprécie pas !! La trop grande proximité des syntaxes de ces deux langages n'incite pas a faire table raze de ces habitudes. Je pense que le pb sera à peu près le même pour un vieux routard du C++ qui tenterait de migrer en C# : A la première tentative d'héritage multiple, il va se ramasser !
Alors quitte à changer de langage (C'est un fait aujourd'hui incontournable pour moi), j'ai pris le parti de zapper radicalement et de me lancer dans le C++ : Ayant fait du C dans ma jeunesse, je ne part pas totalement de zéro toutefois !
Cette migration vers le C++, je la fait aussi car je reste persuadé que le C++ sera encore pour très longtemps LE langage de programmation !
IL y a un vent disant que dans les prochaine version de Windows, .NET sera au coeur du système et que de ce fait, C++ perdra de sa domination sur les langages .NET ! Je rappelerai au passage que Windows perd lui-même de sa domination sur ... Linux pour les Workstation et Unix pour les serveurs par exemple ! Cette perte de domination est très faible mais de plsu en plus de société commence à se poser la question, et certaine saute le pas !! Essaye donc de faire du .NET sur un serveur SUN !!!

Bon je m'arrête la !!

C++ Rooky

NairodDorian · Answer

Bonjour,


Pour ce qui est de mon avis voila ce que j'en pense.



1)
.NET est une technologie avec de nombreux outils (C#, VB, COBOL, C++ Managed, CAML, Delphi...) mais c'est une technologie d'entreprise ! (le developpement d'application avec ce framework ne se fait que pour repondre a un probleme applicatif dans une entreprise. En effet les applications .NET ne voyent le jour que dans une entreprise pas dans la grande distribution. En gros les applications .NET reste a la maison et ne se sont pas distribuer pour le  grand public comme un jeu video par exemple.)
L'interet de .NET est de developper des applications riche graphiquement de maniere rapide et en melangent les langages selon 2 criteres qui sont :


1er : L'utilisation d'un langage pour un cas particulier en simplifiant au maximum la difficulte.
Exemple :
La gestion de base de donnees est plus aise a coder en VB qu'en C# de meme qu'on utilisera le C++ Managed pour faire des calculs scientifique contrairement a C# car le compilateur C++ quand il fonctionne en mode managed est plus intelligent.
Je vous invite a regarde ceci

2eme : Comme tous le monde dans une entreprise ne maitrise pas forcement le meme langage certains coderont en COBOL et d'autres en C#. En effet comme le code MSIL produit par les deux compilateurs est aussi performant il n'y a pas de problemes a melanger les deux langages. On a double productivite puisque tous les developpeurs meme oppose au niveau d'un langage peuvent apporte leurs dix doigts au developpement.

2) L'utilisation du C++ se fait selon quelques criteres qui sont :

1er : Les performances car comme tous le monde le sait les compilateurs C++ meme mauvais genere du code "assez optimise".
2eme : L'organisation d'un programme, il est plus facile d'entretenir un programme en separant les parties. Exemple d'un jeu nous avons plusieurs classes qui communique entre elles pour fonctionner. Une class pour le son une autre pour la video ainsi de suite. Si un bug est repere sur la partie sonore on se dirigera dans la classe contenant les methodes en rapport au son contrairement au C ou on perdrai beaucoup de temps a repere d'ou peut venir le bug entres les quelques milliers / million de fonctions.
3eme : Les bibliotheques, comme la plupart des bibliotheques facilitant le developpement sont elles codees en C++ exemple de MFC.

3) L'utilisation du D ne doit etre utilise que pour l'apprentissage dans les universites. En effet le D supprime l'heritage multiple et est hyper (qui a dit trop) strict au niveau des types, il faut faire des cast(type) partout dans un programme Win32.
Exemple :
MessageBox(cast(HWND)0, "mon texte en ansi", cast(LPSTR)0, 0);
En C/C++ :
MessageBox(0, "mon texte en ansi", 0, 0);



Cordialement,

Pamaury · Answer

Je ne suis pas du tout d'accord avec toi sur le D,
car concernant le problème des cast, l'exemple est biaisé: tu montre l'API Windows .
En effet, c'est bine une des rare API où la moitié des paramètres sont des pointeurs NULL .
D'ailleurs il est tout à fait possible d'écrire:
MessageBox(HWND_DESKTOP, "mon texte en ansi","",0);
en C/c++ et en D normalement, cela dépend uniquement de comment est définie MessageBox et les constante en D .
Je rappèle que en D, il y a des alias(<=> typedef C++=typage faible) et les typedef (typage fort) .
Je trouve que justement cela permet d'écrire un code de plus haut niveau et de repérer plus vite les bug mais ce n'est que mon avis .

A m a u r y

steve_clamage · Answer

Pour le 3) je ne suis pas d'accord, la force du typage est un plus et
donner en exemple le fait que ca rend laborieux l'interfacage avec du C
est malhonnete, on pourrait tres bien faire des wrappers dans ce cas.


Pour le 2eme du 2), ce n'est pas parce que le C ne supporte pas la POO
qu'il est impossible de faire de la programmation modulaire avec. Comme
en C++ on peut mettre l'interface publique d'un module dans des .h et
son implémentation dans des sources (.c).

cpprooky · Answer

D'accord avec Pamaury et steve_clamage ! Un langage fortement typé est plus sécurisant ! Cela permet de faire bloquer le compilo sur des erreurs de la part du codeur ! La politique est alors : "Si le codeur fait un typecast, c'est qu'il sait ce qu'il fait ! Sinon, moi, le compilo, je ne met permet pas d'interpréter ce qu'il a écrit d'une facon qui m'arrange pour pondre le code machine !"
Il est un fait que cela allourdi les syntaxes mais cela simplifie la lecture du code : Avec un "cast(HWND)0" au lieu d'un simple "0", on sait tout de suite que le 1er argument de MessageBox() est un handle de fenetre -Dans le cas de cete API, c'est débile, car on le sait tous mais sur d'autres fonction, cela aide, c'est indéniable je pense !-
En plus, cela ralenti le codeur lors de sa frappe mais il débuggera moins, donc !! Vaut-il mieux perdre 2s à taper "cast(HWND)0" plutot que "0" ou perdre 10 minutes à lancer le compilo, tester l'exe obtenu, s'appercevoir que y a un bug, retourner dans l'IDE, lancer le debugger, chercher et trouver ensuite l'erreur ?

Perso je suis plus fénéant sur le debuggage que sur la frappe ! Cela coute plus cher en clavier (touches "(" et ")" qui s'usent plus vite et qu'il faut alors remplacer, etc ...) mais cela evite d'attraper de l'arthrose au doigts et donc réduit les couts de santé publique en France !! En conclusion : D est bon pour la Sécu !!

C++ Rooky

nightlord666 · Answer

Bonne conclusion cpprooky 

Pour reboucher le trou de la secu, ils n'ont qu'à nous payer des bons ordinateurs et la licence d'Office ^^.

<hr size="2" width="100%" />Sachant qu'on peut toujours enlever une ligne à un programme, et que dans un programme il y a toujours un bug, un programme peut se résumer à une ligne avec un bug.

Le future de C++

74 réponses

Votre réponse

Discussions similaires