Discussion :

[heska77240]

Salut à tous,

Je voulais vous posez une question à propos du C#,

Ne connaissant rien à la programmation, je voudrais apprendre le langage C#, j'ai acheté un livre.

Je pose cette question car une fois le livre terminé je n'aurais rien appris sur les windows forms alors que c'était dans mes objectifs.

En revanche avez vous un livre à me conseiller qui traite la programmation en windows forms, en partant du principe que j'aurais lu celui que je viens d'acheter avant, ce qui m'aidera beaucoup quand même je pense, sachant que c'est un livre qui est fait pour les personnes sans connaissances qui partent de zéro dans la programmation.

Je vous remercie d'avance bye ;-)

[alandrieu]

Bonjour #heska77240,

L'erreur de la jeunesse qui ne lit plus, la prochaine fois si possible lis le sommaire . Ce n'est pas un mauvais livre et pour commencer il faut passer par le mode console. Les Winform ou WPF ne sont pas bien compliqués et de bons tutoriels Winform sur le net expliquent leurs fonctionnements.

[heska77240]

Salut girakith,

Tout d'abord merci pour ta réponse ;-)

Si tu me dis que pour commencer il faut passer par le mode console sa me rassure, mais je voulais savoir si la console et les Winforms sont deux mondes à part ou bien retrouve ton les mêmes "codes", variables etc....

J'ai hesité à apprendre le C++ mais le C# étant le plus récent j'ai préféré ce choix, mais pour exemple pour apprendre le C++ il traite le sujet des Winforms mais le le C++ est bien plus compliqué que le C#.

[Pragmateek]

L'avantage de bosser en mode console est que les concepts cœurs ne sont pas noyés dans de la tuyauterie graphique donc continue comme ça.

Après pour faire des interfaces graphiques en .Net sache que WinForms est obsolescent depuis quelques années remplacé par WPF dont l'avenir est ... disons incertain.
Mais sur Windows XP/Vista/7 pas le choix c'est WPF et la transition WinRT n'est pas aussi abrupte que de WinForms aux technos XAML.

Après le fait que C# soit plus récent n'en fait pas un meilleur langage, par exemple il est à la ramasse par rapport à du C++ pour faire du calcul haute performance et c'est bien normal ce n'est pas son objectif.
En revanche pour le développement d'applications graphiques couplé avec WPF ou WinRT il est top.

[heska77240]

L'avantage de bosser en mode console est que les concepts cœurs ne sont pas noyés dans de la tuyauterie graphique donc continue comme ça.

Après pour faire des interfaces graphiques en .Net sache que WinForms est obsolescent depuis quelques années remplacé par WPF dont l'avenir est ... disons incertain.
Mais sur Windows XP/Vista/7 pas le choix c'est WPF et la transition WinRT n'est pas aussi abrupte que de WinForms aux technos XAML.

Après le fait que C# soit plus récent n'en fait pas un meilleur langage, par exemple il est à la ramasse par rapport à du C++ pour faire du calcul haute performance et c'est bien normal ce n'est pas son objectif.
En revanche pour le développement d'applications graphiques couplé avec WPF ou WinRT il est top.

Merci Pragmateek,

Très clair et très bien expliqué! Pour être honnête le truc c'est que je n'ai pas vraiment de projets après l'apprentissage de ce language, la seule chose que j'ai en tête c'est de vouloir apprendre un language qui me permettrai de créer des applications ou logiciels, l'objectif premier que j'ai est de créer un crypteur de fichiers.

J'ai entendu que du bien sur le C++, mais apparemment il est très difficile à apprendre c'est pour sa que j'ai choisi le C#, mais j'en suis qu'au début sur l'apprentissage du C#, si le jeu en vaut la chandelle je préférerais me tourner sur le C++........

En tant que connaisseur qu'en penses-tu???

Encore merci pour ton aide ;-)

[Pragmateek]

Dans l'idéal il te faudrait mixer les deux : C++ pour la couche de calcul et C# pour élaborer l'UI en WPF.

Après si c'est purement un projet éducatif tu peux commencer par tout faire en C# en veillant à bien séparer la couche UI de la couche calcul.
Puis une fois cette 1ère version terminée tu réimplémentes la couche calcul en C++ natif.

[Pragmateek]

Ah oui et une "petite" précision : si tu veux une UI portable sur Mac, Linux et Unix oublie WPF qui n'est pas implémenté par Mono (la version multi-plateforme de .Net), tu n'as que WinForms à ta disposition.

Ou faire une application web mais là c'est un autre univers...

[heska77240]

Pour la portabilité ce n'est pas un problème pour l'instant seul windows m'interresse, quand tu parle de mixer les deux c'est pour les projets en générale ou pour mon projet de crypteur ?

Sinon étant donné qu'après la lecture de " Apprenez à développer en C# ", je ne saurais rien sur comment programmer avec WPF, as tu un livre à me conseiller ?

Je te cache pas que je suis un peut perdu lol, je ne savais pas qu'on pouvais couplet deux languages.

[alandrieu]

Commence par bien maîtriser le C# ou le C++, le gros avantage du C++ est la gestion de la mémoire. Pour exemple de programme mixé tu as Unity que est ultra souple et pourtant c'est une machine de guerre .

La meilleur façon de travailler c'est aussi de travailler en groupe. Un groupe de deux est super pour bachoter un langage (avis personnel). Je ne connais pas spécialement de livre pour le WPF mais la documentation de Microsoft est pour moi assez complète pour commencer à l'utiliser.

> Lien <

Tu as aussi à ta disposition toute l'équipe de Developpez.com pour tes problèmes de conception

[Pragmateek]

Le mix des langages c'est pour ton projet car la crypto doit se faire le plus rapidement possible.
Ce n'est pas une généralité, la plupart des développements se contentent de .Net/C#.

Cependant mixer est très commun : e.g. en finance les pricers sont la plupart du temps implémentés en C++ pour les perfs et pour les outils de calcul numériques quasi inexistant en .Net/C#, par contre les UIs sont développées en .Net/C# pour la richesse fonctionnelle, la productivité et l'interfaçage aisé avec d'autres outils comme Excel.

Pour chaque besoin il faut le bon outil, il n'existe pas encore de langage/plateforme à large spectre, mais un projet de développement d'une telle bête existe : http://www.red-lang.org/
Je ne sais pas si ça aboutira car c'est très ambitieux et n'apporte pas forcément une grosse valeur ajoutée, la plupart des devs travaillant dans un domaine restreint et l'interop n'étant pas si compliquée que ça quand il faut passer les frontières de chaque langage/plateforme.

Pour WPF en français tu as "Développez des applications riches sous Windows" qui date de 2010 mais est toujours d'actualité vu la faible évolution de WPF depuis.
Le seul truc qu'on peut reprocher à ce livre est l'organisation étrange avec certains sujets avancés au début, et le biais "rendu 2D/3D" de l'auteur.

Pour les livres en anglais (et en général d'ailleurs) le mieux c'est "WPF 4.5 Unleashed" par contre il est très détaillé et se veut exhaustif donc passe beaucoup de temps sur des sujets rarement utilisés voire obsolètes donc il faut savoir faire le tri.

[Pol63]

Apprendre le c# juste en mode console me parait légèrement trop axé concepts
c'est bien sur le papier, mais ca doit etre frustrant ^^
enfin au moins tu devrais avoir de bonnes bases

concernant windows forms, il est en effet censé disparaitre depuis une bonne décennie, mais force est de constater que ca reste simple à coder et que ca fonctionne encore sur les windows récents
et quand microsoft abandonne une techo elle marche encore un bout de temps, et une techno si usité je pense qu'on verra venir la fin du fonctionnement
sans parler du fait que si on reste dans l'utilisation du framework, celui peut etre modifié pour ne plus appeler les dll win32 de base (on sait jamais ^^)
(un exe windows forms appelle du code du framework .net qui lui appelle le code des dlls de windows, le framework peut être codé différement sur chaque OS sans que ca ne change le fonctionnement du programme qui s'appuie dessus, c'est le principe d'une machine virtuelle)

wpf est donc un autre mode de gestion graphique d'un exe
il devait être le futur, on voit qu'avec silverlight ca a quand même bien cafouillé, à mon sens il y a eut pas mal de défaut au début, et microsoft bricole des trucs pour qu'on puisse faire des choses complexes avec


pour le choix entre les 2 je te laisse voir, techniquement ils sont vraiment différents, et maitriser l'un n'aide pas à maitriser l'autre, et le code c# à produire derrière n'est pas le même non plus

pour le windows forms, je ne pense pas qu'acheter un livre soit utile, c'est une conception très ancienne et simple à comprendre
il y a une classe (Control) qui représente un controle, celui ci est géré par windows (demande de rendu et autre) et il est rectangle
plein de classes héritent de control, chacune a ses propriétés et une méthode de dessin (méthode paint) (form (une fenetre) hérite de la classe control)
dans la méthode de dessin un bouton dessine un rectangle puis un string, alors qu'un listbox va dessiner plein de string à la suite
quand on modifie une propriété, le redessin et demandé pour ce controle
tous les controles de bases sauf le textbox sont codés en .net
on peut en créer des nouveaux en codant le méthode paint
donc au final on a du code qui modifie des propriétés des controles, et qui répond à des évènements de ceux ci (sur button.click faire que button.enabled passe à false par exemple, puis executer du code d'un traitement (qui peut etre rangé dans une classe quand même))
quand on pose un controle en mode design sur une fenetre, visual studio génère le code qui va avec dans le fichier .designer.cs (button b = new button();b.left = 50;this.controls.add(b)


pour wpf c'est plus complexe, c'est de conception plus récente
il y a un nouveau langage à balise nommé xaml qui permet de décrire l'interface plutot que de poser les controles sur une fenetre (on peut quand même les poser mais on en perd vite l'habitude)
dans ce langage on décrit à quoi ressemble la fenetre, comment se dessinent les controles (combinaison d'autres controles) et le lien entre les controles et les données
après le code en c# ne fait que traiter des données, normalement on ne modifie aucune propriété des controles directement
par exemple en xaml on écrit que dans un listbox c'est la propriétés "Clients" qui est affiché, qu'un client c'est un label avec le nom du client, un bouton pour le supprimer etc...
quand la propriété nom d'un client change, le listbox est rafraichit (il y a aussi des bindings en winforms, mais moins complets)
et sur le bouton supprimer on dit que ca appelle la méthode "Supprimer" qui se trouve sur la classe client, et là autant qu'en windows forms on écrirait listboxclients.remove(telclient), en wpf, on le supprime juste de notre collection et ca le supprime du controle qui l'affichait
le code c# est donc totalement déconnecté de l'interface, ce qui permet de mieux trier, maintenir et tester le code
quant au rendu, c'est un thread de wpf qui s'en occupe à intervalle régulier, ca utilise DirectX, on peut faire des formes autres que rectangle, et ca gère de la vraie transparence
en bref sur le papier ca parait parfait



l'utilité du C++ ce sont les performances, et la portabilité
sur la portabilité il n'y a rien à dire ca permet de développer pour autre chose que windows
pour les perfs, peu de programmes en ont besoin, du C# bien codé reste très performant (et microsoft parle d'un compilateur en code natif pour le C#)

[heska77240]

Merci pour tous vos conseils je vais déjà commencé par finir mon livre pour partir sur de bonnes bases et je verrai par la suite.

Merci pour vos explications très clairs ;-)

Si jamais j'ai quelques questions je sais à qui m'adresser ;-) bye

[alandrieu]

Ah oui et une "petite" précision : si tu veux une UI portable sur Mac, Linux et Unix oublie WPF qui n'est pas implémenté par Mono (la version multi-plateforme de .Net), tu n'as que WinForms à ta disposition.

Ou faire une application web mais là c'est un autre univers...

Il y a une alternative au WPF avec Mono : Moonlight

pour les perfs, peu de programmes en ont besoin, du C# bien codé reste très performant (et microsoft parle d'un compilateur en code natif pour le C#)

J'aurais ajouté "peu de programme pour le grand public en ont besoin", amuse toi à faire un Photoshop, Autocad, SolidWorks en C# ou java, bonjour la machine qui devra faire tourner cette application ! C'est sûr pour FlappyBird... usless.

[Pragmateek]

Attention Moonlight c'est l'implémentation Mono de Silverlight qui est une techno obsolète (j'en sais quelque chose ayant été "victime" de ce couac :/).

Pour info l'implémentation de WPF prévue par Mono se nommait le projet Olive mais vu la complexité du bousin ça n'a jamais été implémenté et ça ne le sera jamais puisque désormais l'avenir de WPF est incertain avec l'arrivée de WinRT.

[Pol63]

J'aurais ajouté "peu de programme pour le grand public en ont besoin", amuse toi à faire un Photoshop, Autocad, SolidWorks en C# ou java, bonjour la machine qui devra faire tourner cette application ! C'est sûr pour FlappyBird... usless.

c'est pas vraiment une question de grand public, mais c'est vrai que dans ce que tu cites, en c# ca n'ira pas trop ^^
il y a bien paint.net, mais ce n'est pas photoshop et la dernière version prend déjà 30% de mon i7 à rien faire !

nous on fait des applications de supervision industrielle en .net avec des tas de données et des tas de routines à exécuter ca reste très performant


@Pragmateek
winrt n'est pas un genre de wpf ? wpf sera abandonné ?
je ne fais trop de wpf, j'attends le prochain langage ^^ mais j'ai cru comprendre que même si ce n'est pas wpf qui reste ca sera du xaml, donc assez proche dans la logique et la syntaxe
je me trompe peut être mais je pense que wpf n'a pas été très adopté, ce qui me fait penser qu'il pourrait être remplacé rapidement et/ou facilement ...

[DonQuiche]

J'aurais ajouté "peu de programme pour le grand public en ont besoin", amuse toi à faire un Photoshop, Autocad, SolidWorks en C# ou java, bonjour la machine qui devra faire tourner cette application !

Bof. Très franchement je ne vois pas pourquoi C# ou Java seraient inadaptés à ce genre de programme. Oui ce sera un peu plus lent. Un peu. Pas beaucoup. Et ça pourrait même être plus rapide si les gains de productivité et de sécurité permettent de se concentrer sur des optimisations de haut niveau et la parallélisation (le nouveau compilateur C# écrit en C# est par exemple plus rapide que l'ancien en C++).

Je n'ai notamment aucun doute concernant la faisabilité d'un Photoshop en C#, aucun problème. Je suis un peu plus hésitant sur la 3D à cause des accès aléatoires de tableaux mais pas beaucoup plus.

Au pire, si c'est parce que tu as besoin de quelques instructions assembleur vectorielles, tu crées 1% du programme en C/asm et basta.

[alandrieu]

Bof. Très franchement je ne vois pas pourquoi C# ou Java seraient inadaptés à ce genre de programme. Oui ce sera un peu plus lent. Un peu. Pas beaucoup.

Je n'est pas dit que l'application serait lente mais que le matériel pour utiliser l'application devra être plus évolués.

le nouveau compilateur C# écrit en C# est par exemple plus rapide que l'ancien en C++

Tu peux me donner les compilateurs que tu prends pour référence dans ton argument ? GCC, Gtk# ?

Et ça pourrait même être plus rapide si les gains de productivité et de sécurité permettent de se concentrer sur des optimisations de haut niveau et la parallélisation

Dans le framework .NET il y a un moyen de rendre plus rapide ton application au détriment de sa portabilité sur d'autres plateformes.

[DonQuiche]

Je n'est pas dit que l'application serait lente mais que le matériel pour utiliser l'application devra être plus évolués.

Cela revient au même, à quelques détails près.

Tu peux me donner les compilateurs que tu prends pour référence dans ton argument ? GCC, Gtk# ?

Je faisais référence au précédent compilateur C# qui était écrit en C++, et qui a été remplacé par un nouveau compilateur C# écrit en C#. D'après MS leur nouveau compilo est significativement plus rapide parce qu'ils ont opté pour un design plus propre et très parallélisable, avec beaucoup de données immuables.

Dans le framework .NET il y a un moyen de rendre plus rapide ton application au détriment de sa portabilité sur d'autres plateformes. <

Non, il n'y a pas de gain de vitesse avec ça, le compilateur est le même que le compilateur JIT et cela ne fait qu'accélérer les futurs démarrages puisqu'il ne sera pas nécessaire de recompiler. Accessoirement tu peux très bien faire cette opération sur la machine du client, à l'installation.

Si tu veux un vrai compilateur AOT il faut se tourner du côté de dotnet native qui n'est pour l'instant utilisable que pour les applis windows store. Et si les gains sont appréciables (30%) cela ne se substituera certainement pas à un code optimisé et parallèle : c'est toujours au codeur de faire le gros du boulot.

[Pragmateek]

@Pragmateek
winrt n'est pas un genre de wpf ? wpf sera abandonné ?
je ne fais trop de wpf, j'attends le prochain langage ^^ mais j'ai cru comprendre que même si ce n'est pas wpf qui reste ca sera du xaml, donc assez proche dans la logique et la syntaxe
je me trompe peut être mais je pense que wpf n'a pas été très adopté, ce qui me fait penser qu'il pourrait être remplacé rapidement et/ou facilement ...

WinRT emprunte beaucoup de choses à WPF et Silverlight (XAML, liaison de données, MVVM, templates...) mais ça reste un environnement très différent de .Net, et même ce qui est commun n'est pas identique.
Donc la transition depuis WPF n'est pas monstrueuse mais il faut souvent apprendre à faire avec moins.
Cependant WinRT n'est pas encore stabilisé et reste un work-in-progress comme le montrent les nombreuses hésitations avec des composants abandonnés, mais je pense qu'on a atteint la phase de bêta depuis la 8.1, et pê que la version pour Windows 9 sera enfin assez complète pour être qualifiée de version finale, wait and see...

Il est vrai que l'adoption de WPF a été assez lente et qu'il s'est retrouvé victime d'un effet ciseau :
- d'un côté les développeurs à l'aise avec WinForms impressionnés par ce gros morceau ont mis beaucoup de temps à l'adopter, le FUD de certains n'ayant rien arrangé, faisant même croire que WPF était plus complexe que WinForms alors qu'il est juste plus riche, et rien n'empêche de faire du WPF à la WinForms
- de l'autre côté le changement de stratégie de Microsoft, notamment en raison de tensions politiques internes, certains voulant la peau de .Net (Steven Sinofsky finalement débarqué fin 2012) et l'ayant à priori obtenue en ce qui concerne le client (WinRT reposant sur COM directement et pas sur .Net), tensions sûrement associées à de véritables contraintes techniques, qui ont coupées net les perspectives de WPF.

Après WPF reste parfaitement viable et même incontournable si tu cibles Windows 7 mais il n'est plus une technologie d'avenir.

Je prépare un article sur mon blog concernant ce sujet ô combien épineux, mais pas eu le temps de le poser.

[StringBuilder]

Pour en revenir au début du sujet, il faut savoir que la GUI, que ce soit ASP.NET, WinForms, WCF, WPF, ou Console, ou je ne sais quoi d'autre n'impacte qu'une faible partie du code d'une application.

Bon, après, si on code une application purement GUI (jeu par exemple) évidement, la partie impactée est plus grande.

En C#, comme dans tous les langages, on travaille par modules, et 99% du code est présent dans des classes qui n'ont rien à voir avec la GUI. Tout comme elles n'ont rien à voir avec le SGBD utilisé ou la résolution de l'écran !

Donc pour apprendre le langage à proprement parler, le mode Console est tout aussi complet et efficace que n'importe quel autre type de projet.

Si tu maîtrises les mécanismes de C#, alors le portage d'une application de Console à WinForms, WCF, WPF ou même ASP.NET n'est qu'une simple formalité (à quelques détails quand même, il faut l'avouer).

Sinon, j'ai envie de rebondir sur les problèmes de performance de C# par rapport à C++, mais aussi sur la gestion mémoire...

C# est comme tous les langages (y compris les "plus mauvais") : si le développeur fait de la merde, il fera de la merde. Si le développeur optimise ses algos et son code, en maîtrisant les mécanismes du langage, alors le programme sera rapide et peu gourmand.

Autant C++ permet d'aller encore plus loin dans l'optimisation (et encore, ça dépend des domaines, mais à ce moment, autant proposer de faire directement de l'assembleur), autant C++ permet de faire en 2 lignes des fuites mémoires catastrophiques aussi, qu'il serait impossible à faire en C#.

Alors après, quand un développeur fait des concaténations de string à grand coup d'opérateur "+", qu'il vienne pas chialer que C# est lent... Avec StringBuilder (hihi c'est moi) les performances de C# sont identiques à celles du C++ alors bon...