Class static = instance unique ?

Bonjour,

J'ai depuis longtemps un flou sur ce qu'est réellement une classes static.
Mon problème n'est pas de savoir comment elle se comporte, mais plutôt ce qu'elle représente et sur ce qui se cache derrière :

• Un programmeur m'a dit une fois qu'une classe static est simplement une classe qui ne possède qu'une seule instance que l'on ne contrôle pas et qui est crée par le constructeur static lors de la première utilisation de la classe.
  Pour ma part, j'ai l'impression qu'il n'y a pas création d'objet avec de telles classes car on travaille directement sur le type... Est-ce qu'au niveau MSIL, une classe static est traduite comme une classe n'ayant qu'une instance ? Mais alors, à quoi peut-on rattacher une classe static dans le monde réel ? Je veux dire qu'est-ce qu'elle représente concrètement ? Ou bien n'est elle utile que pour la programmation sans avoir réellement de signification ?
  
• J'ai l'impression que les classes statiques sont là pour combler tout ce qu'on ne peut pas faire en programmation objet et qui est pourtant indispensable : on y met des des méthodes prenant en paramètre des objets que l'on ne peut hériter (comme des objets de type string) (on peut même maintenant "tricher" avec des méthodes d'extensions), des variables globales... Peut être y t-il d'autre cas typique d'utilisation de classe statique ? :?
  
• Une autre question que je me pose : pourquoi les avoir appelées "static" ? Est-ce en opposition avec le polymorphisme des classes "normales" à l'exécution ?
  
• Enfin, pourquoi ne peut on pas binder une classe statique à des contrôles, pourquoi ne peut-on pas la sérialiser ?

Si quelque un peut m'éclaircir sur ces points...

Merci d'avance. :)

mathmax

Citation:

---

Un programmeur m'a dit une fois qu'une classe static est simplement une classe qui ne possède qu'une seule instance que l'on ne contrôle pas et qui est crée par le constructeur static lors de la première utilisation de la classe.

---

Il s'est planté... aucune instance n'est créée. Il y a effectivement un constructeur statique, qui initialise les membres statiques de la classe, mais tu ne peux pas créer d'instance. Celà dit, d'un point de vue fonctionnel ça revient un peu au même qu'une classe avec une instance unique.

Citation:

---

J'ai l'impression que les classes statiques sont là pour combler tout ce qu'on ne peut pas faire en programmation objet et qui est pourtant indispensable

---

Comme je le vois, ça sert surtout à regrouper des fonctionnalités qui ne se rapportent pas à un objet en particulier. C'est généralement des classes "utilitaires".

Citation:

---

Enfin, pourquoi ne peut on pas binder une classe statique à des contrôles, pourquoi ne peut-on pas la sérialiser ?

---

Le binding se fait sur une instance d'objet, or dans ce cas il n'y en a pas. Même chose pour la sérialisation : tu ne peux pas sérialiser un objet qui n'existe pas...

salut

par contre, rien n'empeche de sérialiser des choses dans une classe statique :)

The Monz, Toulouse

Citation:

---

Envoyé par tomlev

Celà dit, d'un point de vue fonctionnel ça revient un peu au même qu'une classe avec une instance unique.

---

Si on veut...
Pour le développeur qui va utiliser ta classe, il est clair que le comportement semble similaire entre une classe statique et un singleton.

Pour le compilateur par contre, la différence n'est pas négligeable...

Puisqu'une classe statique ne peut pas être héritée, on est sûr du chemin d'exécution de ses méthodes. Du coup, une classe statique devient une candidate prioritaire pour "l'inlining".

C'est d'ailleurs l'une des raisons pour lesquelles il faut souvent refléchir un minimum au moment de choisir entre instantiable et statique. Sauf erreur de ma part (il faudrait que je vérifie), en .Net une classe statique est systématiquement "inlinée", ce qui peut conduire à une chute des performances assez dramatique.

Citation:

---

Du coup, une classe statique devient une candidate prioritaire pour "l'inlining".

---

Qu'est ce que l'inlining ?

Citation:

---

Le binding se fait sur une instance d'objet, or dans ce cas il n'y en a pas.

---

Oui j'ai bien compris, mais qu'est ce qui empêcherait réellement de pouvoir le faire. Ne pourrait-on pas étendre aussi le binding aux classes statiques ?

Citation:

---

Puisqu'une classe statique ne peut pas être héritée, on est sûr du chemin d'exécution de ses méthodes.

---

C'est ce que je sens aussi. J'oppose cela au ploymorphisme des classes normales et c'est comme cela que je m'explique qu'on les appelle "static". :?

Si par exemple, on a une application avec plusieurs form. Et des objets qui doivent être manipuler dans toutes ces form. Pour ma part, j'exposerais ces objets dans une classe statique et je les instancierais dans le constructeur statique de cette classe. Est-ce vraiment la façon classique de procéder ?

Citation:

---

Envoyé par maa

Ca veux dire quoi ?

---

"L'inlining" est une optimisation utilisée par le compilateur.

Pour résumer on peut dire que l'inlining, c'est le remplacement d'un appel de fonction par une copie de son corps.

Les avantages sont nombreux, les surcoûts de l'appel sont évités : les instructions call et return, la sauvegardes des registres, le passage de paramètres et l'ajustement de la pile n'ont plus lieu d'être.

Il convient par contre de trouver un juste milieu car la forte expansion du code peut conduire à une dégradation des performances.

Le fait de creer une classe statique et d'y mettre toutes les methodes "utiles" n'appartenant a aucune autre classe d'un projet est-il une bonne chose, ou alors est-ce a eviter?

(performances, memoire, mauvaise utilisaton du static...)

Personnellement je m'en sert pour declarer quelques objets utilisable partout dans le projet ainsi que des methodes utiles (dates, formatage, parcours de grilles, tableaux etc...).

Bah je crois que sur le site de microsoft, il est écrit que les classes static sont à utiliser pour définir les méthodes utilisable par plusieurs classes et non une seule.
Un peu comme une librairie ou une dll sauf qu'à la différence tu peut y mettre des méthodes spécifiques au projet. Par exemple tu peu rendre ta classe gérant la couche d'accés au données statiques ou la classe de contrôle de la classe précédente..

Citation:

---

Envoyé par Contrec

Personnellement je m'en sert pour declarer quelques objets utilisable partout dans le projet ainsi que des methodes utiles (dates, formatage, parcours de grilles, tableaux etc...).

---

C'est un peu la question que je me posais aussi quand je disais :

Citation:

---

Si par exemple, on a une application avec plusieurs form. Et des objets qui doivent être manipuler dans toutes ces form. Pour ma part, j'exposerais ces objets dans une classe statique et je les instancierais dans le constructeur statique de cette classe. Est-ce vraiment la façon classique de procéder ?

---

Citation:

---

Si par exemple, on a une application avec plusieurs form. Et des objets qui doivent être manipuler dans toutes ces form. Pour ma part, j'exposerais ces objets dans une classe statique et je les instancierais dans le constructeur statique de cette classe. Est-ce vraiment la façon classique de procéder ?

---

Je dirais que c'est une bonne façon de procéder, et cela ressemble à la façon décrite par MS. A mon avis il suffit d'aller faire un tour sur le site MSDN pour avoir la meilleur façon d'utiliser les objets .net et la bonne façon de programmer en .net.

On est donc sur la bonne voie. D'ailleur cela justifie le role de classes statiques dans un projet.
Je n'ai pas de ralentissements lors du lancement de l'application et j'evite ainsi de creer les memes objets plusieurs fois. Cela dit, il faut etre un peu ordonne car du coup on peu se servir d'une classe statique pour y mettre tout et nimporte quoi...

tu as posé une question : pourquoi "static" plutot qu'un autre mot genre "virtual" car après tout une classe statique est virtuelle au sens où elle n'a pas d'existance propre vue qu'elle n'a pas d'instance.

déjà le mot virtual fait office au méthodes virtuelles (celles suceptibles d'etre surchargées dans les héritières) et fait référence au fait que la liaison n'est plus statique et déterminé à la compilation, mais bien à l'exécution car virtuelle au moment de la compilation.

Le mot clé static joue le meme role ici, on se place du point de vue du compilateur. une classe static est une classe que le compilateur manipule de façon statique, (comme l'inlining par exemple) l'espace alloué à chacun de ses membre ne l'est pas dans le tas, mais directement dans le code ou le segment de données, et ces emplacements sont immuables, leur "offset" est connu à la compilation, aucun mécanisme de pointeur de retour dans le chainage objet ni rien, d'ailleurs il n'y a pas de cadre objet, autour de ces membres, ils existent et c'est tout, c'est donc le contraire de dynamique et bien statique d'où l'utilisation du mot "static".

Néanmoins là on est plus dans la phylosophie qu'autre chose.

Moi j'utilise les classes statiques soit pour y mettre des données accessible par tout le programme, soit comme collection de fonctions toutes indépendantes l'une de l'autres, et souvent sans rapport aucun entre elles,
comme une classe statique Tools qui comprend des tonnes de fonctions de conversions, de changements de normes et je ne sais quoi d'autre.

Cependant, attention toutefois entre l'utilisation d'un Singleton et d'une classe statique. il est vrai que la limite entre les deux peut paraître floue, mais en réalité, les implications n'étant pas les memes, les usages non plus.

Citation:

---

Envoyé par cinemania

Cependant, attention toutefois entre l'utilisation d'un Singleton et d'une classe statique. il est vrai que la limite entre les deux peut paraître floue, mais en réalité, les implications n'étant pas les memes, les usages non plus.

---

Vi, je vois deux exemples en particulier.

En asp.net, une classe statique est 'commune' à toutes les requêtes d'une même application. Donc les valeurs statiques qui peuvent être stockées dedans sont appliquées à tout le monde, et il faut notamment faire très attention aux verrous.
Avec un singleton, on peut stocker l'instance au niveau d'une seule requête pour éviter les éventuels conflits.

Côté tests unitaires, l'instance d'un singleton peut être remplacée par une 'fausse' instance qui simule le fonctionnement normal du singleton (notamment en évitant les accès au disque ou à la base). Avec une classe statique, pas moyen. On ne peut pas passer par une interface, on est obligé de se taper la 'vraie' classe. Si elle fait appel à des ressources externes, ça alourdit monstrueusement les tests unitaires du code qui l'utilise.


Ah et donc, un singleton peut profiter de l'héritage. Une classe statique non.
Mais une classe statique est une chouette simplification syntaxique quand on n'a pas besoin de plus de subtilité.

À consommer avec modération en somme.

Citation:

---

Envoyé par cinemania

tu as posé une question : pourquoi "static" plutot qu'un autre mot genre "virtual" car après tout une classe statique est virtuelle au sens où elle n'a pas d'existance propre vue qu'elle n'a pas d'instance.

---

Il me semblait avoir lu quelque part sur ce site que le concept de classe statique est propre à C#, et n'existe pas en .Net. Tel que je le comprends, elle n'a rien de virtuel : c'est juste que son unique instance est créée quelque part entre le début de l'appli et le premier appel à un membre. Quant à l'inlining, eh bien je n'en sais rien.

Mais ça n'a rien de neuf : on pouvait déjà ne définir que des membres statiques dans une classe en c++ ou .Net 1.1, mettre son constructeur en privé et zou :)

Citation:

---

Envoyé par Guulh

Mais ça n'a rien de neuf : on pouvait déjà ne définir que des membres statiques dans une classe en c++ ou .Net 1.1, mettre son constructeur en privé et zou :)

---

Rien ne t'empéchait de quand même mettre des champs ou méthodes non static...
L'avantage de l'utilisation d'une classe statique est que le compilateur peut vérifier qu'aucun membre d'instance n'a été ajouté par erreur. Le compilateur garantira que les instances de cette classe ne peuvent pas être créées.
De plus les classes statiques sont sealed et ne peuvent par conséquent pas être héritées (chose que tu devais spécifier de toi même avec une classe non static).

Citation:

---

c'est juste que son unique instance est créée quelque part entre le début de l'appli et le premier appel à un membre

---

absolument pas, aucune instance n'est jamais créée ! Ce n'est pas nécessaire, puisque toutes les méthodes sont statiques et n'ont pas le paramètre "this" (implicite dans les méthodes d'instance)

Elle n'ont pas d'instance au sens propre du terme.

Une instance suppose un cadre d'objet en mémoire, avec des références nécessaires, lors de l'exécution, qui englobe tout le bloc mémoire alloué aux membres. En réalité dans une classe statique, il n'y a pas de cadre d'objet, car tu n'a pas d'instance, aucun dynamisme, pas besoin de savoir à quelle instance ni comment y accèder.
C'est le même procédé que si tu développe hors objet en C++ ou que tu fait du C, quand les membres sont alloués en mémoire, ils le sont à l'initialisation du programme dans le segment de données à une adresse fixe. (pas dans le tas)
Dans ce cas tu ne peux pas parler d'objet, d'instance, meme unique gérée par le compilateur, car tu ne sais pas non plus dans quel ordre les champs vont être réellement placé à la compilation. D'autres concepts inhérent à la représentation réelle en mémoire entres en jeux et font qu'on ne peut pas parler d'instance, mais ca devient hors sujet si on entre trop dans le détail.

C'est exactement le meme principe que les champs static d'une classe, à ceci près que là c'est pour toute la classe.

Ce concept de classe statique n'existe pas qu'en .NET (C#), et dans les langages qui l'autorise, on voie très clairement, quand on sait comment fonctionne un compilateur objet, ce qui se passe entre les classes statiques et les classes "normales", pour que ce soit du Natif.
Une des raisons des classes static de C#, provient de son héritage C++.

En fait une classe statique est plus ou moins équivalente au concept de Module en VB... d'ailleurs je ne sais pas si ça existe encore en VB.NET ?

Citation:

---

Envoyé par tomlev

absolument pas, aucune instance n'est jamais créée ! Ce n'est pas nécessaire, puisque toutes les méthodes sont statiques et n'ont pas le paramètre "this" (implicite dans les méthodes d'instance)

---

Disons que je me suis mal exprimé. Simplement, comme on peut accéder à ses membres comme on accèderait à par exemple MonSingleton.Instance.Membre, on peut voir ça, d'un point de vue utilisation (et non pas d'un point de vue compilo, on est d'accord :) ), comme une instance unique générée automatiquement.

Tournons la question de ce thread autrement : à part imposer plus de rigueur en normalisant une certaine pratique, qu'amènent les classes statiques qui ne soient pas déjà simulable en C++ / .Net 1 ? D'après la MSDN, pas grand chose :

Creating a static class is therefore much the same as creating a class that contains only static members and a private constructor. A private constructor prevents the class from being instantiated.

The advantage of using a static class is that the compiler can check to make sure that no instance members are accidentally added. The compiler will guarantee that instances of this class cannot be created.

Static classes are sealed and therefore cannot be inherited. Static classes cannot contain a constructor, although it is still possible to declare a static constructor to assign initial values or set up some static state. For more information, see Static Constructors (C# Programming Guide).

Citation:

---

Il me semblait avoir lu quelque part sur ce site que le concept de classe statique est propre à C#, et n'existe pas en .Net. Tel que je le comprends, elle n'a rien de virtuel : c'est juste que son unique instance est créée quelque part entre le début de l'appli et le premier appel à un membre.

---

Donc instance unique ou pas d'instance après compilation ? :roll:

Citation:

---

Envoyé par maa

Donc instance unique ou pas d'instance après compilation ? :roll:

---

Pas d'instance. Juste une notation qui explicite bien que la classe ne peut être instanciée, ne comporte que des membres statiques, et dont un bout de code se déclenchera avant tout appel à un de ses membres : le constructeur.

Ok pour nous pas d'instance, mais est ce que au niveau de l'IL une instance est réellement crée ?

Citation:

---

Envoyé par tomlev

En fait une classe statique est plus ou moins équivalente au concept de Module en VB... d'ailleurs je ne sais pas si ça existe encore en VB.NET ?

---

+1
Oui ça existe toujours en VB.NET. .... Malheureusement.

Citation:

---

Envoyé par maa

Ok pour nous pas d'instance, mais est ce que au niveau de l'IL une instance est réellement crée ?

---

Pas d'instance à ma connaissance.

Citation:

---

Envoyé par Keihilin

"L'inlining" est une optimisation utilisée par le compilateur.

Pour résumer on peut dire que l'inlining, c'est le remplacement d'un appel de fonction par une copie de son corps.

Les avantages sont nombreux, les surcoûts de l'appel sont évités : les instructions call et return, la sauvegardes des registres, le passage de paramètres et l'ajustement de la pile n'ont plus lieu d'être.

Il convient par contre de trouver un juste milieu car la forte expansion du code peut conduire à une dégradation des performances.

---

On peut agir manuellement sur le code pour dire qu'une méthode est inline ou pas? (Comme en C++). Si oui comment?
Sinon quelles sont les autres critères qui peuvent rendre une méthode de classe inline?
Je pensais que seul les propriétés étaient inline en .NET

Salut,

en IL non plus, il n'y a pas d'instance. De plus, il existe des instruction specifique pour les membres statiques. Un exemple 'bateau' pour comparer :

Code:

---

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 38 39 40 41 42 43

using System; using System.Collections.Generic; using System.Linq; using System.Text;   namespace ConsoleApplication1 { class Program { static void Main(string[] args) { string str = "Salut !";   StaticClass.Display(str);   new InstanceClass().Display(str); } }   public static class StaticClass { static string str;   public static void Display(string s) { str = s; Console.WriteLine(str); } }   public class InstanceClass { string str;   public void Display(string s) { str = s; Console.WriteLine(str); } }     }

---

Donc en gros deux classes faisant la meme chose, la premiere statiquement, l'autre etant un objet. En IL, le Main nous donnera ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

.method private hidebysig static void Main(string[] args) cil managed { .entrypoint .maxstack 2 .locals init ( [0] string str) L_0000: nop L_0001: ldstr "Salut !" L_0006: stloc.0 L_0007: ldloc.0 L_0008: call void ConsoleApplication1.StaticClass::Display(string) L_000d: nop L_000e: newobj instance void ConsoleApplication1.InstanceClass::.ctor() L_0013: ldloc.0 L_0014: call instance void ConsoleApplication1.InstanceClass::Display(string) L_0019: nop L_001a: ret }

---

On voit bien que dans le cas static, il n'y aucune creation d'instance, et que l'on appelle directement la methode Display. Dans le second, il y a d'abord un newobj puis l'appel concret. Dans le corps du Display Static, on trouve :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

.method public hidebysig static void Display(string s) cil managed { .maxstack 8 L_0000: nop L_0001: ldarg.0 L_0002: stsfld string ConsoleApplication1.StaticClass::str L_0007: ldsfld string ConsoleApplication1.StaticClass::str L_000c: call void [mscorlib]System.Console::WriteLine(string) L_0011: nop L_0012: ret }

---

En fait, les instructions stsfld et ldsfld sont des instructions specialisées dans la manipulation des champs statiques. Donc ici, on enregistre le premier argument dans le champs static str (ldarg.0 et stsfld) puis on passe le champ static sur le stack (ldsfld) et on l'affiche par un CW (call ...).

Pour la methode d'instance :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

.method public hidebysig instance void Display(string s) cil managed { .maxstack 8 L_0000: nop L_0001: ldarg.0 L_0002: ldarg.1 L_0003: stfld string ConsoleApplication1.InstanceClass::str L_0008: ldarg.0 L_0009: ldfld string ConsoleApplication1.InstanceClass::str L_000e: call void [mscorlib]System.Console::WriteLine(string) L_0013: nop L_0014: ret }

---

c'est la meme idée (les deux methodes faisant la meme chose), mais il faut jouer avec une reference supplementaire, le pointeur vers this (qui est en fait le premier argument de la methode dans les objets, ce qui explique que le premier argument d'une methode d'instance est à l'index 1 et non 0 comme precedemment). En effet les instructions stfld et ldfld attendent deux choses sur le stack, la reference vers l'objet en question (this ici) et la nouvelle valeur (pour stfld du moins).

Enfin pour la structure des classes en langage IL, une classe static est presenté comme suit :

Code:

---

1 2	.class public abstract auto ansi sealed beforefieldinit StaticClass extends [mscorlib]System.Object

---

la classe, pour nous static, est pour le compilateur abstract et sealed (ce qui est impossible à specifier pour une classe => erreur compilateur), et de plus, le compilateur ne generera pas de constructeur par defaut, ce qu'il a fait pour la classe d'instance ci-dessus.

En conclusion, meme en IL, avec une classe static, tu es sur qu'aucune instance de ce type ne sera jamais créé, ou utilisée en classe de base (pas de .ctor, sealed, abstract)


Pour revenir au sujet du thread, les classes statics, je les utilise pour definir des constantes, ou pour "enfermer" des methodes p/invokées (ce que fait Microsoft dans son framework d'ailleurs pour tout les appels de ce type). Mais le probleme des classes statics, c'est que tu ne peux pas facilement controler la durée de vie de ses membres contrairement à une instance qui peut implementer IDisposable, donc j'evite de tenir des ressources qui pourrait etre amené à etre disposées ou qui auraient une durée de vie plus courte que le programme, dans des elements statics.

Edit ; @ Abelman

Apparement, on ne peut pas jouer par instructions pour forcer un inlining en C#, mais Microsoft donne quand meme une liste pour savoir si une methode sera inlinée :

Citation:

---

Methods that are greater than 32 bytes of IL will not be inlined.

Virtual functions are not inlined.

Methods that have complex flow control will not be in-lined. Complex flow control is any flow control other than if/then/else; in this case, switch or while.

Methods that contain exception-handling blocks are not inlined, though methods that throw exceptions are still candidates for inlining.

If any of the method's formal arguments are structs, the method will not be inlined.

---

NB : ca date de 2003, donc peut etre est-ce different maintenant.

Moi un truc m'embête lorsque vous dites pas d'instance. Cela voudrait dire que les valeurs des variables de la classe static ne sont pas stockées en mémoire mais dans un fichier binaire et qu'on le lirait lorsque l'on veut récupérer une de ces valeurs ?
Dans ce cas la le code serait stockées dedans également, puis au moment de l'utilisation d'une méthode, il serait lu, compilé, puis interprété ?

Citation:

---

Envoyé par abelman

On peut agir manuellement sur le code pour dire qu'une méthode est inline ou pas? (Comme en C++). Si oui comment?
Sinon quelles sont les autres critères qui peuvent rendre une méthode de classe

---

Je ne pense pas que l'on puisse agir directement sur l'inlining...Le compilateur utilise une heuristique un peu complexe pour choisir les méthodes candidate à "l'inlining".

Ce que je sais :

• Les méthodes dont l'IL fait plus de 32 bytes ne sont pas candidates.
• Les méthodes virtuelles ne sont pas candidates.
• Les méthodes avec un contrôle de flux complexe ne sont pas candidates.
• Les méthodes comportant un block de gestion d'exception ne sont pas candidates. (mais les méthodes pouvant lever une exception peuvent l'être).
• Les méthodes ayant un struct comme paramètre ne sont pas candidates.

Donc non, il n'y a pas que les propriétés qui sont "inlinées", mais elles sont effectivement des candidates privilègiées.

Certains critères qui excluent "l'inlining" peuvent paraître limites, et on se dit que ça ne laisse pas beaucoup de candidats, mais il ne faut pas oublier que l'on parle d'un compilateur JIT et qu'il faut bien trouver un compromis entre sa vitesse d'exécution et les optimisation qu'il peut faire...

Précision : j'avais cherché ces informations il y a un bon moment déjà, et du coup je certifie leur pertinence sur le fx 1.1, mais il est possible que les choses aient un peu changé sur le 2.0 et le 3.0 !

Citation:

---

On voit bien que dans le cas static, il n'y aucune creation d'instance

---

Euh... perso moi je vois rien du tout ! Mais merci pour ce petit cours de MSIL, ça me rappelle le bon vieux temps de l'assembleur... ;)

Citation:

---

Moi un truc m'embête lorsque vous dites pas d'instance. Cela voudrait dire que les valeurs des variables de la classe static ne sont pas stockées en mémoire mais dans un fichier binaire et qu'on le lirait lorsque l'on veut récupérer une de ces valeurs ?
Dans ce cas la le code serait stockées dedans également, puis au moment de l'utilisation d'une méthode, il serait lu, compilé, puis interprété ?

---

Oula, pas du tout... les valeurs sont bien stockées en mémoire, et n'ont d'existence qu'au cours de l'éxécution du programme. D'ailleurs la portée des membres statiques d'une classe est limitée à l'application : si tu lances 2 programmes qui appellent tous les 2 Process.GetCurrentProcess() (par exemple), le résultat ne sera pas le même, heureusement !

Merci SirJulio et Keihilin ;-)

Citation:

---

Envoyé par ced600

Moi un truc m'embête lorsque vous dites pas d'instance. Cela voudrait dire que les valeurs des variables de la classe static ne sont pas stockées en mémoire mais dans un fichier binaire et qu'on le lirait lorsque l'on veut récupérer une de ces valeurs ?
Dans ce cas la le code serait stockées dedans également, puis au moment de l'utilisation d'une méthode, il serait lu, compilé, puis interprété ?

---

Pourquoi stockées dans un fichier?
Elles sont stockées en mémoire à une adresse qui n'est "liée" à aucune instance si je peux me permettre de parler ainsi.
Exactement comme serait stockée une variable globale en C.

Citation:

---

Envoyé par ced600

Moi un truc m'embête lorsque vous dites pas d'instance. Cela voudrait dire que les valeurs des variables de la classe static ne sont pas stockées en mémoire mais dans un fichier binaire et qu'on le lirait lorsque l'on veut récupérer une de ces valeurs ?
Dans ce cas la le code serait stockées dedans également, puis au moment de l'utilisation d'une méthode, il serait lu, compilé, puis interprété ?

---

Salut,

c'est juste que le champs, methodes ou autres n'est lié à aucune instance, mais existe dans le type en tant que tel. Comme le dirait le standard du CLI :

Citation:

---

Fields can be marked as static, indicating that the field is not part of values of the type but rather a location associated with the type as a whole. Locations for the static fields are created when the type is loaded and
initialized when the type is initialized.

Fields not marked as static define the representation of a value of a type by defining the substructure of the value (see §8.4.1). Locations for such fields are created within every value of the type whenever a new value is
constructed. They are initialized during construction of the new value. A non-static field of a given name is always located at the same place within every value of the type.

---

Si tu preferes, il existe une initialisation pour tous les types que tu utilises, et independemment de toutes creations d'instance de ce type. Donc les valeurs placées en static, sont stockés dans la representation du type lui-meme et initialisé avant toute utilisation par le cctor. (et par extension est partagé par toutes les instances de ce type).

Citation:

---

Pourquoi stockées dans un fichier?
Elles sont stockées en mémoire à une adresse qui n'est "liée" à aucune instance si je peux me permettre de parler ainsi.
Exactement comme serait stockée une variable globale en C.

---

En effet j'essayé d'imaginer où cela pouvait être stocké.
Pour moi une instance d'une classe, cela veut dire que l'on a une petite zone mémoire représentant l'objet.
Alors quand j'ai lu : classe static ne possède pas d'instance, j'en ai conclu pas de case mémoire.
Bon assez basique comme résonnement, mais bon si les données sont bien stocké en mémoire, alors c'est comme une sorte d'instance unique pour tout le programme mais que l'on ne peut pas appeller instance :aie: .
Je comprends mieux le problème et la comparaison avec le singleton.

Citation:

---

Si tu preferes, il existe une initialisation pour tous les types que tu utilises, et independemment de toutes creations d'instance de ce type. Donc les valeurs placées en static, sont stockés dans la representation du type lui-meme et initialisé avant toute utilisation par le cctor. (et par extension est partagé par toutes les instances de ce type).

---

Ok je comprends, c'est la différence avec le singleton.
Bref on met les valeurs dans une case mémoire partagé par tout le monde que cela soit visible de toutes classes comme un type de données.
En même temps je me demande du coup si ce n'est pas plus facile d'accés pour un pirate qui essayerais de pirater ton application, comme les variables globales en C ?

Citation:

---

je me demande du coup si ce n'est pas plus facile d'accés pour un pirate qui essayerais de pirater ton application, comme les variables globales en C

---

Je me demande où tu as pêché ça... les variables globales sont pas plus faciles à pirater que les autres ! Ce serait même plutot le contraire, du moins dans le cas d'une attaque par buffer overflow.

Citation:

---

Envoyé par tomlev

Je me demande où tu as pêché ça... les variables globales sont pas plus faciles à pirater que les autres ! Ce serait même plutot le contraire, du moins dans le cas d'une attaque par buffer overflow.

---

Hum... désolé je ne suis pas spécialiste dans le domaine, j'ai juste encore confiance en mes anciens professeurs qui ne cessaient de répéter qu'une variable globale est un "cadeau" pour les pirates. Bien sur ils se gardent de nous dire pourquoi :aie: .

je suis pas non plus spécialiste du hacking...
moi aussi mes profs disaient de pas utiliser de variables globales, mais c'etait plutot parce que ce n'etait pas "propre"...

Citation:

---

Envoyé par tomlev

je suis pas non plus spécialiste du hacking...
moi aussi mes profs disaient de pas utiliser de variables globales, mais c'etait plutot parce que ce n'etait pas "propre"...

---

Je pense aussi, cependant sans grande certitude n'etant pas un adepte du cracking, ceci dit, je pense que faire mumuse avec le memoire d'un process managé à la vue de l'usine à gaz qu'est .Net, ca doit pas etre de tout repos comparé au C. =p

Citation:

---

Envoyé par SirJulio

Salut,
Comme le dirait le standard du CLI :
Fields can be marked as static, indicating that the field is not part of values of the type but rather a location associated with the type as a whole. Locations for the static fields are created when the type is loaded and
initialized when the type is initialized.

---

Et quand le type est-il chargé en mémoire, lors de sa première utilisation dans l'application je suppose.

Merci d'avance.
Bye

Salut,

si tu parles du chargement concret (lire l'assembly) du type, je suppose que cela se produit au lancement de l'application (quand la CLR va lire les metadatas et decouvrir ainsi les types, modules et assemblies). Si tu veux parler de l'initialisation, alors oui, tu es sur que les types statics seront initialisés, avant tout appel à un membre static de la classe, par le cctor. D'ailleurs, il y a certaines differences à noter entre le fait d'initialiser par un constructeur static explicite et d'initialiser les champs statics inline, notamment en ce qui concerne les types instanciables et possedant des champs statics. Plus de precisions sur cet article.