Discussion :

[puke502]

bonjour,

je souhaiterais faire un petit programme (mon premier de vraiment "complexe")

-qui "scan" les fichiers de plusieurs répertoires
-et pour chaque fichiers je recup certaines infos pour les stockers pour les traiter plus tard

je pensais faire une class File par exemple

class File
{
public string fullpath;
public string name;
public string datedecreation;
public string lastacces;
etc..
}

j'aimerais partir sur une bonne base et faire en sorte d'optimiser mon code pour qu'il soit rapide et bien structuré

j'ai du mal je tourne en rond depuis plusieurs jours..

il faut que je scinde mon code dans plusieurs fichiers class je suppose genre main.cs et file.cs?
j'ai lu qu'utiliser des structures permet de gagner en rapidité, cela est il vrai dans mon cas?

je sais alimenter une class avec methode ou constructeur
je sais lister tous les fichiers d'un répertoire

mais par contre lister les fichiers d'un répertoire et en même temps alimenter ma class avec les infos de chaque fichier je galère a mort..

je me dis que je vais découper en plusieurs méthodes mais apres du coup je sais jamais si je dois mettre mes fonctions dans le main.cs ou dans le file.cs

si quelqu'un a du temps a perdre pour m'expliquer les bonnes habitudes a prendre sur ce genre de traitements etc .. ça serait top !
et si il y a du code en plus c'est encore mieux !

Merci d'avance !

[ctxnop]

Salut,
Deux pages de documentations devraient suffirent :
- Directory.GetFiles, méthode (String, String)
- FileInfo Class

[puke502]

merci je vais un peu plus regarder les 2 liens mais ca ne reponds pas forcement a mes questions

j'ai oublié de preciser que dans la class file je voudrait rajouter le hash du fichier et pleins d'autres info en tout genre

[ctxnop]

il faut que je scinde mon code dans plusieurs fichiers class je suppose genre main.cs et file.cs ?

Aucune obligation de rien, mais pour que ce soit lisible on fait généralement un fichier par classe/structure. L'emplacement du fichier correspond au namespace de la classe, le fichier est nommé comme la classe (case sensitive). Encore une fois, aucune obligation, c'est juste plus lisible et facile de s'y retrouver.

j'ai lu qu'utiliser des structures permet de gagner en rapidité, cela est il vrai dans mon cas?

Pour dire oui ou non il faudrait dire "au lieu de ...". Dire qu'utiliser des structures au lieu de quelque chose d'autre est plus rapide, peut être, mais sans ce "au lieu de" il n'y a pas de comparaison.
Si tu voulais dire "au lieu de classes", c'est faux. C'est même plutôt l'inverse.
Le fait est que la réponse est purement généraliste. Dans certains cas les structures sont mieux, dans d'autres ce sont les classes, tout dépend de ce que tu veux faire et de comment tu le fais.
Les grosses différences :
- Une structure est un type de "valeur", c'est à dire que lorsque tu passes une structure à une fonction, celle-ci est copiée (donc plus elle est grosse plus c'est lent), la fonction qui manipule la structure ne peut modifier la valeur d'origine.
- Une classe un est type de "référence", c'est à dire que lorsque tu passes une classe à une fonction, celle-ci est passée via une sorte de pointeur. Pas de copie, le passage est donc beaucoup plus rapide qu'avec une classe. Par contre la fonction à accès à la valeur d'origine et peut la changer.

Il y a d'autres différences mais qui influent peu ou pas sur les performances. Sauf qu'avec une classe on ne fait normalement pas de membre publique, on fait des propriétés, et donc l'accès à un membre implique l'appel d'une méthode qui retourne la valeur plutôt que l'accès directe à la valeur. Mais ça veut aussi dire qu'on peut ajouter des choses sur le get/set, et l'objet peut être visualisé dans une grille de propriétés, servir de source de données à un contrôle, etc...

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
public struct MaStruct
{
    public string Abc; // Variable membre public, ok avec les structs. Non visible dans une grille de propriété, pas de surcharge possible, pas de code possible sur l'obtention/définition
}
 
public class MaClass
{
    public string Abc; // Syntaxiquement valide mais déconseillé.
 
    private string _Def; // Variable membre privée
    public string Def  // Propriété donnant accès à la variable membre, visible dans une grille de propriété.
    {
        get { /* Je peux ajouter du code ici */ return _Def; }
        set { /* Je peux ajouter du code ici */ _Def = value; }
        // Le code ajouté peut être un calcul, la modification d'une valeur ou la levée d'un évènement. N'importe quel code en somme.
    }
 
    public string Ghi { get; set; } // Propriété "auto-implémentée", équivalente à la propriété ci-dessus, mais je ne peux ajouter du code.
}

je sais alimenter une class avec methode ou constructeur
je sais lister tous les fichiers d'un répertoire
mais par contre lister les fichiers d'un répertoire et en même temps alimenter ma class avec les infos de chaque fichier je galère a mort.

Si tu sais liste les fichiers d'un répertoire et créer des classes, il n'y a qu'a mixer les deux. Un foreach pour parcourir les fichiers et dans celui-ci on crée une instance de la classe souhaité en la remplissant comme il se doit.
Tu peux stocker ces instances dans une liste par exemple.

je me dis que je vais découper en plusieurs méthodes mais apres du coup je sais jamais si je dois mettre mes fonctions dans le main.cs ou dans le file.cs

Elles vont là où elles sont logiques. C'est du développement objet, on met une méthode sur un objet si celle-ci manipule l'objet en question.
Il faut se demander si la méthode sera utilisable partout, par tout le monde, dans n'importe quelles conditions et si elles se rapportent réellement à l'objet ou si celui-ci n'est qu'un paramètre de la fonction. Si tu réponds à ces questions tu sauras où mettre tes méthodes.

[DonQuiche]

Bonjour.

1) Les infos fichiers doivent-elles être persistées quelque part (dans un fichier) ou bien simplement utilisées pour un traitement ultérieur ? En clair s'agit-il d'une programme de "bibliothèque" (type iTunes, Calibre, etc) ou d'un traitement sur des lots de fichiers ?



2) Une structure occupe moins de place en mémoire (pas d'en-tête), son instanciation ne requiert pas d'allocation puisqu'elle est stockée sur la pile, sa destruction est rapide et réalisée à la volée contrairement à la classe qui nécessitera plus tard une inspection du GC, et les accès à ses membres sont directs (pas besoin de lire l'adresse de l'instance). Mais passer une structure en argument est généralement plus lent puisqu'une référence pèse seulement seulement 4 à 8 octets (en 32/64 bits) quand les structures pèsent fréquemment 8 à 16 octets (rarement plus de 16 octets, c'est déconseillé, rapport aux échanges mémoire qui se font par groupes de 16 octets).

Bref parfois oui, parfois non. L'important est surtout que manipuler des structures est généralement plus casse-bonbons du fait du passage par valeur, ce qui modifie grandement le code, et que ce genre de considérations sur les performances est totalement superflue.

N'essaie PAS d'optimiser ! Écris le code le plus propre possible, point. 99% du temps il n'y aura aucun problème de performance à la fin.. Et si jamais il y en avait un il suffirait de modifier la petite partie du programme qui est concernée, et en s'appuyant sur des mesures précises pour savoir précisément ce qui prend du temps (non, l'intuition ne fonctionne pas). On n'écrit pas du code performant en salopant le code, ça ne fait que saloper le code et pas le rendre performant. Au contraire ça le rend difficilement maintenable, ce qui freinera son amélioration quand à la fin on possèdera les données indispensables à l'optimisation (profilage, etc).

"Premature optimization is the root of all evil." D. Knuth.

Si tu retiens cela, crois-moi, tu t'éviteras bien des peines et cela fera de toi un bien meilleur programmeur.

[ctxnop]

2) Une structure occupe moins de place en mémoire (pas d'en-tête), son instanciation ne requiert pas d'allocation puisqu'elle est stockée sur la pile, sa destruction est rapide et réalisée à la volée contrairement à la classe qui nécessitera plus tard une inspection du GC, et les accès à ses membres sont directs (pas besoin de lire l'adresse de l'instance). Mais passer une structure en argument est généralement plus lent puisqu'une référence pèse seulement seulement 4 à 8 octets (en 32/64 bits) quand les structures pèsent fréquemment 8 à 16 octets (rarement plus de 16 octets, c'est déconseillé, rapport aux échanges mémoire qui se font par groupes de 16 octets).

Juste pour savoir, c'est un peu HS mais bon, certaines de tes déclarations ne me semblent pas exactes. Peut-être que c'est parce que tu veux être schématique et ne pas rentrer dans les détails, mais comme je ne suis pas sur de tout, je préfère demander confirmation.

Une structure n'a pas d'en-tête ?
En C# une structure peut contenir des propriétés et des méthodes. Elle peut hériter d'une interface. Par contre elle ne peut pas hériter d'une autre structure. Mais la simple présence de méthodes et d'interface implique une entête, non ? En plus tout hérite implicitement de System.Object qui est une classe. (Attention, pas d'entête en MSIL ne signifie pas qu'il n'y en a pas au runtime)

Son instanciation ne requiert pas d'allocation puisqu'elle est stockée sur la pile ?
Les copies sont stockées sur la pile. Donc au lieu d'allouer dans le head, on copie sur la pile, pas sur que ce soit avantageux. Je ne sais pas si le principe en C/C++ est conservé en .Net, mais dans ces deux langages on possède une troisième zone d'allocation : la statique. C'est la zone dans laquelle sont stockée les données connues à la compilation. Donc typiquement, quand j'écris une fonction dans laquelle j'écris une variable de type valeur, à la compilation on connait la taille nécessaire, elle est allouée au chargement du programme. Pas sur la pile, ni sur le heap. Par contre quand je passe cette valeur à une fonction, la je copie sur la pile. Mais allocation il y a forcément, quelque soit la zone. N'utiliser que des types de valeur fait gonfler le poids de l'exécutable qui est copié en mémoire. C'est une forme d'allocation. Par contre l'allocation sur le heap est nettement plus lent, c'est sur.

Sa destruction est rapide et réalisée à la volée contrairement à la classe qui nécessitera plus tard une inspection du GC ?
La encore, une structure peut avoir des membres de type class et donc compter comme référençant. En prime une structure peut être disposée. Donc les structures sont également inspectée par le GC, surement moins en profondeur, mais tout de même.
D'ailleurs, je me suis toujours demandé si la distinction était réellement et concrètement (en opposition avec "sur le papier", après tout l'implémentation physique peut être légèrement différente si le comportement exposé correspond bien à ce qui est donné dans la norme) faite par la machine virtuelle étant donné que tout hérite de System.Object, et donc je peux mettre un int dans un System.Object, celui-ci devient alors un type de référence et non de valeur.

Je ne dit absolument pas que tes arguments en faveur de la vitesse des structure sont faux. Nul doute qu'il est plus rapide de détruire une structure qu'une classe dans le cas général. Ce sont les raisons que tu évoques qui m'interpellent et du coup j'aimerai confirmation.
Sinon un gros +1 pour la citation de Knuth. C'était déjà vrai à l'époque, mais ça l'est de plus en plus avec les compilateurs modernes pourvus d'optimiseurs surpuissants. Bon ok, ils leurs arrivent aussi de faire n'importe quoi, mais dans le cas général ils seront bien meilleurs que le développeur pour optimiser.

[DonQuiche]

En substance manipuler une structure Vecteur avec deux champs entiers X et Y aboutit aux mêmes instructions CPU que le code équivalent avec deux champs entiers distincts.

C'est très différent d'une classe.

étant donné que tout hérite de System.Object, et donc je peux mettre un int dans un System.Object, celui-ci devient alors un type de référence et non de valeur.

Attention : quand on boxe une structure (conversion à une interface ou à Object), un objet est créé. Et il faut se méfier avec la notion d'héritage : ça ne veut pas dire que l'implémentation est uniforme. Ça veut seulement dire que le compilateur C# fait des pieds et des mains pour en donner l'impression.

Une structure n'a pas d'en-tête ?

Non, une structure n'a pas d'en-tête, alors que chaque instance de classe a un en-tête de 12 octets utilisé pour stocker le hash code, son adresse (une référence n'est pas une adresse et celle-ci peut changer) et un champ utilisé par le GC (les détails de ces infos sont à vérifier, notamment la taille en 64 bits). Et l'adresse de la table virtuelle doit être stockée dans le corps de l'instance elle-même, ce qui est encore un poids supplémentaire.

En C# une structure peut contenir des propriétés et des méthodes. Elle peut hériter d'une interface.

Oui mais pas besoin de table virtuelle ni d'en-tête pour ça : une structure ne peut pas être héritée, donc si j'appelle maStructure.maFonction(), l'adresse de maFonction est connue à la compillation.

Le seul cas où une table virtuelle devient nécessaire c'est lorsqu'on boxe la structure. Et dans ce cas un objet est créé qui, lui, contiendra ces infos.

Les copies sont stockées sur la pile. Donc au lieu d'allouer dans le head, on copie sur la pile, pas sur que ce soit avantageux.

D'abord les deux zones mémoire sont équivalentes en termes de performances (si ce n'est que la plage de la pile est plus souvent déjà en cache et n'est en général pas utilisée par les autres coeurs). La seule différence importante est que :

* Avec une structure le compilateur a déjà un espace alloué et mis à zéro (la pile) et il décide que la zone sommetPile + j à sommetPile + j + p est ma structure.

* Avec une classe le compilateur a déjà un espace alloué (la pile) et il décide que la zone sommetPile + j à sommetPile + j + 8 est la référence à l'instance. Puis il fait un appel au GC qui recherche dans ses structures de données un espace de n octets pour cette instance, qu'il réserve et initialise à zéro. Enfin il enregistre cette instance dans la file du GC (celle de tous les objets), la variable contenant sa référence dans la file des objets racines, et assigne cette référence à la variable (pas nécessairement dans cet ordre)

Même histoire lors de la destruction : lorsqu'on quittera la fonction il y aura mise à zéro de la mémoire libérée, ce qui détruira naturellement la structure. Avec une classe il faudra préalablement désenregistrer la référence et par la suite le GC devra faire un tour pour nettoyer tout ça.

La encore, une structure peut avoir des membres de type class et donc compter comme référençant. En prime une structure peut être disposée. Donc les structures sont également inspectée par le GC, surement moins en profondeur, mais tout de même.

Une structure n'est même pas enregistrée dans le GC (sauf ses membres référençant des instances, comme n'importe quelle variable). Et quand tu appelles Dispose tu ne fais qu'appeler une fonction comme une autre.

En revanche une structure ne peut pas avoir aujourd'hui de destructeur puisque celui-ci est appelé par le GC pour les classes. MS pourrait toutefois concevoir un mécanisme dédié mais ça semble superflu.

[puke502]

merci de vos réponses !

Si tu sais liste les fichiers d'un répertoire et créer des classes, il n'y a qu'a mixer les deux. Un foreach pour parcourir les fichiers et dans celui-ci on crée une instance de la classe souhaité en la remplissant comme il se doit.
Tu peux stocker ces instances dans une liste par exemple.

justement c'est le mixe des 2 que je n'arrive pas a faire..

je voulais faire un foreach pour creer une instance de la classs souhaité et affecter les valeurs mais cela fonctionnait pas..

du coup après je suis parti vers l'idée de faire des méthodes ou j'essayais de renvoyer par exemple le lastaccess d'un fichier puis le stocker dans ma class ca c'est fini par un gros fail

du coup j'ai fini par venir écrire ici parce que j'avance pas..
mais en vous lisant je crois que mon problème c'est surtout que j'ai pas assez de bonnes bases..et que je suis pour l'instant un useless en particulier sur la manipulation des types etc

1) Les infos fichiers doivent-elles être persistées quelque part (dans un fichier) ou bien simplement utilisées pour un traitement ultérieur ? En clair s'agit-il d'une programme de "bibliothèque" (type iTunes, Calibre, etc) ou d'un traitement sur des lots de fichiers

non je veux pas stocker les infos fichiers mais les traiter en mémoire une fois que j'aurais tout ce qu'il faut pour faire les analyses

du coup j'ai une autre question qui me vient

imaginons que je veux récup

-writeaccess
-lastaccess
-fullpath
-name

de tous les fichiers .txt d'un répertoire d:\test (qui contient 150k de fichiers)

comme disait ctxnop un simple foreach pour parcourir les fichiers et dans celui-ci on crée une instance de la classe souhaité en la remplissant comme il se doit doit fonctionner (quand on est bon )

faut il que je récup toute les infos pendant ce foreach ?

ou faut il
1) que je récupère une liste de fullpath des fichiers txt uniquement
2)et qu'ensuite je fasse une méthode pour récup les infos manquantes uniquement a partir de la liste des fullpath que j'ai recup dans le 1) ?

merci encore !

PS :
http://www.dotnetperls.com/struct-versus-class
en effet les class semblent plus "rapide"

[DonQuiche]

je voulais faire un foreach pour creer une instance de la classs souhaité et affecter les valeurs mais cela fonctionnait pas..

Il n'y avait aucune raison pour que ça ne fonctionne pas, donc je t'invite à reprendre cette approche.

faut il que je récup toute les infos pendant ce foreach ?

ou faut il
1) que je récupère une liste de fullpath des fichiers txt uniquement
2)et qu'ensuite je fasse une méthode pour récup les infos manquantes uniquement a partir de la liste des fullpath que j'ai recup dans le 1) ?

Les deux approches sont possibles, tout dépend de la façon dont tu veux organiser ton code. Tu peux très bien stocker l'objet FileInfo pour l'utiliser plus tard, ou seulement stocker le chemin d'accès, ou stocker un objet personnalisé reprenant le FileInfo. J'éviterais quand même cette dernière solution si son seul rôle est de stocker des infos déjà exposées par FileInfo : autant éviter de créer des types pour rien.

Seul bémol : entre le moment où tu relèves les infos et le moment où tu accèdes au fichier, les choses peuvent avoir changé. Et plus il s'écoule de temps entre les deux, plus ce risque est grand. Même en faisant les deux dans la foulée à 1ms d'écart tu peux toujours avoir ce risque.

http://www.dotnetperls.com/struct-versus-class
en effet les class semblent plus "rapide"

Non, il n'y en a pas un des deux qui est plus rapide et ce benchmark ne mesure que lui-même.
* Lire depuis une structure est plus rapide.
* Une référence fait 8 octets en 64-bits, passer une structure de moins de 8 octets sera plus rapide que de passer cette référence, passer une structure de plus de 8 octets sera plus lent que de passer cette référence.
* Allouer ou détruire une structure est immédiat et rapide.

Désolé mais dans le domaine des performances les choses ne sont jamais simples. Ce benchmark a une valeur illustrative, par arbitrale.

Et, encore une fois, on s'en cogne : ne fais pas ton choix en fonction d'un problème inexistant de performances et selon la solution qui serait peut-être meilleure mais peut-être pas. Fais ton choix en fonction de ton besoin : te faut-il un objet à passer par valeur ou par référence ? Qu'est-ce qui donnera le design le plus propre ?

[puke502]

Il n'y avait aucune raison pour que ça ne fonctionne pas, donc je t'invite à reprendre cette approche.

ah ben c'est certain que le problème c'est moi j'y arrive pas..
je vais me rerepecher dessus

merci

[moldavi]

Bonjour.

Désolé, mon intervention n'a rien à voir avec le sujet.

L'important est surtout que manipuler des structures est généralement plus casse-bonbons du fait du passage par valeur

Une question à DonQuiche.

Ce que je comprends ici, c'est que l'on ne peut pas référencer une structure.

J'ai peut-être mal lu, mais il existe le mot clé "ref" pour le passage par référence. Mais je comprends peut-être mal cette assertion.

PS: toujours à DonQuiche. Tu sembles connaître des choses très précises sur le fonctionnement du GC. Quelles sont tes sources (reverse E..., employé Microsoft, un article/conférence que j'ai zappé).

[DonQuiche]

Ce que je comprends ici, c'est que l'on ne peut pas référencer une structure.

Cela veut simplement dire que par défaut une structure est passée par valeur et non par référence, contrairement aux classes.

Considère le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Vector _vector;
 
Vector GetVector()
{
    return _vector;
}
 
void Test()
{
    _vector.X =5;     // Ok
    GetVector().X = 5;  // Pas ok
}

Si Vector est une classe, pas de problème. Mais si Vector est une structure, GetVector renvoie seulement une copie de _vector. Notre dernière ligne aboutirait donc seulement à modifier une copie. Comme c'est presque certainement une erreur, le compilateur va d'ailleurs le signaler comme telle.

Cela étant dit il est effectivement possible de réclamer explicitement un passage par référence avec le mot-clé "ref". Néanmoins c'est peu commode et quand on aura besoin de passer un type par référence on choisira donc une classe et non pas une structure.

Tu sembles connaître des choses très précises sur le fonctionnement du GC. Quelles sont tes sources (reverse E..., employé Microsoft, un article/conférence que j'ai zappé).

Il y a des pelletées d'articles msdn sur le sujet (msdn magazine, blogs msdn de développeurs MS, etc) mais fondamentalement c'est un algorithme mark-and-sweep générationnel avec compactage (voir wikipedia pour infos générales sur les ramasse-miettes et algos existants).

Cela dit j'ai cet article dans mes favoris qui est la plus ancienne source officielle à ma connaissance (2000, certaines choses ont un peu évolué depuis le temps : concurrence, modes serveurs du GC et autres variantes, et améliorations du LOH) : Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework

[ctxnop]

Désolé, voilà seulement que je lis tes réponses à mes questions.
Merci pour ces éclaircissements.

[moldavi]

Re.

Il y a des pelletées d'articles msdn sur le sujet (msdn magazine, blogs msdn de développeurs MS, etc)

Merci pour le lien.

Ce qui m'a étonné, c'était la précision sur les tailles d'allocation du GC. Je n'avais jamais rien lu de tel.

[puke502]

yeah je pense avoir enfin reussi

quelqu'un peut me valider ce bout de code svp ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
 
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
 
            List<File> analyse = new List<File>();
            String[] files = Directory.GetFiles("D:\\test");
 
            for (int i = 0; i < files.Length; i++)
            {
                FileInfo F = new FileInfo(files[i]);
                File CF = new File();
                CF.Name = F.Name;
                analyse.Add(CF);
            }
 
            foreach (File print in analyse)
            {
                Console.WriteLine(print.Name);
            }
        }
 
        public class File
        {
            public string Name;
        }
 
    }
}