[C#] Beginnersfoutje?

[Verwijderd]

Hallo,

Ik ben voor mezelf bezig te kleine programmaatjes aan het schrijven, gewoon voor de fun.

Nu loop je in het begin natuurlijk al gelijk tegen basic dingen, zoals dit:
Dit is de 2e namespace in het script (weet niet of dit uitmaakt, volgens mij niet, maar je weet maar nooit)


namespace belasting{

public class belastingType{

belastingType qBelasting;
qBelasting = new belastingType();

belastingType fBelasting;
fBelasting = new belastingType();


nu krijg ik een melding van invalid token "=" in class, struct or interface member delcaration

Iemand een idee

[BM]

Je mag op die plek geen assignment doen. Of je doet dat direct bij je variabele declaratie, of je doet het in een aparte methode (je constructor bijvoorbeeld).

C#:

namespace belasting
{
    public class belastingType
    {
        belastingType qBelasting = new belastingType();
        belastingType fBelasting = new belastingType();
    }
}

of

C#:

namespace belasting
{
    public class belastingType
    {
        private belastingType qBelasting;
        private belastingType fBelasting;

        public belastingType()
        {
            qBelasting = new belastingType();
            fBelasting = new belastingType();
        }
    }
}

[ Voor 63% gewijzigd door BM op 05-04-2010 11:06 ]

[roy-t]

Dit mag zeer zeker wel, maar niet op twee regels! Het is dan trouwens niet gedefinieerd in welke volgorde alles geinitialiseerd wordt, het wordt wel uitgevoerd voordat de constructor van het object wordt uitgevoerd.

C#:

namespace ConsoleApplication2
{
    class Class1
    {
        Object obj1 = new Object();
        

    }
}

Weet je zeker dat je niet per ongeluk je namespace niet goed opened of dat je in je namespace zelf een variabele aan het maken bent, dat mag inderdaad niet.

(PS met de tags [ code=C# ] kun je dit netjes highlighten).

[ Voor 3% gewijzigd door roy-t op 05-04-2010 11:59 ]

[NickThissen]

Correct me if I'm wrong, maar ik vind het een beetje vreemd om in een klasse BelastingType nog eens twee instances van diezelfde klasse BelastingType aan te maken. Die twee instances maken dan zelf ook weer twee instances aan, en die ook weer, etc. Ik weet niet zeker of het fout zal gaan, maar ik vind het in ieder geval niet logisch.

Daarbij wordt meestal aangeraden om de .NET standaard te volgen en de namen van namespaces en classes met een hoofdletter te beginnen, maar dat is bijzaak.

[BM]

NickThissen schreef op maandag 05 april 2010 @ 13:41:
Correct me if I'm wrong, maar ik vind het een beetje vreemd om in een klasse BelastingType nog eens twee instances van diezelfde klasse BelastingType aan te maken. Die twee instances maken dan zelf ook weer twee instances aan, en die ook weer, etc. Ik weet niet zeker of het fout zal gaan, maar ik vind het in ieder geval niet logisch.

Daarbij wordt meestal aangeraden om de .NET standaard te volgen en de namen van namespaces en classes met een hoofdletter te beginnen, maar dat is bijzaak.

Hoeft niet zo vreemd te zijn, toch? Er zijn genoeg voorbeelden te bedenken van objecten die ook weer een instantie van datzelfde object hebben. Dat het kan, wil niet zeggen dat zo'n object altijd geinitialeerd/gebruikt word

[Verwijderd]

BM schreef op maandag 05 april 2010 @ 13:54:
[...]

Hoeft niet zo vreemd te zijn, toch? Er zijn genoeg voorbeelden te bedenken van objecten die ook weer een instantie van datzelfde object hebben. Dat het kan, wil niet zeggen dat zo'n object altijd geinitialeerd/gebruikt word

In het voorbeeld wat gegeven wordt gebeurt dat dus wel. Het is dus een stukje recursie waar hij nooit uit komt.

[ Voor 6% gewijzigd door Verwijderd op 05-04-2010 13:59 ]

[Phyxion]

BM schreef op maandag 05 april 2010 @ 13:54:
[...]

Hoeft niet zo vreemd te zijn, toch? Er zijn genoeg voorbeelden te bedenken van objecten die ook weer een instantie van datzelfde object hebben. Dat het kan, wil niet zeggen dat zo'n object altijd geinitialeerd/gebruikt word

Hoeft niet vreemd te zijn maar ik betwijfel of TS dit wel zo wil.

[NickThissen]

Ik heb het even getest en het gaat inderdaad mis. Je krijgt een StackOverflowException, wat natuurlijk ook logisch is; het is gewoon een oneindige recursie.

Je kan natuurlijk een klasse een instantie van zichzelf laten hebben, maar je mag die natuurlijk niet in de constructor (of tijdens initialisatie zoals hier) initialiseren, dan kom je er niet meer uit.

[pedorus]

roy-t schreef op maandag 05 april 2010 @ 11:59:
Dit mag zeer zeker wel, maar niet op twee regels! Het is dan trouwens niet gedefinieerd in welke volgorde alles geinitialiseerd wordt, het wordt wel uitgevoerd voordat de constructor van het object wordt uitgevoerd.

Hoe kom je erbij dat de volgorde ongedefinieerd is? Zowel in java als in c# maakt dan de volgorde waarin ze in de class staan uit. Hier een mooi voorbeeld:

quote: http://msdn.microsoft.com/en-us/library/aa645757.aspx

It is possible for static fields with variable initializers to be observed in their default value state. However, this is strongly discouraged as a matter of style. The example

C#:

using System;
class Test
{
   static int a = b + 1;
   static int b = a + 1;
   static void Main() {
      Console.WriteLine("a = {0}, b = {1}", a, b);
   }
}

exhibits this behavior. Despite the circular definitions of a and b, the program is valid. It results in the output

a = 1, b = 2

because the static fields a and b are initialized to 0 (the default value for int) before their initializers are executed. When the initializer for a runs, the value of b is zero, and so a is initialized to 1. When the initializer for b runs, the value of a is already 1, and so b is initialized to 2.

Voor instance members kun je (helaas) this niet gebruiken in c#, maar dan nog maakt de volgorde uit:

quote: http://msdn.microsoft.com/en-us/library/aa645759.aspx

The variable initializers are executed in the textual order in which they appear in the class declaration.

---

Maar voor de rest is wat TS aan het doen is zeer vaag. Een mislukte implementatie van een van de patterns Singleton, Factory, of Prototype ofzo? Of zoekt TS een enum? Of overerving? static? Iets met ontbrekende probleemomschrijving

[roy-t]

@ Pedorus,

Goede vraag, ik dacht dat ooit gelezen te hebben, maar dit blijkt dus niet zo te zijn. Nouja het is iig niet erg .