Variable und Instanz einer Klasse mit Gültigkeit für die gesamte Klasse
Hartmut Callies
ich habe zwei Fragen zum richtigen Vorgehen in C#.
In einer Klasse, und nur innerhalb dieser Klasse, benötige ich eine globale
Variable.
Somit will ich das Ergebnis der einen Methode auch in anderen Methoden
dieser Klasse nutzen bzw. auswerten.
In VB.NET war es so:
Public Class clsTest
Private strOrderNumber As String = ""
Wie ist die richtige Vorgehensweise in C#?
In einer Klasse (clsBeispiel) will ich die Methode Prüfen aus der Klasse
clsTest aufrufen.
Dazu erstelle ich eine Instanz: clsTest objTest = new clsTest();
Jetzt habe ich Zugriff auf die Methode Prüfen: objTest.Prüfen ...
Will ich die Methode Prüfen von der Klasse clsTest in mehreren Methoden
innerhalb der Klasse clsBeispiel nutzen,
dann müsste ich in jeder Methode eine Instanz erstellen. Gibt es nicht die
Möglichkeit eine Instanz für die
gesamte Klasse zu erstellen, so dass jede Methode dieser Klasse darauf
zugreifen kann?
Danke für Eure Hilfe.
Hartmut Callies
Martin Honnen
> In einer Klasse, und nur innerhalb dieser Klasse, benötige ich eine
> globale Variable.
> Somit will ich das Ergebnis der einen Methode auch in anderen Methoden
> dieser Klasse nutzen bzw. auswerten.
> In VB.NET war es so:
> Public Class clsTest
> Private strOrderNumber As String = ""
> Wie ist die richtige Vorgehensweise in C#?
So die Variable nur genau einmal pro Klasse existieren soll, würde ich
in VB.NET Shared erwarten und in C# static, siehe dazu "statische
Member" in http://msdn.microsoft.com/de-de/library/79b3xss3.aspx
--
Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/
Nicolas Pavlidis
Hartmut Callies wrote:
> Hallo,
> ich habe zwei Fragen zum richtigen Vorgehen in C#.
>
> In einer Klasse, und nur innerhalb dieser Klasse, benötige ich eine
> globale Variable.
> Somit will ich das Ergebnis der einen Methode auch in anderen Methoden
> dieser Klasse nutzen bzw. auswerten.
> In VB.NET war es so:
> Public Class clsTest
> Private strOrderNumber As String = ""
> Wie ist die richtige Vorgehensweise in C#?
private string strOrderNumber = "";
:-)
>
> In einer Klasse (clsBeispiel) will ich die Methode Prüfen aus der Klasse
> clsTest aufrufen.
> Dazu erstelle ich eine Instanz: clsTest objTest = new clsTest();
> Jetzt habe ich Zugriff auf die Methode Prüfen: objTest.Prüfen ...
> Will ich die Methode Prüfen von der Klasse clsTest in mehreren Methoden
> innerhalb der Klasse clsBeispiel nutzen,
> dann müsste ich in jeder Methode eine Instanz erstellen. Gibt es nicht
> die Möglichkeit eine Instanz für die
> gesamte Klasse zu erstellen, so dass jede Methode dieser Klasse darauf
> zugreifen kann?
Vielleicht verstehe ich dein Problem falsch aber:
public class clsBeispiel
{
private clsTest theInstance = new clsTest();
public void MethodA()
{
theInstance.Prüfe();
}
public void MethodB()
{
theInstance.Prüfe();
}
}
Ist immer die gleiche instanz innerhalb des Objktes, und jede Methode
innerhalb der Klasse kann auf diese instanz zugreifen.
Wenn du wirklich *eine* Inanz von clsTest für alle Objekte der Klasse
willst, dann war Martin wohl besser im Raten mit static :-).
HTH && LG
Nicolas
Frank Dzaebel
wenn "Shared" gemeint gewesen wäre, hätte
er nicht folgendes schreiben dürfen:
Public Class clsTest
Private strOrderNumber As String = ""
das nun mal keine Shared Variable ist.
_____
Dann noch kurz für Hartmut:
Soetwas wie "clsKlasse" "strOrderNumber"
schreiben wir hier in C# auch eher nicht. Und bitte wenigstens
Klassennamen gross schreiben. Es wird
empfohlen, die ungarische Notation nicht zu verwenden
Gute Grundrichting ist:
[Allgemeine Benennungskonventionen]
http://msdn.microsoft.com/de-de/library/ms229045.aspx
(-> "Verwenden Sie nicht die ungarische Notation.")
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Nicolas Pavlidis
Frank Dzaebel wrote:
> wenn "Shared" gemeint gewesen wäre, hätte
> er nicht folgendes schreiben dürfen:
>
> Public Class clsTest
> Private strOrderNumber As String = ""
>
> das nun mal keine Shared Variable ist.
Ich habe das static (oder shared) auch nicht auf diesen string bezogen
(ich denke Martin auch nicht) sondern auf diese Instanz von clsTest die
ja in jeder Methdoe einer anderen Klasse verwendbar sein sollte.
Ich habe das static eigentlich nur erwähnt weil der OP dauernt von
Klassen geredet hat nicht von Objekten.
> _____
>
> Dann noch kurz für Hartmut:
>
> Soetwas wie "clsKlasse" "strOrderNumber"
> schreiben wir hier in C# auch eher nicht. Und bitte wenigstens
> Klassennamen gross schreiben. Es wird
> empfohlen, die ungarische Notation nicht zu verwenden
> Gute Grundrichting ist:
>
> [Allgemeine Benennungskonventionen]
> http://msdn.microsoft.com/de-de/library/ms229045.aspx
> (-> "Verwenden Sie nicht die ungarische Notation.")
Jep :-). Ich wollte nur keine weitere grundsatzdiskusion hier auslösen :-D.
LG
Nicolas
Frank Dzaebel
> Ich habe das static (oder shared) auch nicht auf diesen string bezogen
> (ich denke Martin auch nicht) sondern auf diese Instanz von clsTest
Eine Shared class gibt es ja in VB.NET AKAIK nicht.
Shared Variablen/Instanzen (von Klassen) schon.
_______
> die ja in jeder Methdoe einer anderen Klasse verwendbar sein sollte.
Er sagt:
"in anderen Methoden *dieser* Klasse nutzen bzw. auswerten."
an anderer Stelle:
"Methode 'Prüfen' von der Klasse clsTest in mehreren
Methoden innerhalb der Klasse clsBeispiel nutzen"
Wenn letzterer Satz eher gemeint wäre, dann
sind die gängigen Möglichkeiten unter C# über:
- statischen Klassen oder
- dem 'Singleton Pattern' oder
- der Übergabe der gemeinsamen Instanz in Konstruktoren (o.ä.)
haben.
Die "Properties.Settings" sind ein Beispiel, wo sich der
OP dies abschauen kann. Aber auch hier einige Links
aus unserer Gruppe:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/c0daf368896f2bd0
________________
> > [Allgemeine Benennungskonventionen]
> > http://msdn.microsoft.com/de-de/library/ms229045.aspx
> > (-> "Verwenden Sie nicht die ungarische Notation.")
>
> Jep :-). Ich wollte nur keine weitere grundsatzdiskusion hier auslösen :-D.
Ach, die müsste man auch nicht mitmachen.
Ein paar kleine Hinweise sind IMHO "ab und an"
mal ganz angebracht, gerade bei Umsteigern.
ciao Frank
--
Dipl. Inf. Frank Dzaebel [MCP, MVP C#]
http://Dzaebel.NET
Harald M. Genauck
So wie ich es aus der Sicht der direkten Übertragung von VB nach C#
sehe, trifft die erste Antwort von Nicolas genau zu, in beiden Teilen.
Mit "Shared" (VB) oder "static" (C#) hat Deine Frage überhaupt nichts
zu tun - lass Dich da nicht verwirren.
Viele Grüße
Harald M. Genauck
"VISUAL STUDIO one" - http://www.visualstudio1.de (Chefredakteur)
"ABOUT Visual Basic" - http://www.aboutvb.de (Herausgeber)
Harald M. Genauck
> Eine Shared class gibt es ja in VB.NET AKAIK nicht.
Die gibt es - heißen nur anders, nämlich "Module".
Frank Dzaebel
> So wie ich es aus der Sicht der direkten Übertragung von VB nach C#
> sehe, trifft die erste Antwort von Nicolas genau zu, in beiden Teilen.
> Mit "Shared" (VB) oder "static" (C#) hat Deine Frage überhaupt nichts
> zu tun - lass Dich da nicht verwirren.
ich glaube, Du hast:
a) die Frage von Hartmut nicht vollständig gelesen,
b) mein und Nicolas' Posting, in dem ich/Nicolas erklären,
in welchem Fall man mit static unter C# arbeiten kann,
(nicht muss) nicht richtig gelesen.
Frank Dzaebel
> > Eine Shared class gibt es ja in VB.NET AKAIK nicht.
>
> Die gibt es
Nein.
*aber* es gibt Module, die diese Funktion ausüben.
In C# gibt es zum Beispiel eine "static class".
________
So einfach mal für Nicolas wiederholt:
Harald M. Genauck
>> > Eine Shared class gibt es ja in VB.NET AKAIK nicht.
>>
>> Die gibt es - heißen nur anders, nämlich "Module".
> Nein.
>
> *aber* es gibt Module, die diese Funktion ausüben.
> In C# gibt es zum Beispiel eine "static class".
Und was willst Du damit anderes als ich sagen?
Das C#-Schlüsselwort "static" entspricht in VB.NET generell dem
Schlüsselwort "Shared", mit gleicher Funktionalität.
(siehe auch:
http://www.dotnetspider.com/forum/ViewForum.aspx?ForumId=39486)
Eine "static class" aus C# wäre in VB.NET eine "Shared Class". VB.NET
erlaubt jedoch diese Schlüsselwortkombination nicht. Statt dessen
entspricht ein "Module" in VB.NET funktional einer C#-"static class" -
mit lediglich dem kleinen syntaktischen Unterschied, dass in VB.NET die
Methoden eines Modules auch ohne den "Klassen"- AKA: Modulenamen als
Qualifizierer aufgerufen werden können.
Harald M. Genauck
>> So wie ich es aus der Sicht der direkten Übertragung von VB nach C#
>> sehe, trifft die erste Antwort von Nicolas genau zu, in beiden
>> Teilen.
>> Mit "Shared" (VB) oder "static" (C#) hat Deine Frage überhaupt
>> nichts
>> zu tun - lass Dich da nicht verwirren.
> ich glaube, Du hast:
>
> a) die Frage von Hartmut nicht vollständig gelesen,
Doch, habe ich sehr wohl.
> b) mein und Nicolas' Posting, in dem ich/Nicolas erklären,
> in welchem Fall man mit static unter C# arbeiten kann,
> (nicht muss) nicht richtig gelesen.
Ob man mit "static" unter C# arbeiten kann, war nicht Hartmuts Frage.
Er hatte in VB.NET ein privates Instanzfeld (oder auch
"Instanzvariablen") - und das geht in C# genau so, wie Nicolas es
dargestellt hat.
Die Verwendung einer weiteren Klasseninstanz, auf die in einem solchen
privaten Instanzfeld eine Referenz abgelegt ist, funktioniert von jeder
beliebigen Instanzmethode der Klasse aus - ebenfalls so, wie Nicolas es
dargestellt hat.
Das geht gleichermaßen in VB.NET wie in C#. In C# braucht es keine
andere Vorgehensweise - und ob eine solche notwendig sei, hatte Hartmut
gefragt.
Hartmut hat auch nichts weiter zur Funktion und zum Zweck dieser
"Prüfklasse" clsTest geäußert. So zum Beispiel ist nicht gesagt, ob
diese nicht ggfs. absichtlich gemeinsam mit ihrer "Mutterklasse"
clsBeispiel instanziert werden soll und ebenfalls je Instanz eigene
Inhalte und Zustände haben soll. In diesem Fall wäre er mit "static"
völlig auf dem Holzweg.
Hartmut verwendet die Formulierungen "Klassen" und "Instanzen"
allerdings etwas ungenau.
Also nochmal klargestellt:
Will Hartmut je Instanz seiner Klasse clsBeispiel eine Instanz von
clsTest verwenden, deren Instanzmethoden von jeder Instanzmethode in
clsBeispiel aufgerufen werden kann, ist die "private"-Deklaration
und -Instanzierung richtig. In diesem Sinne habe ich seine
Fragestellung anhand seines VB.NET-Beispiels verstanden.
Will Hartmut jedoch in allen Instanzen seiner Klasse clsBeispiel nur
eine einzige Instanz von clsTest gemeinsam verwenden, ist die
"static"-Deklaration und -Instanzierung richtig.
Herfried K. Wagner [MVP]
"Harald M. Genauck" <hmg.ng.e...@aboutvb.de> schrieb:
> Das C#-Schlüsselwort "static" entspricht in VB.NET generell dem
> Schlüsselwort "Shared", mit gleicher Funktionalität.
> (siehe auch:
> http://www.dotnetspider.com/forum/ViewForum.aspx?ForumId=39486)
>
> Eine "static class" aus C# wäre in VB.NET eine "Shared Class". VB.NET
> erlaubt jedoch diese Schlüsselwortkombination nicht. Statt dessen
> entspricht ein "Module" in VB.NET funktional einer C#-"static class" - mit
> lediglich dem kleinen syntaktischen Unterschied, dass in VB.NET die
> Methoden eines Modules auch ohne den "Klassen"- AKA: Modulenamen als
> Qualifizierer aufgerufen werden können.
Das ist m.E. ein riesiger Unterschied!
Es gibt einfach keine direkte Entsprechung für eine in C# mit 'static'
markierte Klasse in VB.NET. Genausowenig, wie es eine direkte Entsprechung
zu Modulen aus VB.NET in C# gibt.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Frank Dzaebel
> Will Hartmut jedoch in allen Instanzen seiner Klasse clsBeispiel nur
> eine einzige Instanz von clsTest gemeinsam verwenden, ist die
> "static"-Deklaration und -Instanzierung richtig.
ich denke, so langsam hast Du es verstanden,
das ähnelt jetzt schon sehr unseren Aussagen.
Allerdings kann man eben nicht sagen die
"static Instanziierung" ist dann "richtig", sondern
man hat eben mehr Möglichkeiten - ruhig nochmal
wiederholt:
- statischen Klassen oder
- dem 'Singleton Pattern' oder
- der Übergabe der gemeinsamen Instanz in Konstruktoren (o.ä.)
sollte man jetzt einfach so stehen lassen.
Sonst wird der OP noch vollends verwirrt.
Immerhin hattest Du gesagt, "static (C#)
hätte mit der Frage nichts zu tun".
Günter Prossliner
> Das ist m.E. ein riesiger Unterschied!
Im Endeffekt ist es ein sehr maginaler Unterschied.
Im IL-Code gibt es im Endeffekt weder Modul noch statische Klasse. Beide
Kompiler emittieren auch sehr ändlichen Code:
Beide Kompiler emittieren die Klasse als 'sealed' und ohne Konstruktor. Die
Members werden klarerweise ebenfalls als 'static' emittiert.
csc emitiert zusätzlich noch 'abstract', erzeugt also eine abstract & sealed
class. Dieses Konstrukt ist über validen C# Code nicht zu erreichen. So
erkennt der Compiler also auch ob es sich um eine statische Klasse handelt.
vbc emittiert zusätzlich noch ein Attribut
(Microsoft.VisualBasic.CompilerServices.StandardModuleAttribute). Der VB.Net
Kompiler erkennt die statische Klasse also so.
Auf einen niedrigen Ebene (sieht man bei Refernzen zwischen VB und C# Code)
kann man keine Instanzen erstellen weil eben keine Konstruktoren emittiert
werden. Wenn die Deklaration und die (fehlerhafte) Instanzierung innerhalb
einer Sprache erfolgen, hat der jeweilige Kompiler die Möglichkeit eine
"bessere" Fehlermeldung auszugegeben.
> Es gibt einfach keine direkte Entsprechung für eine in C# mit 'static'
> markierte Klasse in VB.NET. Genausowenig, wie es eine direkte
> Entsprechung zu Modulen aus VB.NET in C# gibt.
Praktisch gesehen gibt es keinen Unterschied.
Dass man in VB.Net den Klassen (bzw. eigentlich Modulnamen) nicht
voranstellen muss ist eine Syntaxfrage, und hat mit dem Unterschied 'static
class' vs. 'Module' IMO nichts zu tun.
Übrigens:
Wenn man in einer C# static class mit dem VB StandardModuleAttribute
kompiliert (scheint im Intellisense nicht auf, geht aber trotzdem, Refernez
auf Microsoft.VisualBasic vorausgesetzt), dann kann man diese C# wenn sie in
VB.Net referenziert wird ohne expliziten Klassennamen verwenden :D. Ich bin
aber froh, dass man in C# das angeben muss.
mfg GP
Frank Dzaebel
> Das ist m.E. ein riesiger Unterschied!
> Es gibt einfach keine direkte Entsprechung für eine in C# mit 'static'
> markierte Klasse in VB.NET. Genausowenig, wie es eine direkte
> Entsprechung zu Modulen aus VB.NET in C# gibt.
ja, eine "direkte" Entsprechung ist sicher nicht vorhanden, ACK.
Die Literatur sagt gängigerweise, dass die "Static class" als ein
*grobes* (rough) Pendant für das 'Module' gesehen wird.
Nun, Du als VB.NET Kenner, kannst Du die wichtigsten
Unterschiede hier skizzieren?
Ein paar Dinge die ich kenne, sind u.a.:
[C# Equivalent to VB Modules]
http://tangiblesoftwaresolutions.com/Articles/CSharp%20Equivalent%20to%20VB%20Modules.htm
[What a C# Coder Should Know Before They Write VB - Updated - Leaning Into
Windows]
http://msmvps.com/blogs/kathleen/archive/2008/07/25/what-a-c-coder-should-know-before-they-write-vb-updated.aspx
(-> "A VB module is roughly a C# static class, except it can be used without
naming the class.")
Bzw. natürlich der syntaktische Aspekt:
http://social.msdn.microsoft.com/Forums/en-US/vblanguage/thread/aa2427e3-a57f-4c38-adb9-0496d7e3eb9a/
(-> "You can not have a STATIC CLASS in VB.Net this is *not* *allowed*")
Harald M. Genauck
Was sagen diese Quellen anders und mehr, als ich und Günter schon
längst gesagt haben? Worin liegt ihre besondere Relevanz, dass Du sie
jetzt noch extra anführen zu müssen glaubst?
Der einzige Unterschied, den ich sehe, ist, dass sie es in Englisch
formulieren ...
Harald M. Genauck
>> Das ist m.E. ein riesiger Unterschied!
> Im Endeffekt ist es ein sehr maginaler Unterschied.
Eben... danke für die Untermauerung im technischen Detail.
Aus gegebenem Anlass mal nebenbei (in die Runde) gefragt:
Gibt es irgendeinen Grund, von der Verwendung statischer Klassen
abzusehen?
Herfried K. Wagner [MVP]
"Frank Dzaebel" <Po...@FranksSeite.de> schrieb:
>> Das ist m.E. ein riesiger Unterschied!
>> Es gibt einfach keine direkte Entsprechung für eine in C# mit 'static'
>> markierte Klasse in VB.NET. Genausowenig, wie es eine direkte
>> Entsprechung zu Modulen aus VB.NET in C# gibt.
>
> ja, eine "direkte" Entsprechung ist sicher nicht vorhanden, ACK.
> Die Literatur sagt gängigerweise, dass die "Static class" als ein
> *grobes* (rough) Pendant für das 'Module' gesehen wird.
>
> Nun, Du als VB.NET Kenner, kannst Du die wichtigsten
> Unterschiede hier skizzieren?
Ich beziehe mich besonders auf den automatischen Import in VB. Das ist m.E.
ein substantieller Unterschied zwischen statischen Klassen (ohne dem
entsprechenden VB-Attribut) und Modulen. Zumindest in VB.NET würde man
deshalb nicht in allen Fällen zu Modulen greifen, in denen man in C# eine
statische Klasse benutzt.
Frank Dzaebel
>> ja, eine "direkte" Entsprechung ist sicher nicht vorhanden, ACK.
>> Die Literatur sagt gängigerweise, dass die "Static class" als ein
>> *grobes* (rough) Pendant für das 'Module' gesehen wird.
>>
>> Nun, Du als VB.NET Kenner, kannst Du die wichtigsten
>> Unterschiede hier skizzieren?
>
> Ich beziehe mich besonders auf den automatischen Import in VB. Das
> ist m.E. ein substantieller Unterschied zwischen statischen Klassen
> (ohne dem entsprechenden VB-Attribut) und Modulen. Zumindest in
> VB.NET würde man deshalb nicht in allen Fällen zu Modulen greifen, in
> denen man in C# eine statische Klasse benutzt.
Danke für die Klärung. Kannst Du ein kurzes Beispiel für einen
solchen Fall geben?
Zusätzlich zu den genannten Unterschieden scheint es auch
Unterschiede bzgl. Extension Methods zu geben,
sodass statische C# Klassen z.T. nicht 1:1 funktional in
VB.NET Module überführbar sind (und umgekehrt) :
[Extension Methods in Vb.Net and C# | Habitually Good]
http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Harald M. Genauck
> Zusätzlich zu den genannten Unterschieden scheint es auch
> Unterschiede bzgl. Extension Methods zu geben,
> sodass statische C# Klassen z.T. nicht 1:1 funktional in
> VB.NET Module überführbar sind (und umgekehrt) :
>
> [Extension Methods in Vb.Net and C# | Habitually Good]
> http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Was aber wohl grundsätzlich nichts mit der Verwandtschaft bzw. den
Unterschieden bezgl. "static" und "Module" zu tun hat, sondern mit
der - ja erst später draufgesattelten - offensichtlich
unterschiedlichen Implementierung der Extension-Methods in den
Compilern. Ich sehe jedenfalls keinen Grund, warum eine
Referenzübergabe (siehe Dein Quellenverweis) prinzipiell nicht ebenso
bei einer static-Klasse in C# möglich sollte wie bei einem
VB.NET-Module.
Frank Dzaebel
>> [Extension Methods in Vb.Net and C# | Habitually Good]
>> http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
>
> Was aber wohl grundsätzlich nichts mit der Verwandtschaft
wie gesagt gegen "Verwandschaft" hat hier glaube ich
niemand was. Wir sehen halt nur die Unterschiede
auf vielfältigen Seiten.
Ursprünglich war *mein* Ansinnen auch eher syntaktisch
gemeint, es gibt halt keine Static/Shared class in VB.NET,
sie ist nicht erlaubt.
Jetzt sehe ich aber und so sehen es andere auch,
dass doch noch mehr Unterschiede in verschiedenen
Bereichen bestehen. Ich schliesse mich da also eher dem
VB.NET-Experten Herfried Wagner an:
"Es gibt einfach keine direkte Entsprechung für
eine in C# mit 'static' markierte Klasse in VB.NET.
Genausowenig, wie es eine direkte Entsprechung
zu Modulen aus VB.NET in C# gibt."
Das wird in der Literatur oft ähnlich gesehen, vielleicht
etwas milder ausgedrückt.
Frank Dzaebel
ich hatte eine Sache noch nicht beantwortet ...
> Ich sehe jedenfalls keinen Grund, warum eine
> Referenzübergabe (siehe Dein Quellenverweis) prinzipiell nicht ebenso bei
> einer static-Klasse in C# möglich sollte wie bei einem VB.NET-Module.
Also, wenn Du mir ein Beispiel geben kannst,
wie Du die Extension method des Link-Beispiels
aus meinem Link in einer C# static class funktionsfähig
in gleicher Funktionalität wie in VB.NET implementierts, wäre
ich Dir sehr verbunden :-)
Das geht AFAIK nicht, Du kannst nicht in C# :
ref this Enum theEnum
in der "extension method" benutzen.
Insofern wirst Du bei Aufruf von:
test.FromString("zwei")
in VB die test-Variable ändern, aber
nicht in C#.
Herfried K. Wagner [MVP]
> "Es gibt einfach keine direkte Entsprechung für
> eine in C# mit 'static' markierte Klasse in VB.NET.
> Genausowenig, wie es eine direkte Entsprechung
> zu Modulen aus VB.NET in C# gibt."
Damit meine ich, um das noch einmal klarzustellen, 1:1-Entsprechungen (also
einschließlich aller Seiteneffekte).
Harald M. Genauck
> ich hatte eine Sache noch nicht beantwortet ...
>> Ich sehe jedenfalls keinen Grund, warum eine
>> Referenzübergabe (siehe Dein Quellenverweis) prinzipiell nicht
>> ebenso bei einer static-Klasse in C# möglich sollte wie bei einem
>> VB.NET-Module.
> Also, wenn Du mir ein Beispiel geben kannst,
> wie Du die Extension method des Link-Beispiels
> aus meinem Link in einer C# static class funktionsfähig
> in gleicher Funktionalität wie in VB.NET implementierts, wäre
> ich Dir sehr verbunden :-)
>
> Das geht AFAIK nicht, Du kannst nicht in C# :
>
> ref this Enum theEnum
>
> in der "extension method" benutzen.
> Insofern wirst Du bei Aufruf von:
> test.FromString("zwei")
> in VB die test-Variable ändern, aber
> nicht in C#.
Da ich in C# nicht ganz so fit bin wie Du, frage ich einfach mal
sicherheitshalber zurück:
a) Kann man in C# generell einer Methode einen Enum nicht als
Ref-Parameter übergeben?
b) Kann man in C# einer static-Klasse generell einer Methode einen Enum
nicht als Ref-Parameter übergeben?
c) Kann man in C# in einer static-Klasse einer Extension-Methode einen
Enum nicht als Ref-Parameter übergeben?
Was von den dreien (a, b, c) ist zutreffend?
Wenn a und b zutreffen, und nur c nicht, hätte das Problem mit den
Extension-Methoden folglich nichts mit einem Unterschied von
C#-static-Klassen und VB.NET-Modulen zu tun, sondern mit einer
unterschiedlichen Implementierung bei der ja nachträglich erfolgten
"Draufsattelung" der Extension-Methods in C# oder im C#-Compiler (oder
wo auch immer) gegen deren Implementierung in VB.NET.
Frank Dzaebel
>> Das geht AFAIK nicht, Du kannst nicht in C# :
>> ref this Enum theEnum
>> in der "extension method" benutzen.
>
> [...] Da ich in C# nicht ganz so fit bin wie Du, frage ich einfach mal
> sicherheitshalber zurück:
>
> a) Kann man in C# generell einer Methode einen Enum nicht als
> Ref-Parameter übergeben?
Man *kann* einer (Nicht-Extension) "Methode"
einen "ref MyEnum" als Parameter angeben und der
wird auch geändert:
private void Form1_Load(object sender, EventArgs e)
{
MyEnum me = new MyEnum(); me = MyEnum.Eins;
Test(ref me); MessageBox.Show(me.ToString());
}
private void Test(ref MyEnum me)
{
me = MyEnum.Zwei;
}
enum MyEnum
{
Eins, Zwei, Drei
}
_________________
> b) Kann man in C# einer static-Klasse generell einer Methode einen Enum
> nicht als Ref-Parameter übergeben?
Man *kann* einer statischen Methode in einer statischen
Klasse einen Enum als ref-Parameter übergeben (wie oben
ebenfalls funktional).
static class Test
{
static public void Start()
{
MyEnum me = new MyEnum(); me = MyEnum.Eins;
Testen(ref me);
MessageBox.Show(me.ToString());
}
static void Testen(ref MyEnum me)
{
me = MyEnum.Zwei;
}
enum MyEnum
{
Eins, Zwei, Drei
}
}
________________
> c) Kann man in C# in einer static-Klasse einer Extension-Methode einen
> Enum nicht als Ref-Parameter übergeben?
Man kann das in C# *nicht* (IL-Tricks, dynamisches Emit mal ausgenommen).
Dann müsste man "ref this" etc. schreiben, das geht aber bei "Extension
Methods"
in statischen Klassen in C# nicht. Im ersten Parameter einer
Erweiterungsmethode
sind hier keine weiteren Modifizierer [..] zulässig.
[Compilerfehler CS1101]
http://msdn.microsoft.com/de-de/library/bb384258.aspx
Wenn Du also etwas wie folgendes hast:
public enum MyEnum
{
Eins, Zwei, Drei
}
public static class Extensions
{
public static void FromString(
this MyEnum theEnum, string fromString)
{
theEnum = (MyEnum)Enum.Parse(
theEnum.GetType(), fromString);
}
}
_________
wird beim Aufruf:
MyEnum me = new MyEnum();
me.FromString("Zwei");
MessageBox.Show(me.ToString());
"me" nicht (wie in VB.NET mit ByRef) geändert.