Bonjour,
Je viens de commencer de lire (le très bons) tuto de Garuma sur le C#.
Mais voilà, je demande un truc: est ce que ça vaut vraiment le coup d'apprendre le c# quand on connait le c++? Si oui, pourquoi?
Je veus dire, (corriger moi si je me trompe) le seule avantage qu'apporte le C# c'est, d'une part d'être totalement POO et en plus de faire partie de la plateforme .Net.
Au finale, qu'elles pourraient être les vraies motivations que je pourrait avoire à apprendre le c# (moi qui programme un peus en c++), qu'est ce qui change vraiment dans le c#?
ben c'est un langage different, qui reprend (un peu) la syntaxe du C++, mais qui au final est tres different sur bien des points (existence du garbage collector, heritage simple ...). Si tu preferes, c'est plus proche du Java que du C++. Le C++ te propose une portabilité plus etendue, alors que C# est "reservé" aux machines pouvant faire tourner le CLR (Windows et Linux). Enfin de par l'existence des classes de base de la plateforme DotNet, tu arriveras plus simplement a faire des actions qui auraient pu etre plus laborieuse (j'entends a faire toi meme) en C++, le meilleur exemple est l'aspect IHM avec toute la technologie WinForms, mais ca s'applique aussi a tout ce qui touche au reseau, au travail de fichier XML, au BDD.
Si tu es interressé par la plate-forme .Net, tu peux essayer le C++/CLI qui est en gros une surcouche pour faire tourner du C++ sur le framework (Jamais trop essayé donc je laisse la main sur ca).
Majoritairement on utilise un langage parce qu'il nous plait. Si tu n'aimes pas C# ne l'utilises pas (mais bon si tu aimes C++ je ne vois pas pourquoi tu n'aimerais pas C#).
Pour moi (et c'est seulement mon avis), C++ est langage qui est le fruit de très bonne idée (POO, templates, surcharge d'opérateur....) mais qui ont malheureusement soit été mal intégré soit complètement raté. Java a été en partie créé pour résoudre ces lacunes mais il en a lui même introduit de nouvelles. C# s'est construit sur la base de ces deux langages en prenant, à mon avis, un soin particulier à résoudre leurs problèmes respectifs tout en évitant d'en introduire de nouveaux, c'est pourquoi (sans dire que C# est parfait) il représente à mon sens une synthèse efficace dans le domaine du développement d'application "classiques".
C# possède (c'est toujours mon avis) beaucoup d'avantage au dessus de C++ (non exhaustif) :
- Portabilité au niveau du binaire.
- Simplicité avec par exemple la gestion automatique de la mémoire.
- Performances honorables.
- Avantage d'un code managé et vérifié.
- Un framework complet pour à peu près ce qu'on veut.
- Un langage riche possédant la plupart des qualités de Java et C++ sans leur lourdeur avec ses propres caractéristiques (au pif, le pattern GoF observateur géré au niveau du langage).
Faut bien, faut bien. En même temps je ne pense pas que ce que j'ai dit soit faux .
Non. En voilà un bon exemple d'une réponse sans troller . Explication des différences et ce que peut apporter C# comparé a C++ dans une position neutre et sans "tricherie" .
Et pour moi, la question qui me trotte dans la tête, est=ce que C# est rapide? Je veux dire, j'aimerais bien créer des minis applications avec du 3d (OpenGL exste-t-il?) alors ça prend des performances quand-même!
Et puis, est-ce que quand on utilise quelquechose avec .Net, c'est sur que c'est portable???
Merci d'avance, je suis très séduis pas ce language!
C# est rapide parce qu'il est compilé à la volée et non pas juste interprété. Néanmoins le calcul brut ne sera jamais aussi rapide que dans un langage style C. Au niveau du graphisme tu peux utiliser OpenGL en C# (de manière portable et tout) et de cette façon il n'y a pas de perte de perf puisque c'est le matos qui s'occupe du rendu. Le seul problème vient donc des sections critique de code qui demande beaucoup de calcul, je pense à la physique, et dans ce cas il peu être intéressant de réécrire ces parties en natif (C par exemple) puis de les appelé depuis C# (ce qui est très facile avec .NET). Alternativement, et à l'image du moteur de jeu Unity, tu peux écrire ton moteur graphique, physique etc... en natif PUIS à partir du code C# lié tous ces éléments entre eux.
Ha ha, merci beaucoup, c'est très interessant mais tant qu'a devoir utiliser du natif pour les calculs, autant le faire complètement en natif non?
Pas forcément. Quelque chose tu trouveras plus facile en faire en C# qu'en C dont les performances sont pas la priorité(je pense par exemple au menu de jeux ... ect.
Citation : Jowee
Et puis, pour les jeux, est-ce un bon language?
Je te répond oui car C# est objet et donc pour les jeux, la programmation (orientée) objet est un réél atout .
Citation : Garuma
C# est rapide parce qu'il est compilé à la volée et non pas juste interprété.
ByteCode ?
Citation : Garuma
Néanmoins le calcul brut ne sera jamais aussi rapide que dans un langage style C. Au niveau du graphisme tu peux utiliser OpenGL en C# (de manière portable et tout) et de cette façon il n'y a pas de perte de perf puisque c'est le matos qui s'occupe du rendu. Le seul problème vient donc des sections critique de code qui demande beaucoup de calcul, je pense à la physique, et dans ce cas il peu être intéressant de réécrire ces parties en natif (C par exemple) puis de les appelé depuis C# (ce qui est très facile avec .NET). Alternativement, et à l'image du moteur de jeu Unity, tu peux écrire ton moteur graphique, physique etc... en natif PUIS à partir du code C# lié tous ces éléments entre eux.
Tu veus dire qu'on peut utiliser open GL avec le c#, non parce que je croyais, que dans le .Net, les librairies était spécifique.
Ce qui m'ammène à une autre question: peut on utiliser la SDL en C#? (dite le moi si je suis à côté de la plaque ).
Concernant les bibliothèques, il y a le mécanisme P/Invoke qui permet d'utiliser des fonctions dans des bibliothèques natives (non .NET).
Concernant la portabilité, les binaires .NET sont portables pour peu que l'on prenne soin d'éviter certains espaces de nom du framework .NET qui sont un peu trop spécifiques à la plate-forme Windows.
Alors si je me fais une bibliothèque de fonctions disons....mathématiques, et que je veux l'utiliser en C# (comprenez .Net) alors c'est facile? Donc FMOD, SDL, OPENGL sont à la portée de tous en C#!
Alors si je me fais une bibliothèque de fonctions disons....mathématiques, et que je veux l'utiliser en C# (comprenez .Net) alors c'est facile? Donc FMOD, SDL, OPENGL sont à la portée de tous en C#!
Très très interessant!!!
Salut,
oui oui, tu peux, d'autant plus que la plupart du temps, ces "binds" ont deja été fait par d'autres (SDL.net par exemple, ou encore SQLite.net).
Je crois faire les calculs plus demandants en C et le reste en C#, c'est bien ça?
Oui, enfin, tu peux aussi essayer de tout implémenter en C# et tester les performances obtenues, il est tout à fait possible qu'elles soient très satisfaisantes, auquel cas faire un mix C# / C ne serait pas forcément justifié.
Regarde se moteur graphique uniquement fais en C# actuellement en beta , il donne envie de ce mettre au C#
Donc bon je pense que bien qu' il ne soit pas compiler nuit tres peu a ce performence.
Et puis au niveau d' un programme c' est pas le langage de programmation utilisé qui fais la rapidité de l' application c' est les algorythme utilisé. Utilise un algorytme fais avec les pied il ira pas vite avec n' importe qu'elle langage !!
- La plupart des binds multimédias bruts sont assuré par le projet Tao (OpenGL, OpenAL, GLFW, DevIL, SDL ...).
- Après d'autre projet comme celui de David font des wrappers OO dessus.
- @Jowee : Ecris d'abord ton programme en C# et après comme dit goutted il te suffit d'utiliser un profiler pour identifier les endroits où le programme passe beaucoup de temps dans les calculs et donc porté ces parties de code en C.
Citation : Ptidel
Regarde se moteur graphique uniquement fais en C# actuellement en beta , il donne envie de ce mettre au C#
Donc bon je pense que bien qu' il ne soit pas compiler nuit tres peu a ce performence.
Et puis au niveau d' un programme c' est pas le langage de programmation utilisé qui fais la rapidité de l' application c' est les algorythme utilisé. Utilise un algorytme fais avec les pied il ira pas vite avec n' importe qu'elle langage !!
Dans l'absolu ouais, dans la pratique, quand c'est le même algo, il est la plupart du temps plus rapide en langage compilé.
OMG: la dernière vidéo sortie est effectivement très bien, mais bon pour l'instant ce moteur est DX seulement (le backend OpenGL suivra après sa première sortie)
Citation : garulfo
Citation : Garuma
C# est rapide parce qu'il est compilé à la volée et non pas juste interprété.
ByteCode ?
Oui. Le bytecode s'appelle IL (Intermediate Language) et il est standardisé à l'ECMA.
Oui bien sur dans l' absolue le meme algo est plus rapide compilé qu' interprété il n' y a pas photo. Mais serieusement pas selon le meme facteur. La difference entre compiler et interprété il doit pas y avoir une difference de facteur de plus de 4 avec qu' entre different algo ( l' un fais avec les pied et un super optimisé ) on peut avoir une difference de facteur superieur a 1000 !!
Sur la question des performances, j'aimerais insister sur le point suivant, qui me semble essentiel : on ne peut jamais prévoir les performances d'un code, quel que soit le langage dans lequel il est écrit. Il y a trop de facteurs qui entrent en jeu, dont certains peuvent dépendre de détails d'implémentation qui ne sont pas forcément connus des programmeurs.
Le seul moyen de savoir si un code est rapide, c'est de le tester (et de le tester rigoureusement) et de faire des tests de performance.
Sinon, je suis d'accord sur le fond avec Ptidel (sauf pour les chiffres). Mieux vaut sûrement un bon algorithme écrit en C# qu'un mauvais algorithme en C.
Le chiffre je les ai donner completement au pif , mais pour la difference encore different algo je pense que l' on peut encore meme l' augmenter.
Petit exemple : Un solveur de soduku. L' un fais une methode qui ressemble plus a un brute force en remplissant toute les case au pif et regardant si la grille est encore valide ...
Et l' autre code avec un semblant de logique
Les deux arrive au bout mais l' un peut mettre un peu plus de temps
Sinon pour le temps entre un langage compiler et un interprété la j' en ai aucune idée
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Google
Google
Google