Bonjour
Je commance a me mettre au C# car on m´en parle beaucoup enfin bref.
Déjà, que me conseiller vous comme lib GUI C#, j´ai trouvé GTK# mais j´ai pas reussi à l´installer sinon j´ai trouvé wxWidgets en binding C#
http://wxnet.sourceforge.net/
Et niveau argumentation, qu´elle sont mes intêrets a faire une interface en C# plutot qu´en C++ ?
Deuxième question plutot débile vous allez voir :
en C++, pour l´entrée on utilise cin >> , en C# quand je fais
maVariable = System.Console.Read();
sa me fait n´importe quoi :
int mon_int = System.Console.Read();
System.Console.WriteLine("{0}", mon_int);
je rentre 6 il me resort 54 ...
ma solutions :
string maChaine = null;
maChaine = System.Console.ReadLine();
int conversion = Convert.ToInt32(maChaine);
je trovue ça un peu chiant a la longue, une solutions ?
Merci d´avance ![]()
Moi aussi la partie "avantages du C#" m´intéresse. Je me suis toujours intéressé au C++ mais après avoir suivi le mini-débat sur un autre thread, je me dis qu´il faudrait peut-être évoluer si je veux être compétitif plus tard. Là j´apprends doucement l´OCaml, cela vaut-il le coup d´apprendre en parrallèle le C# ? (sachant que je ne lâche pas le C++ de toute façon)
codé C# sans lacher le C++ je sais pas si c´est possible
http://dotnet.developpez.com/tutoriels/migration/cpp_vers_csharp/
Ouh la oui ça sent le retournement de cerveau les deux en même temps ^^
En regle general, on fait du C++ pour avoir un systeme avec de hautes performances. Pour les obtenir, ca ne te derange pas d´utiliser un langage compliqué mais qui va te permettre d´aller tuner ton code dans les moindres détails.
Quand tu fais de l´interfacage graphique, tu es généraleent bien loin de la recherche de performance. Tu veux que ca marche, et que ca marche bien. aller gratter une microseconde a chaque clique sur un bouton... tu t´en fous. Ca n´a pas d´interet. Donc ce n´est pas la peine d´utiliser un langage compliqué. Tu peux utiliser un langage plus simple.
C# devient alors un choix raisonable, il a une syntaxe proche du C++, donc plutot facile a apprendre. Et le developpement en C# est beaucoup plus facil qu´en C++.
l´interop est excellente ! je regardais recemment comment me faire des DLL managed et unmanaged pour mixer des technos communes a des projets C++ et C# (surtout pour les outils et GUI)
le C++/CLI me parait personnelement une tres bonne solution pour profiter des avantages des deux mondes.
Pour ce qui est de la bibliothèque graphique, le mieux d´après moi est d´utiliser celle qui est supporté apr ton IDE. Si tu es sous windows avec Visual Studio, tu prend les winforms et si tu es sous linux avec MonoDevelop, tu prend GTK#2.
Mais on n´y gagne que si tu peut utiliser les facilité de ton IDE et, pour l´instant, visual studio est encore bien meilleur.
Je crois que le Console.Read renvoie le code de la touche entrée au clavier (genre un getch). Alors je viens de regarder sur mono et il n´y a pas d´autre méthode que read et readline dans System.Console. Sous .NET il y a d´autre méthode plus puissante. Je ne sais pas si on peut les trouver sur linux (je connais très peu mono).
Salut,
pour ton code, Console.Read() te renvoie le code de la touche pressée, si tu le mets dans un int, tu te gardes le code (54 c´est 6).
Console.WriteLine((char)Console.Read());
la tu obtiendras 6, si tu rentres 6.
Pour revenir à la lib GUI, à moins que tu developpes sur ou pour Mono, ou que tu aies de fort besoin de portabilité, prefere Winforms, c´est la lib standard pour faire du GUI sous .Net, et ca le fait plutot bien. De plus comme dit plus haut, la facilité pour faire une GUI sous .Net en sans commune mesure avec C++, tu as un designer performant et integré, et le processus de compilation est lui aussi integré (pas besoin de moc ou autre comme QT).
A noter enfin, a part si tu fais du C++/CLI, les bases de C++ mieux vaut les oublier, si tu fais du C#, ce sont deux langages trop differents aussi bien au niveau design (heritage simple, notion d´interface) que du fonctionnement (plus de notion d´allocation, de destruction etc).
Enfin, C# (et la plateforme .Net dans son ensemble) n´est vraiment pas à la traine question perf, on obtient des resultats plutot satisfaisants, mis à part sur quelque points plus problematiques (principalement tout le pan graphismes qui en managé est plutot lent, ceci etant du à Winform qui n´aime vraiment pas les bidouilles (Thread recent sur Developpez, une form avec une image en background et 15 label transparent => resultats catastrophiques).
Bon apprentissage et bienvenu sur .Net. =)
slt, merci des réponses, je developpe sous Visual C# / Vista .
Sinon je ne connais pas le C++/CLI, et les Winforms tu peux m´en dire plus ? il y a un rapport avec l´API WIN32 ?
merci
C++/CLI, c´est la surcouche .Net au C++, qui permet de faire du C++ en evironnement managé, c´est bien pour les vieux briscards du C++ qui souhaite se mettre à .Net, pour ma part, je trouve ca syntaxiquement fatiguant à coder (pleins de ^ etc )et que quite à programmer pour .Net autant le faire avec le langage de cet plateforme à savoir C#. Apres C++/CLI reste un tres bon langage, et te permet des choses bien plus poussé que les deux autres (C# et VB) au niveau de l´interop, ou tu peux mixer code managé et non managé. Bref pour le langage sur lequel tu vas programmer en .Net, c´est vraiment une affaire de gout.
Pour Winforms, c´est le nom de la technologie des GUIs du framework, c´est une abstraction de l´API win32 (d´ailleurs tu n´as meme pas à le savoir) qui te permet de developper des GUIs facilement et rapidement. Pour demonstration, un Hello World sur Winform :
http://rafb.net/p/7fF3nj22.html
En 3 lignes, j´affiche une fenetre fonctionnelle. Bref, je te laisse lire la section de la MSDN sur la techno Winform si tu veux en savoir plus, tu y trouveras surement ton bonheur.
merci, ça a l´air énorme les Winforms ! Facile, simple et efficace, tout ce qu´il me fallait ! merci !
Juste pour temperer ton enthousiasme, meme si Winforms est une technologie qui à l´air simple à la base (abstraction de l´API sous jacente souvent bien lourde, presence d´un designer etc ...), ce n´est pas aussi simple que peut le laisser penser ce Hello World. Tant que tu resteras dans les sentiers battus, VS te cachera la plupart des difficultés, mais ca reste une techno plutot complexe.
Bref, c´etait juste un avertissement pour pas que tu te casses les dents dans quelques temps. La MSDN est ton amie, et est une lecture essentielle si tu veux programmer en .Net, n´hesites pas à la consulter.
Et bon courage. =)
Sur, les winform peuvent être complexe, mais avec l´IDE on peut produire des interface tellement complexe sans aucune ligne de code qu´avant d´arriver à un moment où ça ne suffit plus, on peut coder énormément. C´est pour ça qu´il faut utiliser ce qui est supporté par le logiciel.
@Dnob700 :
Totalement, mais c´est justement la qu´est le probleme, une fois ta belle UI construite, va falloir remplir la logique de l´application, et c´est la que ca se complique. Un debutant dans le langage, tu lui montres 5 min comment marche le designer, il te recreera l´UI de Word en 30 min, apres de la à recreer l´ensemble des fonctions c´est vraiment pas gagné, et il risque de se noyer avec une UI superbe, mais tous les problemes naissant une fois que le designer et les assistants de l´IDE ne seront plus d´aucune aide.
Voila disons que c´est un avertissement, ca parait (car plein de choses sont masqués) facile mais en fait ca ne l´est pas. =)
ok, vu comme ça, je suis d´accord avec toi. Et je recommande toujours d´apprendre à programmer dans un langage en console et sans interface pour séparer l´apprentissage du langage et du système de GUI.
Mais après, les outils, même s´ils masquent une partie de la complexité, sont toujours plus simple que s´il fallait pondre le code à la main.
Cependant, je penses qu´il est utile (pédagogiquement) d´avoir ecrit le code manuellement une fois. Meme si la premiere fois que l´on fait des interfaces n´est pas le bon moment pour tout faire manuellement.
@Godrik :
Pas forcement non plus, le systeme du designer de VS etant assez specifique de par son fonctionnement. Non, la seule chose, AMHA, sans aller jusqu´à ecrire le code soi-meme, c´est de voir au moins une fois comment ca marche (en gros, ouvrir le fichier [nomdelaform].Designer.cs généré). Meme microsoft, dans ses "tutos" a tendance a considerer la construction d´interface comme allant de soit.
Enfin bref, c´est pas fondamental en soit, mais mieux vaut toujours savoir ce que fait un "assistant" plutot que de le "laisser faire".
Quelques liens pour l´OP :
des videos de formations (anglais, mais tres comprehensible) :
http://msdn2.microsoft.com/en-us/beginner/bb308760.aspx
LE site (anglais) pour tout ce qui concerne C# :
http://www.codeproject.com/
Un cours en francais gratuit pas mal fait (Di Scala) :
http://rmdiscala.developpez.com/cours/livres/LivreBases.html#csharp
Enfin, si tu peux commence ta formation sur VS2008 (et donc par extension sur le Fx 3.5), il y a des apports vraiment interressants donc autant se former directement dessus si tu peux.
Je parle d´ecrire soit meme un systeme de gestion/conversion de message a partir d´evenement système bas niveau. Voir comme s´ecrit un fichier form produit par visual, je suis d´accord, c´est completement inutile.
aussi, l´intêret a ce que j´ai compris du C#, c´est la programmation Windows ( winforms etc ), pour les jeux on préfère le C++, donc sur Linux avec ´Mono´, c´est quoi l´intêret du C# ? je doute que l´API windows marche sur linux
, on utilise quelle API sur linux ?
merci d´avance.
le framework .NET, ce n´est pas l´API windows (win32). On peut acceder à win32 depuis .NET mais ce n´est pas la même chose.
Le but du projet mono c´est (entre autre) de fournir toutes les fonctionnalité accessibles au travers de .NET (et qui aurait un sens sur une machine Linux), y compris les winform.
Le résultat est que _parfois_ un programme compilé sous windows avec .NET peut fonctionner directement sous mono (le même .exe, sans recompilation). Bon mono a normalement implémenté tout le .NET 1.1 et ils sont en train d´implémenter le 2.0, donc il ne faut pas utiliser des fonctionnalités trop puissantes (MS en est à la version 3.5 je crois), mais c´est déjà pas mal, car il y a une très grosse base partagé.
Par contre les performances de mono ne sont pas encore terribles, mais ça aussi, ça s´améliore.