Bonjour,
Quels sont les avantages du C# par rapport au C++ ? Le C++ est il devenu un langage has been ?
Merci,
Christophe,
Bonjour,
Quels sont les avantages du C# par rapport au C++ ? Le C++ est il devenu un langage has been ?
Merci,
Christophe,
je dirais que choisir un langage, c'est choisir le langage qui repond au besoin:
C# est un langage made in Microsoft, utilisant le framework .NET:
les plus: permet un developpement plus simple, langage de haut niveau avec des performance "okay"
les gros moins: pour windows uniquement, le code deviendra obsolete avec le temps.
C++ est un langage "universel" tres repandu, et reste le langage objet le plus rapide. Creer une application est nettement plus complexe, rendre un programme multi platforme necessite du travail sur les differentes APIs des differentes platformes. il reste cependant le langage de reference pour la creation de jeux video par exemple.
C++ n'est pas "has been", il est un langage de plus bas niveau que c#, donc moins accessible. En revanche C# doit ca popularite du fait que sa "librairie Standard" soit dedie a Windows, qui detient le monopole des OS.
Donc en dehors de Windows, et Pocket Windows, c# n'est rien...
Il faut garder en tete que Programmer en c# condamne ton appli a tourner exclusivement chez microsoft, et le code produit en c# ne peut etre "durable" car le framework est constamment modifie.
Actuellement, je programme une appli en c#, pour des raisons economique (programmer en c# est plus productif que c++) et logiciel n'a pas la vocation d'etre execute ailleur que chez microsoft.
Mais personnellent, c++ reste une valeur sure, car il offre les performances, et la liberte, et la longevite.
enfin, le createur de c++ a annonce une nouvelle version de c++ pour 2007/2008, qui devrait repondre a la concurence, a suivre...
Je ne suis pas trop d'accord avec cela car on commence à trouver des solution pour faire tourner des applis c# sur du LINUX avec par exemple MONOIl faut garder en tete que Programmer en c# condamne ton appli a tourner exclusivement chez microsoft, et le code produit en c# ne peut etre "durable" car le framework est constamment modifie.
Effectivement, Mono est même l'exemple modèle de la portabilité de .NetEnvoyé par gcorbineau
Justement quand on parle de :
- dotnet haut niveau
- C++ plus bas niveau,
Peut-on imaginer des librairies de fonctions qui constituent le moteur de l'appli en C++ (en API) et le management plus haut niveau en DotNet (Interfaces, comportement etc) ?
Est ce que c'est pertinent ou bien n'importe quoi de faire comme ça ?
En fait existe-t-il une certaine complémentarité entre ces deux langages ?
c'est tout a fait courant en faitEnvoyé par chris92
ne serait-ce pas le C++/CLI qui permet ceci? ou c'est encore autre chose?
non c'est bien çà il me semble, le C++/CLI est bein pratique pour wrapper des dll C++Envoyé par folk
De ce que j'ai vue du C# pour l'instant, je trouve que c'est un bon compromis entre un langage Compilé et du perl, mais après tout dépend de l'utilisation qu'on en fait:
qu'elle intérêt de compiler un code qui devra ou sera probablement modifié ou agrémenter de code?
D'un autre coté C# est j' imagine plus complet que perl (enfin la je suis moins certain que pour le reste)
l'intérêt doit probablement dépendre du système sur le quel on l'utilise ce qui doit faire les diférence entre bsd,linux d'un coté et windows d'un autre
Non pas vraiment. C++/CLI, c'est juste un langage pour la plateforme .NET, de la même façon que tu peux coder en C# ou en VB.
C++/CLI comporte des évolutions et changements significatifs par rapport au C++, il faut plus le considérer comme un nouveau langage.
Par rapport au wrapping de dlls (peu importe le langage dans lequel elles ont été écrites), tu peux faire ça dans tous les langages .NET, même si je ne suis pas en mesure de dire de quelle façon ce serait plus simple dans l'un ou dans l'autre.
C++/CLI, c'est bien plus que ça. On peut coder en tout managé avec, mais ça n'a aucun intérêt.
La seule raison d'exister du C++/CLI, c'est de pouvoir faire cohabiter dans un même projet du code managé et du non managé. On peut en effet appeler une dll native depuis du C#/VB/ tout langage .Net, mais l'intérêt de C++/CLI est de pouvoir le faire dans une même dll. Ce qui est courant, donc, quand on a du code C/C++ et qu'on veut l'utiliser depuis un autre langage .Net, c'est soit de le compiler en natif, et de faire du P/Invoke depuis un consommateur C#, soit d'en faire un projet C++/CLI, qui masquera le code non managé derrière une interface managée. Les consommateurs d'une telle assembly ne verront aucune différence avec une assembly 100% managée.
Merci de ces éclaircissements. Je me rend compte que ma phrase était (très) mal tournée. Je voulais surtout indiquer que le C++/CLI n'était pas juste un moyen d'accéder à du code natif, et pas le seul par ailleurs.
Je pense que C++/CLI a été un plus dans le discours de Microsoft face aux entreprises. Dans toutes les conférences et présentations au lancement, on entendait : "vous n'avez pas à jeter votre code existant, vous pouvez y aller par petites touches, vous pouvez appeler du COM, du code natif, ...". Le discours c'était : vous avez un nouvel outil formidable, et vous allez pouvoir vous mettre à l'utiliser au rythme qui vous plaira. Permettre d'utiliser C++, langage auquel les équipes de développement étaient habituées, contribuait à rassurer.
Aujourd'hui, C++/CLI est assez peu utilisé (je crois que j'avais trouvé des stats indiquant quelque chose autour du pourcent, contre environ 70% de C# et le reste en VB, F# doit être dans l'épaisseur du trait aussi - chiffre à prendre à la louche, la fiabilité de la mesure me parait difficile à obtenir), ce qui ne préjuge pas de sa qualité par ailleurs.
Partager