[C#] Apprentissage - Page 2

./29 http://ideone.com/LEGvux

Aux temps pour moi, j'ai mal expliqué (en même temps, sur téléphone )

Personellement je n'ai quasiment jamais de réassignation de conteneurs dans des fonctions sans ref/out. Si je dois réassigner, je met un coup de .Clear() et hop.

Ok, merci bien, maintenant c'est clair
Bon, je reviens un peu sur mon premier hello world :

namespace testcs
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("pouet pouet");
        }
    }
}

Suis-je obligé de déclarer un namespace ? Ou est-ce simplement une bonne coutume ?
Suis-je obligé de déclarer mon programme dans une classe ? Je crois que oui. Mais alors, cette classe a-t-elle un header ? Ou sont les autres déclarations de cette classe (les variables, par exemple) ?
Que mets-on habituellement dans cette classe "racine" de l'exécutable ?

J'ai l'impression que je vais devoir repenser ma façon de structurer les programmes ^^

Folco (./32) :
Suis-je obligé de déclarer un namespace ? Ou est-ce simplement une bonne coutume ?

Pas obligé, mais par convention on en met toujours un. Il est de bon goût de refléter dans ton namespace la même arborescence que celle de tes fichiers et de préfixer par NomDeTonProjet (voire NomDeTaBoite.NomDeTonProjet, mais là tu t'en fiches probablement), donc /Machin/Truc/Toto.cs sera dans un namespace "SuperProjetDeFolco.Machin.Truc" (et le nom complet de la classe sera donc ("SuperProjetDeFolco.Machin.Truc.Toto")

Folco (./32) :
Suis-je obligé de déclarer mon programme dans une classe ? Je crois que oui. Mais alors, cette classe a-t-elle un header ? Ou sont les autres déclarations de cette classe (les variables, par exemple) ?

Oui, et la distinction "header" vs "code" n'existe pas. Le compilateur s'occuper d'extraire la signature de tes méthodes à partir de l'unique fichier source où tu les auras implémentées.

Oui, et c'est 42 fois plus confortable que de tout dupliquer ()
Au passage, je te conseille de grouper tes membres par fonctionnalité plutôt que de les grouper par visibilité comme Stroustrup le conseillait pour le C++.
C'est en pratique bien mieux, ça évite de tout éparpiller.

Mouais, à sa place je commencerais surtout par être super méfiant vis à vis des suggestions qui contiennent "c'est bien mieux" ou "c'est de la merde" : il aura largement le temps de se faire son avis, et en plus ça évitera de transformer trop rapidement ce sujet en condensat de troll

J'en profite pour répondre à une question que j'avais sautée :

Folco (./30) :
Ca veut dire que Pwet2 travaille sur une copie de l'objet ? Question perf, ça doit être la cata, si c'est ça.

Plus haut j'évoquais les types valeur (par exemple int, float, DateTime, ou n'importe quoi que tu déclares avec le mot-clé "struct") et les types référence (string, List<>, ou n'importe quoi que tu déclares avec le mot-clé "class"), et c'est exactement ici que se joue la différence.

Les types valeur sont toujours copiés et passés en paramètre par copie, tandis que les types référence sont toujours copiés et passés en paramètre par référence. C'est un peu comme si en C++ tu avais d'un côté des "class Toto" et de l'autre "class Toto*", sauf que cette notion fait partie intégrante du type, tu ne peux pas la changer après-coup.

Pour reprendre l'exemple, List<> est un type référence et sera toujours copié par référence, quoi que tu fasses. Si tu veux vraiment copier (dupliquer) une liste, il faudra que tu le fasses explicitement par exemple avec "var autreListe = new List<int>(maListeOriginale)" (il y a des façons plus concises de l'écrire mais ça reviendra au même).

(et du coup je me rends compte que parler de "copier par référence" alors qu'on parlait d'un mot-clé "ref" quelques posts plus haut alors qu'il n'a absolument rien à voir avec tout ça, c'est un choix de mots assez malheureux )

Si tu veux, mais si la visibilité n'est pas gérée par des blocs comme en C++, je pense que c'est parce qu'il y a une raison plus objective que mon simple avis qui n'intéresse que moi, certes. Sinon c'est inutilement verbeux d'être obligé de préciser pour chaque déclaration, et un pseudo label à la C++ aurait sans doute été choisi.
Bien sûr il fait comme il veut, je ne prétends pas apporter _la_ vérité.
Je pointais juste la différence.

(edit : et j'explique pourquoi ça me semble mieux : "ça évite de tout éparpiller")

Je fais seulement une réaction allergique aux affirmations de type "c'est mieux" quand il manque la partie "je pense que" devant, peu importe que je partage l'avis ou non

Mouais, OK. C'est bien sûr selon mon expérience, ça ne me semblait pas nécessaire de tout préfixer. C'était sans doute mal formulé.
Cela dit, je ne crois pas avoir l'habitude des posts perpendiculaires, et si c'est le cas, désolé, j'y ferai attention

Warpten (./31) :
./29 http://ideone.com/LEGvux

Aux temps pour moi, j'ai mal expliqué (en même temps, sur téléphone )

C'est comme en C++ en fait:#include <QString> #include <QVector> #include <QTextStream> #include <cstdio> void Value(QVector<int> l) { l = QVector<int>(1); } void Reference(QVector<int> &l) { l = QVector<int>(1); } // Il n'y a pas de différence entre Reference et Out en C++. void Out(QVector<int> &l) { l = QVector<int>(1); } int main(void) { auto l = QVector<int>(2); auto m = QVector<int>(3); auto n = QVector<int>(4); Value(l); Reference(m); Out(n); QTextStream console(stdout); console << QStringLiteral("%1 2\n").arg(l.size()); console << QStringLiteral("%1 3\n").arg(m.size()); console << QStringLiteral("%1 4\n").arg(n.size()); return 0; }

[kevin@laptop64 ~]$ g++ -std=gnu++11 -Os -fPIC -s `pkg-config --cflags --libs Qt5Core` reftest.cpp -o reftest
[kevin@laptop64 ~]$ ./reftest
2 2
1 3
1 4

Folco (./32) :
Suis-je obligé de déclarer mon programme dans une classe ? Je crois que oui.

Il existe quand-même un workaround, couramment utilisé dans tous les langages de ce type (aussi en Java): On peut avoir des méthodes (et aussi des variables) statiques et publiques, donc on crée tout simplement une classe outils (avec un nom générique comme Utils, Globals ou Global) dans laquelle on fourre tout ce qu'on mettrait en global en C++. Ou alors tu trouves la classe à laquelle la méthode ou variable correspond le plus thématiquement et tu la mets en statique là-dedans.

(Digression: QVector? et std::vector ?)

Folco (./32) :
Suis-je obligé de déclarer un namespace ? Ou est-ce simplement une bonne coutume ?

C'est une bonne coutume, et quand tu découvriras qu'il est tout à fait possible de référencer un exécutable (pas une librairie) dans un autre exécutable, tu verras, ça te rendras les choses plus claires.

Admettons que tu aies deux classes Stream, une pour des flux de fichiers, une pour des flux réseau. Plutôt que de déclarer NetStream et FileStream, tu déclares Net.Stream et File.Stream; et quand tu as besoin des deux dans un même fichier, tu peux explicitement indiquer l'espace de nom, ou réassigner la directive using (syntaxic sugar).

(Même si cet exemple est très mauvais, puisque System.IO.File.Open retourne un FileStream :P)

Warpten (./41) :
(Digression: QVector? et std::vector ?)

(Même comportement visible, sauf que passer un std::vector par valeur copie tout le vecteur! QVector est une référence cachée (copy on write). Donc il y a une différence de performance.)

Warpten (./41) :
référencer un exécutable (pas une librairie) dans un autre exécutable

On peut faire ça aussi avec des binaires PE (.EXE classiques) ou ELF sous certaines conditions (symboles exportés, …), mais quelle horreur!

Ok, merci pour tous vos bons conseils

Bon, la suite. Je fais référence à ça : https://upload.wikimedia.org/wikipedia/commons/8/8d/Programmation_C_sharp-fr.pdf

- Page 57, pourquoi parler de libération de ressources dans une exception ? Je croyais qu'on s'occupait pas de gérer les ressources, justement ?

- page 48, j'ai pas du tout compris à quoi sert le mot-clé yield.

- à partir de la page 74, on parle des attributs. L'auteur expose tout ce qu'on peut immaginer côté syntaxe, mais pas la moindre réponse à la question "A quoi servent les attributs ? Pourquoi ont-ils été créés, dans quelle situation est-il judicieux de les utiliser ?"

Voilà, merci bien de m'éclairer sur ces questions.

Libération des ressources : la mémoire gérée par .NET est effectivement libérée automatiquement, mais ça n'est pas forcément le cas quand tu utilises des ressources système. Par exemple si tu ouvres un fichier, il faudra quand même le fermer à un moment. Bon, les classes sont toutes bien fichues, et quand le garbage collector va passer pour libérer ton instance de "File" il va appeler sa méthode "Dispose" qui va s'occuper de fermer le fichier, donc tout finira par être nettoyé correctement. Mais si tu as une exception dans ton programme c'est quand même plus propre de fermer le fichier immédiatement plutôt que d'attendre que le garbage collector le fasse pour toi.

Par convention, toutes les classes qui utilisent des ressources système (et qu'il faut donc prendre soin de libérer explicitement dès que possible) implémente l'interface "IDisposable". Elle t'impose d'implémenter une méthode "Dispose", qui est responsable de nettoyer toute ce qui doit l'être. Par convention également, un objet devient inutilisable à partir du moment où sa méthode "Dispose" est appelée.

Tu as d'ailleurs une construction pratique qui est prévue dans ce cas : le bloc "using". Il s'occupe d'appeler pour toi la méthode "Dispose" d'une classe "IDisposable" dès que tu en sors, quelle que soit la raison (return, exception, break, peu importe). Ça s'utilise comme ça :private bool Test() { using (var file = new FileStream("C:\fichier.txt", FileMode.Open)) { if (condition) return false; // file.Dispose() va être appelé juste avant de quitter la fonction ici if (autre_condition) throw new Exception("pwet"); // Idem ici // Si tout s'est bien passé jusqu'ici, la méthode file.Dispose() va être également appelée avant de quitter le bloc "using" } }Utiliser la construction "using" quand tu le peux dès que tu utilises des classes qui implémentent "IDisposable" permet de te simplifier beaucoup la vie en évitant de gérer toi-même tous les cas de sortie possibles.

Yield : c'est un peu plus compliqué à expliquer, il s'agit d'une syntaxe que te propose C# pour écrire des générateurs (mais tu pourrais les écrire à la main également, c'est juste plus long). Un générateur va te générer une suite d'objets, un à un, de façon à ce que tu puisses les énumérer dans une boucle foreach (par exemple). L'intérêt c'est que ces objets sont générés au fur et à mesure que la boucle se déroule, ce qui présente plusieurs avantages. Prenons cet exemple un peu débile (j'ai pas mieux désolé) :private IEnumerable<Resultat> CalculeResultats(int combien) { var results = Resultat[combien]; for (int i = 0; i < combien; ++i) resultat[i] = new Resultat(i); // Supposons que construire "Resultat(i)" est assez couteux, et qu'on veuille éviter de le faire pour rien return resultats; } foreach (var resultat in CalculeResultats(1000)) // Utilise résultat Avec ce bout de code, on va calculer les 1000 résultats avant de pouvoir commencer à les utiliser. Peut-être que ça serait plus intéressant si je pouvais plutôt utiliser les résultats au fur et à mesure que je les calcule, et ça tombe bien, le mot-clé "yield" permet de faire exactement ça :private IEnumerable<Resultat> CalculeResultats(int combien) { for (int i = 0; i < combien; ++i) yield return new Resultat(i); // Supposons que construire "Resultat(i)" est assez couteux, et qu'on veuille éviter de le faire pour rien } foreach (var resultat in CalculeResultats(1000)) // Utilise résultat Avec cette variante, le code compilé est assez différent. À chaque fois qu'un résultat est nécessaire (donc à chaque tour de boucle), ma fonction "CalculeResultats" va être appelée mais va s'arrêter après le "yield return", et me donner juste le résultat suivant pour pouvoir l'utiliser immédiatement. Cette alternance "calcule le résultat suivant / continue l'exécution de la boucle foreach" va continuer jusqu'à ce que "CalculeResultats" ait retourné tous ses résultats.

Attributs : mon message est déjà trop long et je ne suis pas un grand fan de cette fonctionnalité, donc je laisse à qqun d'autre le soin de répondre ^^

Aaaah, merci bien pour toutes ces clarifications !

Au fait, au hasard de mes recherches cédièsiques, je suis tombé sur ça : http://www.icsharpcode.net/OpenSource/SD/
Des fans de ce truc ? J'ai pas forcément envie de l'essayer, à moins qu'il y ait vraiment d'excellentes raisons de l'utiliser en lieu et place de Visual Studio. Votre avis ? Merci bien.

J'ai peut être loupé, mais l'effet de yield est comme sont nom l'indique de bloquer la fonction qui créé les résultat dans l'état ou elle est au moment ou elle retourne une valeur intermédiaire et elle est relancé la ou elle en était des que la fonction appelante a besoin d'une nouvelle valeur.

On peux voir ca comme une forme de threading, ou plutôt de coroutine automatique.

Je ne sais plus si le yield marche en dehors d'une construction type foreach, cette fonction a des imitations, en tout cas a l'époque ou j'avais fait des tests.

Bref, en gros dans l'exemple de Zeph, quand foreach s'execute, il va creer la coroutine Calculer, qui va faire son truc, et des qu'elle arrive au yeild, elle va donner la valeur dans le return, et donner la main au foreach, qui lui va faire son truc, puis une fois qu'il a besoin d'une nouvelle valeur, va redonner la main a Calculer etc..

Ce n'est pas un re-appel direct a la fonction, car elle est resté dans l'état ou elle était, elle ne refait pas tout le code d'init etc..

Yield n'est vraiment utile que si les valeurs a retourner sont dépendante d'un truc externe potentiellement lent, ou que tu as beaucoup de valeurs a calculer et qu'une IHM est a mettre a jour pendant les boucles (et que le calculs de toutes les valeurs est relativement long car beaucoup de données)

Sinon l'intérêt est plutôt limité, car la construction peut être assez laborieuse, car elle a des limites.

De mémoire à la compilation yield se transforme en énumérable, faudra que je passe un coup de reflector à l'occasion.

Pour les attributs, l'intérêt principal ça reste la séralisation quand on commence à toucher à Reflection (Comme en Java, mais tellement mieux à mon sens).
Je m'en sers par exemple pour indiquer à une de mes classes qui lit des fichiers binaires l'ordre dans lequel les champs d'une structure sont définis; on peut aussi s'en servir pour donner des noms plus verbieux à des enums lorsqu'ils sont convertis en string (via une méthode d'extension sur les Enums, pour assurer le coup)

Un exemple?
public static string ToEncodingString(this EncodingFormat en) { var type = en.GetType(); var memInfo = type.GetMember(en.ToString()); if (memInfo.Length == 0) return en.ToString(); var attrs = memInfo[0].GetCustomAttributes(typeof(DescriptionAttribute), false); return attrs.Length > 0 ? ((DescriptionAttribute)attrs[0]).Description : en.ToString(); } [Serializable] public enum EncodingFormat { [Description("MP3 (128 Kbps)")] MP3_128 = 1, [Description("MP3 (320 Kbps)")] MP3_320 = 3, [Description("MP3 (256 Kbps)")] MP3_256 = 5, [Description("AAC (64 Kbps)")] AAC_64 = 6, [Description("MP3 (192 Kbps)")] MP3_192 = 7, [Description("AAC (96 Kbps)")] AAC_96 = 8, [Description("FLAC")] FLAC = 9, [Description("MP3 (64 Kbps)")] MP3_64 = 10, [Description("MP3 (32 Kbps)")] MP3_32 = 11 }
L'attribute DescriptionAttribute est standard dans le .NET, mais on peut définir ses propres attributs en déclarant des classes dérivées de System.Attribute. Le nom de termine par convention par "Attribute", mais la syntaxic sugar autorise d'"oublier" cette partie du nom dans l'assignation d'un attribut.

On peut vraiment faire plein de trucs avec les attributs, faut juste se rappeller que reflection est loin d'être rapide (sans être abyssallement lent)

Bon ok, faudra que je regarde cette histoire de reflexion alors. J'ai pas l'impression que ça m'empêche de commencer à coder quoi que ce soit, donc on y reviandra plus tard. Merci bien ceci dit.

La réflexion ça peut être utile dans certains cas, mais il faut aussi considérer le fait que ça fait sauter à peu près toutes les sécurités que tu as en utilisant un langage fortement typé. Mal utilisé ça peut également empêcher le compilateur de t'avertir de certaines erreurs. Pour ma part ce sont deux inconvénients que je trouve bien plus graves que la performance (surtout qu'on peut se débrouiller pour annuler quasiment toutes les pénalités à ce niveau), du coup c'est une fonctionnalité que je bannis sauf dans des cas exceptionnels. C'est sujet à beaucoup de débats.

Sinon SharpDevelop est pas mal, portable, très léger, 100x plus rapide que Visual Studio. Bien sûr il est loin d'avoir ne serait-ce que le 10ième de ses possibilités, mais ça reste un bon outil (je n'ai que lui sur ma machine perso, comme Visual Studio s'installe dans C:\ et impose tout un tas de merdes non désactivables je n'ai jamais voulu l'utiliser).

./51 , c'est pour ça que c'est pas le truc que je conseillerai de regarder en premier.


Et en alternative à VS, je ne peux que conseille SharpDevelop en effet.

Ok, merci beaucoup, je l'ai installé, et effectivement c'est léger.

Bon, sinon, voici comment on s'y prend pour designer avec Qt Creator : Fichier joint :
Pour simplifier, le container de base est le layout horizontal ou vertical.
Dans le screen, on voit la GroupBox "Files list", avec un layout vertical de 4 éléments : un premier layout horizontal (cadre rouge) contenant quelques labels et boutons, un tableau répertoriant les fichiers, un texte en italique et à nouveau un layout horizontal contenant trois boutons.
Ce layout garantit la cohérence du placement des éléments les uns par rapport aux autres, en cas de redimensionnement de la fenêtre, de changement dans le texte des Widgets, de modification du design ou que sais-je encore. Les contraintes et les placements sont gérés par Qt.

Côté réalisation, c'est on ne peut plus simple :
- installation des différents éléments dans la group box par glisser/déposer
- sélection des éléments d'un même layout, puis Ctrl-H pour créer le conteneur
- enfin, un clic dans la GroupBox, Ctrl-L pour créer le layout vertical, et c'est fini.
Un form comme ça se fait en 10 clics

J'essaye de faire l'équivalent avec les designers de C# : Fichier joint :
Comme vous voyez, j'essaye de reproduire le même form. J'en suis au stade où j'ai déposé les éléments sur le form, mais rien fait côté arrangement.
Question, comment faire, "tout simplement" ? ^^

J'ai designé le même form à l'aide du contrôle TableLayoutPanel, qui permet de layouter dans un tableau de X lignes et Y colonnes. On y retrouve donc les layouts horizontaux et verticaux, avec une ligne ou une colonne respectivement. Par contre, ça prend du temps à faire (probablement une questiob d'habitude aussi), et c'est beaucoup plus pénible à modifier (on ne peut pas ajouter un layout déjà posé sur le form à un TableLayoutPanel, il faut en dropper un nouveau, dixit un tuto sur MSDN).

Suite à ça, Zeph m'a dit sur IRC "t'as juste à glisser/déposer les contrôles sur le form, l'éditeur fait le reste". Ca, c'est le screen que vous voyez ci-dessus. Mais l'éditeur ne fait rien "tout seul".

Tout ça pour dire que les concepts des designers C# sont peut-être tout autre que ceux de Qt Creator auxquels je suis habitué. Donc, svp, quelle est la bonne façon de s'y prendre, y a-t-il des contrôles équivalents des layouts de Qt, etc... ? Merci d'avance.

Tu clique sur chaque élément individuellement et tu ajustes les bordures.

Pour les faire se redimensionner tout seul, il faut jouer avec la propriété Anchor de chaque élément (c'est plus simple en WPF)

Warpten (./54) :
Tu clique sur chaque élément individuellement et tu ajustes les bordures.

J'espère que ça veut pas dire que je dois ajuster manuellement, au pixel près, la taille de chaque contrôle ? Et recommencer si je change le texte d'un label ou insère un contrôle entre plusieurs autres ?

Warpten (./54) :
Pour les faire se redimensionner tout seul, il faut jouer avec la propriété Anchor de chaque élément

C'est pas plutôt la propriété AutoSize ? Ou un combo de celle-ci avec AutoSizeMode et Anchor.

Bref, j'y ai passé des heures, je peux pas dire que c'est intuitif, il va falloir essayer de comprendre la doc, pas le choix.

Bon aller, on la fait pas à pas. On repart de l'exemple précédent : Fichier joint :
J'ai donc mon "label1" qui a les propriétés suivantes : Anchor(top, left), Autosize(true), Dock(Fill).
Donc l'éditeur l'a calé en haut à gauche de la GroupBox.

Maintenant, je veux faire pareil avec le contrôle TextBox. Je veux qu'il soit juste à droite de "label1", à une distance cohérente par rapport aux réglage de l'OS, et que sa position s'adapte si jamais je change le texte de "label1" (ce qui ne va pas manquer d'arriver).
Si je met Anchor(top, left), et Dock(Fill), le TextBox prend toute la largeur de la GroupBox, donc c'est pas ça. Je ne trouve pas le moyen de la faire se placer automatiquement par rapport à "label1".

Je suis sur IRC

Moi aussi, quelle chance !!!

Si tu as Visual je pense () que c'est une mauvaise idée de partir sur un éditeur tiers pour débuter. Tous les tutos parleront de Visual, et si tu as une limitation due à l'outil, tu ne le sauras pas immédiatement.

C'est pas faux, mais il me semble que les tutos traitent plus souvent du langage que des fonctionnalités de l'IDE qui ne sont en grande majorité que des moyens de gagner du temps à quelques exceptions près (comme WCF). Disons que je vois mal un tuto dire "aller dans le 3ième menu et choisissez la deuxième option pour continuer".