Question sur les propriétés et la compilation

Bonjour,

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

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

Citation:

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

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

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é

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 !!!

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.

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

Citation:

Envoyé par john.fender

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:

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 :)

Citation:

Envoyé par ZenZiTone

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.

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:

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:

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...

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

Citation:

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 !