[C#] Apprentissage - Page 1

yop,

J'ai décidé de me mettre au C#, avec Visual Studio côté outillage.

Côté langage, je ne connais que le C et le C++, et j'ai l'habitude d'acheter un bouquin pour en apprendre un nouveau. Je n'en ai pas trouvé chez mon auteur fétiche (Claude Delannoy), donc je compte acheter ce livre. Il est de fin 2015, donc suffisamment récent pour ne pas débuter avec plusieurs versions de retard.
- auriez-vous du feedback dessus ?
- pensez-vous que ce soit vraiment nécessaire, ou on peut vraiment transitionner du C++ au C# avec quelques tutos ?

Côté doc online, je vais devoir apprendre à utiliser MSDN.
- la version française est-elle aussi bien faite que la version anglaise (traduction à jour, fidèle, toussa), ou vaut-il mieux l'éviter ?
- y a-t-il des pièges à connaitre, des choses à savoir ou à éviter ?
En C++ j'utilisais cplusplus.com et la doc de Qt, ces docs sont très bien faites à mon goût. J'espère retrouver la même chose avec MSDN

Côté outils, j'utilise donc MS Visual Studio Community 2015. J'ai créé un projet C# avec une "form" par défaut (l'équivalent d'un QMainWindow j'imagine). Le truc qui me fait peur, c'est qu'avant de taper une ligne, j'ai déjà 15 fichiers sources de trois pages générés, là où j'en avais 3 de 10 lignes chacun avec Qt Creator.
Vais-je devoir maitriser tout ça avant de taper quoi que ce soit, ou est-ce découvrir au fur et à mesure est jouable ?
Parce que j'avoue que ça me fait un peu peur. Je ne suis absolument pas habitué à découvrir de nouvelles technos, donc je sais pas forcément par où attaquer les problèmes.


Voilà, merci d'avance pour vos conseils.


(ps -> je préfère prévenir : pour les trolls c++ vs java vs c# vs ms vs qt vs zeworld, ya jrad, merci bien )

Folco (./1) :
J'ai décidé de me mettre au C#

• Zerosquare tapote son calendrier
Zut il doit être en panne, il ne marque pas le premier avril.

Pour la doc, j'aurais tendance à privilégier la VO, en toute logique c'est celle qui sera le plus à jour. Et je ne sais pas ce qu'il en est pour C#, mais pour d'autres technos, il y a beaucoup plus de trucs en VO qu'en VF.

Je ne sais pas si c'est toujours vrai, mais à l'époque où j'ai fait un peu de C# (c'était du 2.0, donc ça date), le code autogénéré contenait les valeurs initiales des propriétés des objets de la fenête. Autant dire que c'était volumineux, mais sans réel intérêt, puisque l'éditeur permettait de modifier ça de façon plus pratique.

La plupart des pages de la MSDN que j'ai eu à utiliser en français sont des traductions automatiques; je conseille donc largement la version anglaise.

Pour les interfaces, tout dépend du choix d'interface: WPF ou WinForms. Les deux sont totalement différents; WPF est largement plus facilement personnalisable et s'approche de l'XML, tandis que WinForms est plus à l'ancienne. Les deux ont un designer de toute façon (Comme Qt Creator), qui est bien foutu.

Les fichiers "source" de "trois pages" sont automatiquement générés par Visual Studio, t'es pas censé avoir à y toucher, normalement (je le fais des fois pour aller un peu plus vite quand je veux changer un contrôle sans avoir à modifier son ancrage etc).

J'a appris le C# tout seul, sans livre, et ça se comprend très bien - je pense qu'actuellement je code mieux en C# qu'en C++ (ce qui est relativement logique), et j'ai commencé par le C++. Je pense qu'on se dépaysage pas trop - au moins pour la base.

Ok, merci pour vos avis. Perso j'aime bien passer par la case "apprentissage scolaire", après à moi de savoir transformer la théorie en pratique.
Tiens, le WPF, j'ai vu passer cet acronyme, mais j'ai oublié de googler.

<googlage...>

Bon, en résumé et si j'ai bien compris, les Windows Forms utilise le moteur GDI ou GDI+, héritages de Windows 1.
WPF est bien plus moderne, les données sont décrites dans un XML custom (XAML), c'est arrivé avec Vista et il faut un patch pour avoir une compatibilité Windows XP. Donc autant apprendre WPF, ça semble évident.

Merci beaucoup.

WPF est plus compliqué à mettre en place, surtout quand tu as passé ton temps à faire du WinForms; de l'autre main, des fois ça va plus vite de faire du WinForms.

Warpten (./6) :
de l'autre main

Quand tu dis "plus compliqué", c'est que "certaines choses dans certains cas sont plus compliquées", ou c'est plutôt "cliquer sur un simple bouton devient pain in the ass" ?
Qu'est ce qui ressemble à le plus à Qt Creator, qui lui est très "naïf" dans l'approche ?
Ton conseil au final, pour un mec qui n'a pas du tout ton niveau mais qui veut bien bûcher pour apprendre ?

C'est moins instinctif, à mon sens, de faire du WPF.

Je pense que c'est mieux de commencer par WPF - si tu as un jour besoin de faire du winforms, tu t'adapteras plus vite que dans l'autre sens

Ah, une question : est-il prévu que GDI+ soit déprécié ? Auquel cas, aucune raison de l'apprendre. Si ce n'est pas le cas, et que WPF est un autre moteur prévu pour autre chose, et que GDI+ est conservé à l'avenir, la question mérite réflexion.

à ma connaissance WinForms n'est pas prévu pour dépréciation. Mais les deux servent à la même chose: faire des interfaces graphiques.

WPF est juste largement plus flexible.

Ok. J'ai pas besoin encore de trucs de warriors. On va déjà apprendre le langage de toute façon, pour les ui j'ai le temps de voir.
Vous connaissez ce livre en ligne ? https://upload.wikimedia.org/wikipedia/commons/8/8d/Programmation_C_sharp-fr.pdf
Ca m'a l'air pas mal, vous avez des retours dessus svp ?

Je ne suis pas vraiment sur que WPF soit un "choix d'avenir", microsoft s'en eloigne au profit de "Modern UI" (et des Application Windows Universelles (aka UWA))

Au fait Folco, tu projettes d'utiliser Mono (pour la compatibilité Linux) aussi ?

Roslyn (le nouveau compilateur C#) est open-source, donc je pense que soit Mono va tout bonnement copier Roslyn, soit Roslyn va phagocyter Mono ; l'un des deux à long terme

Je pense qu'un tuto du genre from c++ to c# devrait largement faire l'affaire
(ou peut-être from a68k to c# mais c'est sans doute plus difficile à trouver )

Le problème avec un livre, c'est que ça partira sans doute de zéro, et tu risques de trouver ça pénible avec un contenu à 70% inutile.

edit :
C# pour les développeurs C++ — bravo, te voilà expert c#
et aussi :
http://dotnet.developpez.com/articles/migration/cpp_vers_csharp/
http://geekswithblogs.net/BlackRabbitCoder/archive/2010/08/12/10-things-c-developers-learning-c-should-know.aspx

Hum je suis pas sur que faire un C++ to C# soit le meilleur truc a faire, les languages sont proches certes, mais très different aussi! surtout dans la méthodologie, faire du C# comme on ferais du C++ risque de mener a du code de mauvaise qualité ()

Ok, merci pour tes liens Pen^2

Bon, on va commencer quand même les questions techniques, sinon c'est pas drôles. Je suis ce bouquin : https://fr.wikibooks.org/wiki/Programmation_C_sharp
Et j'en suis précisément là : https://fr.wikibooks.org/wiki/Programmation_C_sharp/Les_fonctions#Passage_de_param.C3.A8tres_.C3.A0_une_m.C3.A9thode
Vu qu'on a pas de pointeur, je me suis en effet posé la question de savoir comment modifier une variable en appelant une fonction.
Apparamment il y a deux possibilités :
- utiliser out, la variable concernée semble alors être en write-only
- utiliser ref, la variable est alors en r/w
C'est bien ça ?

Question con alors, pourquoi ne pas tout passer en ref, c'est une question de perf ?
La question peut se prendre dans l'autre sens : ou pourquoi avoir spécifié out, est-ce que ça a à voir avec une notion d'encapsulation, de protection ou quelque chose comme ça ?

Juste à la suite de ça, on parle de méthode COM, qu'est-ce que c'est ? C'est parachuté comme ça dans le bouquin, sans que je sache d'où vient ce fichu COM. Qu'est-ce que je peux lire là-dessus svp ?

Merci bien.

Godzil (./18) :
Mais tu doit pouvoir trouver par contre un tuto 68k asm to JVM asm

Le C# utilise le CLR .NET, pas la JVM.

out force l'assignation à la variable, ref ne le fait pas.

Les deux sont des "références".
À noter que les types objets (class, T[]) sont traités comme des références par défaut. Ce n'est pas le cas de struct ou T.

En gros

ref Dictionary<int, string> est redondant
out Dictionary<int, string> est redondant mais garantit l'assignation d'une valeur. Ce qui n'empêche pas null.

L'intérêt c'est qu'on a pas forcément besoin de la contrainte out, ref peut suffire, elle est moins forte. On s'en rend compte à l'usage.

(Téléphone) les COM je suppose qu'ils veulent parler des DllImport, c'est ce qui te permet d'utiliser une bibliothèque C(++) dans un programme en C#

Warpten (./22) :
À noter que les types objets (class, T[]) sont traités comme des références par défaut. Ce n'est pas le cas de struct ou T.

Ah ben tiens, tu tapes dans la question suivante :
Puisque tout dérive de object, et que les noms des objets sont en fait des références sur ceux-ci, comment peut-on dire qu'on passe un int par valeur, alors que c'est en fait une référence sur un objet de type int ?

(et sinon, je comprends de ce que tu dis qu'un objet passé en argument ne nécessite pas out/ref, vu que c'est une référence (une vraie cette fois !) qu' on passe, c'est ça ?)

int est un type valeur, pas référence.

(Exact)

La MSDN explique tout ça très bien: https://msdn.microsoft.com/fr-fr/library/3ewxz6et.aspx

(Les types pointeurs sont utilisés dans du code unsafe, ça "permer" de se rapprocher du C en évitant tout le runtime managé)

(Je ne veux pas entendre parler de pointeur et d'allocation mémoire, sinon je reste au C++ )

Bon, ok, en fait il y a réellement des types valeur, et une espèce de polymorphisme qui rendent le boxing implicite, quand c'est nécessaire en fait. Par contre, l'unboxing est explicite.
J'imagine donc que passer un entier boxé permet d'éviter out/ref.

Ok, merci pour ton lien.

Warpten (./23) :
(Téléphone) les COM je suppose qu'ils veulent parler des DllImport, c'est ce qui te permet d'utiliser une bibliothèque C(++) dans un programme en C#

Attention, DllImport est du P/Invoke, pas du COM Interop:
https://en.wikipedia.org/wiki/Platform_Invocation_Services
https://en.wikipedia.org/wiki/COM_Interop

Bon, je sens que je vais bientôt pouvoir mettre sur mon CV que je maitrise les technologies .NET : Fichier joint :

Hmm non, l'explication de Warpten n'est pas tout à fait exacte (ou alors je ne l'ai pas comprise).

Les mots-clé "ref" et "out" permettent de passer une référence vers une instance de classe (peu importe qu'il s'agisse d'un type référence ou d'un type valeur, c'est pour ça que c'est confus). Exemple :void Pwet1(out int value) { value = 5; } void Pwet2(out List<string> list) { list = new List<string>(); } void Test() { List<string> list; int value; Pwet1(out list); Pwet2(out value); // Ici, list est une liste initialisée et value contient 5 }Avec les deux codes suivant on peut changer la valeur des paramètres, ce qui aurait été impossible sans "ref" ou "out" dans les deux cas. Plus simplement, "ref" et "out" permettent de réassigner une variable passée par l'appelant. Sans ces mots-clés on peut soit changer son contenu mais pas la faire pointer ailleurs (dans le cas d'une variable de type référence), ou bien rien du tout (dans le cas d'une variable de type valeur).

La différence entre "ref" et "out" n'existe qu'à la compilation : dans le cas de "out" le compilateur considère que tu es obligé d'assigner la variable avant de sortir de la méthode, et va râler si tu oublies. Pour "ref" il suppose que la variable est déjà assignée à l'entrée de la méthode et qu'il est acceptable de ne pas la toucher. C'est la seule différence, les deux sont ensuite compilées exactement avec les mêmes instructions.

Folco (./24) :
(et sinon, je comprends de ce que tu dis qu'un objet passé en argument ne nécessite pas out/ref, vu que c'est une référence (une vraie cette fois !) qu' on passe, c'est ça ?)

Warpten (./25) :
(Exact)

Ah, donc ce que je cite est faux alors ?

Et dans ton exemple, Pwet2 aurait alloué une liste (probablement aussitôt libérée) sans le out, mais la variable List de Text n'aurait pas changé, c'est ça ?
Ca veut dire que Pwet2 travaille sur une copie de l'objet ? Question perf, ça doit être la cata, si c'est ça.