Discussion :

[john.fender]

Bonjour,

avant toute chose voici un très court code qui contient une classe, une propriété mal codée, et une instanciation :

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
 
using System;
    class Program
    {
        static void Main(string[] args)
        {
            var x = new Test();
        }
        class Test
        {
            public int A
            {
                get
                {
                    return A;
                }
                set
                {
                    A = value;
                }
            }
        }
    }

Ma question, c'est pourquoi Visual Studio 2015 ne me remonte aucune erreur et pourquoi je peux compiler ce code ? En effet, A n'est déclaré nulle part et ce n'est pas une propriété automatique. L'évaluation est faite à l'exécution ?

Merci de votre éclairage.

Cdlt,
John.

EDIT : le détail de l'erreur

An unhandled exception of type 'System.StackOverflowException' occurred in...
The program '...' has exited with code -2147023895 (0x800703e9).

[Pol63]

le code est exécuté à l'exécution oui

après si dans le get on retourne la valeur de la propriété elle même, ce qui ce passe est simple :
la propriété appelle la propriété qui appelle la propriété qui appelle la propriété etc... et donc quand la pile est pleine ca crash
idem pour le set

un void qui ne fait que s'appeler lui même fera crasher pour overflow aussi dès qu'il sera appelé

[MABROUKI]

bonjour

Le compilateur VB.Net par comparaison emet ces 2 messages à la compilation :
"
'warning BC42104: La variable 'A' est utilisée avant qu'une valeur ne lui ait été assignée. Une exception de référence null peut se produire au moment de l'exécution.
'warning BC42026: L'expression appelle de manière récursive la propriété conteneur 'A'."
Curieux quand meme !!!

[john.fender]

Je vais réinstaller VS2015 pour voir, sait on jamais. Comprends encore moins que VB.NET puisse cracher une erreur (cela me paraît logique) et pas C#, même si ce sont 2 implémentations différentes du CLR.

[Pol63]

je trouve en effet que vb.net est plus souvent user friendly que c#

[ZenZiTone]

En effet, A n'est déclaré nulle part et ce n'est pas une propriété automatique.

Ce n'est qu'a moitié vrais. Tu déclares bien A :

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
 
using System;
    class Program
    {
       class Test
        {
            public int A //    <----- ici
            {
                get
                {
                    return A;
                }
                set
                {
                    A = value;
                }
            }
        }
    }

Donc effectivement ton code générera une exception, il n'empêche que A existe, tu peux donc le lire et l'assigner

[john.fender]

Ce n'est qu'a moitié vrais. Tu déclares bien A ...Donc effectivement ton code générera une exception, il n'empêche que A existe, tu peux donc le lire et l'assigner

Une propriété n'est pas un champ, c'est un moyen d'accès sur un champ.

Tout comme le compilateur .Net est parfaitement capable de refuser la compilation pour une méthode qui n'existe pas, il devrait donc me semble t-il refuser une méthode qui met à jour autre chose qu'un champ, et encore plus quand la méthode s'appelle elle même, c'est une récursion sans espoir. VB.NET l'a bien compris puisqu'il ne laisse pas faire !

Je me demande si cela n'est pas interdit comme concept, une méthode qui met à jour une autre méthode, cela me semble contrevenir à sa conception.

[MABROUKI]

re

C'est ce que pense beaucoup de programeurs sur les forums ,car une prop meme ,si elle utilise en coulisse des methods,a pour role de persister des champs internes protégés ....
Les methods Getter & Setter devraient donc "renvoyer" & "setter" les champs prives internes uniquement....
Tel n'est pas le cas du C# compare au VB....

voici l'extrait du code MSIL cree par le Deseambleur IL des Getter et Setter pour CSharp ou le "getter" appelle manifestement recursivement le method "getter"!
code CIL managed CSharp:

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
 
.method public hidebysig specialname instance int32 
        get_A() cil managed
{
  // Code size       12 (0xc)
  .maxstack  1
  .locals init ([0] int32 CS$1$0000)
  IL_0000:  nop
  IL_0001:  ldarg.0  
  IL_0002:  call       instance int32 WinProp.Test::get_A()
  IL_0007:  stloc.0 //pop
  IL_0008:  br.s       IL_000a 
  IL_000a:  ldloc.0
  IL_000b:  ret
} // end of method Test::get_A

et celui du VB.Net!

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
 
 
 
.method public specialname instance int32 
        get_A() cil managed
{
  // Code size       7 (0x7)
  .maxstack  1
  .locals init ([0] int32 A)
  IL_0000:  nop
  IL_0001:  ldloc.0
  IL_0002:  stloc.0
  IL_0003:  br.s       IL_0005
  IL_0005:  ldloc.0
  IL_0006:  ret
} // end of method Test::get_A

bon code...

[john.fender]

Sympa ce petit passage par l'IL, merci

Extrait de la référence C# écrite par ses concepteurs, ici une note de BILL WAGNER

Property accesses look like field accesses to your users—and they
will naturally expect them to act like field accesses in every way, including performance.
If a get accessor needs to do significant work (reading a file or querying a
database, for example), it should be exposed as a method, not a property. Callers
expect that a method may be doing more work.
For the same reason, repeated calls to property accessors (without intervening code)
should return the same value. DateTime.Now is one of very few examples in the framework
that does not follow this advice.

Si je lis bien, une propriété ne devrait avoir que peu de code, sinon c'est une méthode ! Curieux d'avoir laissé cette possibilité, VB.NET est bien plus safe sur ce coup.

Bon code !