C# - Eine Mischung aus Java und C++?

[EXDW]

DEvent schrieb:

Die Syntax von Properties in C# ist aber schlecht, viel zu viel Schreibarbeit. Wieso Properties nicht einfach wie in Groovy automatisch erzeugt werden, ist mir ein Rätsel.

string Name {get; set;}
ja - verdammt lang -.-

DEvent schrieb:

Für die, die Groovy nicht kennen:
Wenn du ein Attribut hast, kannst du direkt foo.xx = 5; schreiben. Später im Code kannst du dann eine getXx() und setXx() einfügen. Der Code bleibt foo.xx = 5; , aber nun wird die get/set Methode aufgerufen.
http://groovy.codehaus.org/Groovy+Beans

wo ist der vorteil ? man kann die get und set properties auch noch veraendern

public string Name
{
    get
    {
        // do something
        return _name;
    }
    set
    {
        // do something
        _name = value;
    }
}

ist auch kuerzer als noch zusaetzliche get und set methoden zu brauchen

DEvent schrieb:

Ansonsten, dank diesen Properties muss man jede Methode nun großschreiben, damit man Properties von öffentlichen Attributen unterscheiden kann. Irgendwie stört mich das extrem in C#.

du arbeitest mit oeffentlichen variablen? schaem dich!

zudem gibts ja auch die einschraenkungen
public string Name { get; private set; }

und man kann jeden get und set in diesem propertie noch mit custom code versehen (siehe oben) - das geht bei automatisch generierten code nicht [so einfach]

[loks]

Man muß das mal so sehen. Wenn man bei einem neuen Sprachfeature die Vorteile nicht erkennen kann, gibt es zwei Theorien:

1. Man ist unfähig die Vorteile zu erkennen.
2. Das Feature hat keine Vorteile.

Für einige Programmierer scheidet Ansatz 1 grundsätzlich aus, weil Sie die eigene Unfähigkeit nicht akzeptieren können. Für diese Gruppe gilt: Wenn Ich keine Vorteile erkennen kann, dann gibt es keine.

Gute Entwickler akzeptieren zumindest das Fall 1 möglich ist und schlußfolgern daher: Auch wenn ich keine Vorteile erkenne so kann es diese trotzdem geben.

[Jockelx]

hustbaer schrieb:

Die IMO grössten Stärken von C++ gibt es in C# nicht: ... automatische deterministische Finalisierung.

Kann der C++-Destruktor denn mehr als die C# using...dispose-Variante?

[hustbaer]

Jockelx schrieb:

hustbaer schrieb:

Die IMO grössten Stärken von C++ gibt es in C# nicht: ... automatische deterministische Finalisierung.

Kann der C++-Destruktor denn mehr als die C# using...dispose-Variante?

Natürlich.

1. Man schreibt den Destruktor bloss 1x pro Klasse. using() dagegen muss man bei jeder Verwendung schreiben.

2. Destruktoren funktionieren auch für Klassen-Member (Member-Variablen). Das vereinfacht einige Dinge stark, z.B. das schreiben von Konstruktoren (Destruktoren von Member-Variablen wird automatisch aufgerufen wenn der Konstruktor mit einer Exception abgebrochen wird). Oder auch das schreiben von Destruktoren: man muss nicht alle Member selbst "finalisieren".

[Jockelx]

Ich sehe da weiterhin keinen wesentlichen Unterschied - ausser den 'syntaktischen Zucker'.

Man schreibt den Destruktor bloss 1x pro Klasse. using() dagegen muss man bei jeder Verwendung schreiben.

Man schreibt die Dispose-Methode auch nur einmal pro Klasse und das ist ja das, was mit dem Destructor vergleichbar ist.
Die Objekterzeugung muss in ein using gepackt werden - genauso wie ich in C++ darauf
hoffen muss, dass der User nicht einfach ein vielleicht unsicheres 'new irgendwas' macht,
statt smart Pointer oder Stackobjekte zu nehmen.

2. Destruktoren funktionieren auch für Klassen-Member (Member-Variablen). Das vereinfacht einige Dinge stark, z.B. das schreiben von Konstruktoren (Destruktoren von Member-Variablen wird automatisch aufgerufen wenn der Konstruktor mit einer Exception abgebrochen wird). Oder auch das schreiben von Destruktoren: man muss nicht alle Member selbst "finalisieren".

Mmmmh, okay, man kann vergessen Member in der Dispose-Methode zu disposen.
Das ist etwa mehr als syntaktischer Zucker.
Ist die C#-Klasse aber ordentlich programmiert, besteht meiner Meinung nach kein (Sicherheits-)Unterschied zur C++-Klasse bzgl. Finalisierung.

[mogel]

mag vieleicht auch an der Gewohnheit liegen ... mir ist ein Destruktor lieber als die Dispose Methode - weil

delete foo;

sieht eher nach einem Zerstören des Objektes aus als ein

foo.Dispose();

m2c, mogel

[Jockelx]

Hallo mogel,

um das expliziete zerstören geht es aber nicht.
Da ist C++ natürlich nicht besser, nur weil es 'schöner' aussieht.

Ich wollte eher wissen, ob die zweifellos 'schönen' C++ Destruktoren Vorteile
bieten, die ich in C# nur schwer oder gar nicht nachbauen kann.

[Cpp_Junky]

Jo, z.B. die definitive Gewissheit das im Augenblick der Zerstörung der Speicher frei ist. Dispose ist nur so ne Art Vorbereitung und Bereinigung von abhängigen Daten (Dateihandles schliessen etc). Was da wann Speicher-technisch passiert, entscheidet der Garbage Collector.

[hustbaer]

@Jockelx:
Natürlich ist es besser weil es "schöner" aussieht.
"Schöner" heisst in diesem Fall ja dass es a) weniger zu tippen und b) weniger zu lesen ist.

Was "nicht new verwenden" vs. "immer using verwenden" angeht: etwas nicht zu verwenden ist einfach. Etwas immer zu verwenden, speziell wenn es mehr Tippaufwand ist, erfordert wesentlich mehr Disziplin.

Weiters gibt es noch einen Unterschied: in C# muss man immer Zombie-Objekte berücksichtigen. Also Objekte die bereits disposed wurden. Dummerweise gibt es diese Objekte aber noch, und man kann auch noch lustig Funktionen drauf aufrufen. Also muss man in (fast) jeder Funktion einen "if (disposed)" Check einbauen, und ggf. eine ObjectDisposedException werfen.
In C++ kann man relativ einfach Klassen bauen, die keinen "Zombie" Zustand haben. Und kann sich daher auch die "Zombie" Checks sparen.

[Jockelx]

Das 'schöner' bezog sich auf das expliziete löschen, also 'bla.dispose()' vs. 'delete bla'.
Und das ist dann beides gleich schön bzgl. Schreib- und Leseaufwand.
Desweiteren gebe ich dir ja recht; das C++-Destruktor-Konzept ist natürlich schöner als die C# using-dispose-Hampelei - keine Frage.

Den Versuch von C# die automatische deterministische Finalisierung zu Ersetzen,
sehe ich aber trotzdem als durchaus gelungen an.

Zumindest komme ich damit besser klar, als z.B. in Java (was allerdings schon etwas her ist; vielleicht hat sich da ja auch was geändert):

Wenn ich Resourcen sicher freigeben muss, weiss ich wie das relativ einfach zu machen ist.
Damit kann ich erstmal leben.