Using und globale Variable

SpaceyX · 26. September 2013, 12:00

VB.NET-Quellcode

Public Class Form1
Private f2 As Form2
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
Using f2 As New Form2 With {.Text = "lokal"}
MessageBox.Show((Me.f2 Is Nothing).ToString())
MessageBox.Show((f2 Is Nothing).ToString())
End Using
End Sub
End Class

Sollte nun klar sein. Kopieren, probieren.

sonne75 · 26. September 2013, 12:01

Hier ist nochmal ein Zitat:

Überdeckung

Oben hieß es schon, dass der Name einer Variablen innerhalb ihres Geltungsbereichs eindeutig sein muss. Was bedeutet das aber, wenn es innerhalb einer Klasse eine Variable gibt und in einer Methode eine neue Variable den gleichen Namen bekommt? Dann gilt:

Die lokale Variable überdeckt die Variable aus dem umfassenden Bereich und hat Vorrang.

Ändern wir das vorstehende Beispiel:

VB.NET-Quellcode

string temp = "Ein zweiter Versuch";

for(int x1 = 0; x1 < 10; x1++ )

{

string temp = arr[x1];

}

Innerhalb der Schleife gibt es eine weitere Variable namens temp (und zwar weiterhin in jedem Durchgang eine neue). Innerhalb der Schleife kann aber nicht auf den Wert der außerhalb deklarierten temp-Variablen zugegriffen werden.

de.wikibooks.org/wiki/Arbeiten…n/_Bestandteile/_Variable

fichz · 26. September 2013, 12:09

SpaceyX schrieb:

Sollte nun klar sein. Kopieren, probieren.

Ok nun ergibt es Sinn. Dann ist es aber in meinen Augen ein Bug von Visual Studio (2008 hab grad kein anderes zur Hand), dass die Private p so angezeigt wird als hätte sich eine Referenz auf das gleiche Objekt.

lg

sonne75 · 26. September 2013, 12:10

Wieso soll es ein Bug sein? Es wird eine Variable mit einem Namen angezeigt, der Programmierer sollte schon wissen, was er tut, wenn er schon eine lokale Variable mit dem gleichen Namen wie eine globale verwendet. Dann sollte er auch wissen, wo sie Gültigkeit hat.

fichz · 26. September 2013, 12:13

Ich finde eine IDE sollte eben genau solche Sachen korrekt anzeigen. Ist schon klar, dass ein Programmierer wissen muss was er tut, jedoch verlässt sich dieser auch gerne mal auf seine IDE. Wenn die dann so etwas anzeigt find ich es etwas "verwirrend".

lg

SpaceyX · 26. September 2013, 12:19

@fichz:

Ich weiß schon, was Du meinst. Das ist in der Tat sehr verwirrend. Ist in der 2012er Version genau das Selbe. Darum sollte man eben vermeiden, dass 2 Variablen, die sich den gleichen Scope teilen, die selben Namen haben. Für global deklarierte Variablen nutze ich stets ein "_" als Präfix. Ob es nun ein Bug oder so gewollt ist, kann ich auch nicht beurteilen. Am besten, man begibt sich nicht in eine solche Situation.

Storch · 26. September 2013, 12:40

So ich hab mir das mal ein wenig aufbereitet:

VB.NET-Quellcode

Public Class frm_tests
Private ul As frm_about
Private Sub cbt_usinglocal_Click(sender As Object, e As EventArgs) Handles cbt_usinglocal.Click
'Dim ul As New frm_about
'ul.ShowDialog()
Using ul As New frm_about
ul.ShowDialog()
End Using
End Sub
Private Sub cbt_usingglobal_Click(sender As Object, e As EventArgs) Handles cbt_usingglobal.Click
'ul = New frm_about
'ul.ShowDialog()
Using ul = New frm_about
ul.ShowDialog()
End Using
End Sub
End Class

Ich betrachte jetzt erst mal alles so, als ginge es nicht um das Using sondern um die Deklaration und Verwendung einer Variablen, so wie die auskommentierte Zeilen:

Mit As deklariert man eine Variable als das, was man hinter As angibt. Ohne dem New könnte man wohl sagen, ul fungiert als Platzhalter. Erst die Verwendung des New würde der Privaten ul schon bei der Deklaration einen Wert zuweisen. Also ist die Private ul beim Start meines frm_tests = Nothing.

Zitat aus Hilfe für Shadowing:
Sie können eine Variable ausblenden, indem Sie ein Shadowing für sie durchführen, d. h., indem Sie sie mit einer gleichnamigen Variablen neu definieren.
Genau das passiert nun in cbt_usinglocal_Click . Durch 'Dim ul As New frm_about, wird ul neu definiert, was sozusagen die Private ul außer Kraft gesetzt.
Trotzdem nimmt sie ebenfalls den Wert an, der Lokal zugewiesen wird, was mir duchaus logisch erscheint

in cbt_usingglobal tritt das Shadowing aber nicht in Kraft, denn 'ul = New frm_about ist keine neue Definition der Variable ul ,sondern es wird ihr lediglich ein neuer Wert zugewiesen. Definiert ist sie ja schon durch Private

Ich sehe da keine Fehler in meiner Logik. Ich frage mich jetzt nur, nimmt die Verwendung von Using Einfluss auf die Deklarationen und Wertzuweisungen?????

Ich habe meinen TestCode (Using-Variante) laufen lassen, nach jedem End Using ist die ul wieder Nothing. Gleiches in meiner eigentlichen Anwendung.

Letztlich wird man sich ja auch für eine der beiden Varianten entscheiden. Anderseits.. da der Aufruf eines ShowDialogs keine neuerlichen Aufruf zulässt, solange ein Form durch ShowDialog offen ist, dürfte sich auch eine Mischform obiger Art nicht beißen.

Edith: Ich habe eben Euren letzen Beiträge gelesen.....
Es ging mir nicht ursächlich darum, eine Doppelbelegung von Variablen zu verwenden. Meine Intention war schon: Entweder Global / Oder Lokal. Aber nachdem ich Using mit lokaler Variable angewendet habe, wollte ich halt wissen, wie es mit globaler Variable ist. Aber nicht prinzipiell mit beiden gleichzeitig. Trotzdem eine interessante Diskussion.

fichz · 26. September 2013, 12:43

Ich verwende den selben Präfix. Gerade in Klassen der 2008er wo man die Properties noch ganz schreiben musste, hies die Property p und die Priavate dazu _p.

@Storch: Du benötigst die lokale Variable nicht.
In deinem Code merkst du den Unterschied wenn du ein Me. vor die Variable setzte. Dann wird nämlich die als Private deklarierte ausgewertet, die aber eigentlich Nothing ist. (siehe [VB 2012] Using und globale Variable)

lg

sonne75 · 26. September 2013, 12:46

Storch schrieb:

was sozusagen die Private ul außer Kraft gesetzt.
Trotzdem nimmt sie ebenfalls den Wert an, der Lokal zugewiesen wird, was mir duchaus logisch erscheint

Wie kommst du jetzt darauf? Das passiert eben nicht.

Storch schrieb:

in cbt_usingglobal tritt das Shadowing aber nicht in Kraft, denn 'ul = New frm_about ist keine neue Definition der Variable ul ,sondern es wird ihr lediglich ein neuer Wert zugewiesen. Definiert ist sie ja schon durch Private

Da bin ich mir nicht sicher, ich weiß nicht, ob es einen Unterschied macht.

Storch schrieb:

Ich habe meinen TestCode (Using-Variante) laufen lassen, nach jedem End Using ist die ul wieder Nothing. Gleiches in meiner eigentlichen Anwendung.

Wie schon gesagt, EINE "ul" ist Nothing, SpaceyX hat doch vorhin gezeigt, wie man explizit globale Variable abfragt (mit Me.ul), erst da kannst du sehen, welchen Wert sie hat.

SpaceyX · 26. September 2013, 12:55

@Storch:

Shadowing hat mit dem Thema hier nicht wirklich etwas zu tun. Das gehört in den Bereich Vererbung.

sonne75 · 26. September 2013, 12:58

Storch schrieb:

Aber nachdem ich Using mit lokaler Variable angewendet habe, wollte ich halt wissen, wie es mit globaler Variable ist.

Gut, das hat @SpaceyX:: dann beantwortet:

SpaceyX schrieb:

Using kannst Du nur innerhalb eines Methodenrumpfes verwenden.

@SpaceyX
Doch, in meinem (ersten) Link von MSDN wird es unter Shadowing (internes halt) erklärt.

Storch · 26. September 2013, 13:05

Ich muss jetzt leider außer Haus. Melde mich heute abend wieder

sonne75 · 26. September 2013, 13:05

Storch schrieb:

in cbt_usingglobal tritt das Shadowing aber nicht in Kraft, denn 'ul = New frm_about ist keine neue Definition der Variable ul ,sondern es wird ihr lediglich ein neuer Wert zugewiesen. Definiert ist sie ja schon durch Private

Ich habe es gerade ausprobiert, es ist egal ob du "As" schreibst oder nicht, "Infer On" erledigt es für dich, es wird also in jedem Fall eine neue Variable angelegt.

ErfinderDesRades · 26. September 2013, 15:31

nö - nicht ganz in jedem Fall:

VB.NET-Quellcode

Private frm As New Form
Private Sub AnyMenuItem_Click(ByVal sender As Object, ByVal e As EventArgs) Handles TestToolStripMenuItem.Click
Using frm
frm.ShowDialog()
End Using
Dim b = frm.IsDisposed 'True!
End Sub

So ist die Block-Logik (oder unlogik): Bei

VB.NET-Quellcode

Using frm = New Form

ist frm eine Block-lokale Variable, und bei

VB.NET-Quellcode

Using frm

wird die bereits gegebene frm-Variable verwendet.

Richtig interessant wirds beim For i - Block:

VB.NET-Quellcode

For i = 0 To 22
'...
Next
'MessageBox.Show(i.ToString) 'compile-error, denn i ist nur block-lokal gültig
Dim ii = 0
For ii = 0 To 22
'...
Next
MessageBox.Show(ii.ToString) 'output: 23

Also das Thema ist "Gültigkeitsbereich" (alias "Scope"), und sowohl beim Thema Scope als auch beim Thema Vererbung gibts einen Abschattier-Effekt (Shadowing), was aber jeweils bisserl was anneres bedeutet.

sonne75 · 26. September 2013, 17:26

Es ging aber darum, dass

VB.NET-Quellcode

Using frm As New Form2

und

VB.NET-Quellcode

Using frm=New Form2

unterschiedliches sein sollen, und das ist bei Infer On nicht der Fall (Intellisense zeigt mir bei frm gleich "As Form2" dazu an).

Aber gut zu wissen, dass mit einem

VB.NET-Quellcode

Using frm

dann keine neue Variable angelegt wird (wofür auch immer man das brauchen soll).

Niko Ortner · 27. September 2013, 00:30

Mich wundert's, dass noch niemand auf die Idee gekommen ist, einfach ein Testprogramm zu dekompilieren:

Original

VB.NET-Quellcode

Public Class Program
Private Shared Bar As Foo
Public Shared Sub Main()
Test1()
Test2()
Test3()
End Sub
Private Shared Sub Test1()
Bar = New Foo("Test1")
Bar.DoStuff()
Program.Bar.DoStuff()
Bar.Dispose()
Bar = Nothing
End Sub
Private Shared Sub Test2()
Dim Bar As Foo
Bar = New Foo("Test2")
Bar.DoStuff()
Program.Bar.DoStuff()
Bar.Dispose()
Bar = Nothing
End Sub
Private Shared Sub Test3()
Using Bar = New Foo("Test3")
Bar.DoStuff()
Program.Bar.DoStuff()
End Using
End Sub
Private Shared Sub Test4()
Using Bar As New Foo("Test4")
Bar.DoStuff()
Program.Bar.DoStuff()
End Using
End Sub
Class Foo
Implements IDisposable
Public InternalValue As String
Public Sub New(NewValue As String)
InternalValue = NewValue
End Sub
Public Sub DoStuff()
Console.WriteLine(InternalValue)
End Sub
#Region "IDisposable Support"
Private disposedValue As Boolean ' So ermitteln Sie überflüssige Aufrufe
' IDisposable
Protected Overridable Sub Dispose(disposing As Boolean)
If Not Me.disposedValue Then
If disposing Then
' TODO: Verwalteten Zustand löschen (verwaltete Objekte).
InternalValue = Nothing
End If
' TODO: Nicht verwaltete Ressourcen (nicht verwaltete Objekte) freigeben und Finalize() unten überschreiben.
' TODO: Große Felder auf NULL festlegen.
End If
Me.disposedValue = True
End Sub
' TODO: Finalize() nur überschreiben, wenn Dispose(ByVal disposing As Boolean) oben über Code zum Freigeben von nicht verwalteten Ressourcen verfügt.
'Protected Overrides Sub Finalize()
' ' Ändern Sie diesen Code nicht. Fügen Sie oben in Dispose(ByVal disposing As Boolean) Bereinigungscode ein.
' Dispose(False)
' MyBase.Finalize()
'End Sub
' Dieser Code wird von Visual Basic hinzugefügt, um das Dispose-Muster richtig zu implementieren.
Public Sub Dispose() Implements IDisposable.Dispose
' Ändern Sie diesen Code nicht. Fügen Sie oben in Dispose(ByVal disposing As Boolean) Bereinigungscode ein.
Dispose(True)
GC.SuppressFinalize(Me)
End Sub
#End Region
End Class
End Class

IL

Gekürzt auf's Wesentliche

C-Quellcode

.class Program
{
.field private static Foo Bar
.method public static void Main ()
{
IL_0000: call void Program::Test1()
IL_0005: call void Program::Test2()
IL_000a: call void Program::Test3()
IL_000f: ret
}
.method private static void Test1 ()
{
IL_0000: ldstr "Test1"
IL_0005: newobj instance void Foo::.ctor(string)
IL_000a: stsfld class Foo Program.Bar // Entspricht Zeile 21. Hier wird wie zu erwarten war, die globale Variable verwendet.
IL_000f: ldsfld class Foo Program.Bar
IL_0014: callvirt instance void Foo::DoStuff()
IL_0019: ldsfld class Foo Program.Bar
IL_001e: callvirt instance void Foo::DoStuff() // Logischerweise kein Unterschied zwischen "Bar.DoStuff()" und "Program.Bar.DoStuff()"
IL_0023: ldsfld class Foo Program.Bar
IL_0028: callvirt instance void Foo::Dispose()
IL_002d: ldnull
IL_002e: stsfld class Foo Program.Bar
IL_0033: ret
}
.method private static void Test2 ()
{
// Das ist die lokale Variable aus Zeile 20.
.locals init (
[0] class Foo Bar
)
IL_0000: ldstr "Test2"
IL_0005: newobj instance void Foo::.ctor(string)
IL_000a: stloc.0 // Hier wird die lokale Variable verwendet. Auch wie zu erwarten.
IL_000b: ldloc.0
IL_000c: callvirt instance void Foo::DoStuff() // "Bar.DoStuff()" verwendet die lokale Variable.
IL_0011: ldsfld class Foo Program.Bar
IL_0016: callvirt instance void Foo::DoStuff() // "Program.Bar.DoStuff()" verwendet die globale Variable. Immer noch ganz normal.
IL_001b: ldloc.0
IL_001c: callvirt instance void Foo::Dispose()
IL_0021: ldnull
IL_0022: stloc.0
IL_0023: ret
}
.method private static void Test3 () // Zwischen Test3 und Test4 besteht kein Unterschied (bis auf den String).
{
// Durch Using wird eine lokale Variable deklariert.
.locals init (
[0] class Foo Bar
)
IL_0000: ldstr "Test3"
IL_0005: newobj instance void Foo::.ctor(string)
IL_000a: stloc.0 // Die lokale Variable wird verwendet. Die globale Variable wird nicht angerührt.
.try
{
IL_000b: ldloc.0
IL_000c: callvirt instance void Foo::DoStuff() // Auch hier wird die lokale Variable verwendet.
IL_0011: ldsfld class Foo Program.Bar
IL_0016: callvirt instance void Foo::DoStuff() // "Program.Bar.DoStuff()" verwendet natürlich wieder die globale Variable.
IL_001b: leave.s IL_0027
}
finally
{
IL_001d: ldloc.0
IL_001e: brfalse.s IL_0026
IL_0020: ldloc.0
IL_0021: callvirt instance void [mscorlib]System.IDisposable::Dispose()
IL_0026: endfinally
}
IL_0027: ret
}
.method private static void Test4 ()
{
.locals init (
[0] class Foo Bar
)
IL_0000: ldstr "Test4"
IL_0005: newobj instance void Foo::.ctor(string)
IL_000a: stloc.0
.try
{
IL_000b: ldloc.0
IL_000c: callvirt instance void Foo::DoStuff()
IL_0011: ldsfld class Foo Program.Bar
IL_0016: callvirt instance void Foo::DoStuff()
IL_001b: leave.s IL_0027
}
finally
{
IL_001d: ldloc.0
IL_001e: brfalse.s IL_0026
IL_0020: ldloc.0
IL_0021: callvirt instance void [mscorlib]System.IDisposable::Dispose()
IL_0026: endfinally
}
IL_0027: ret
}
}

Fazit: Wie bereits richtig erklärt wurde, überdeckt eine lokale Variable eine globale vollständig.
Bei Using wird eine neue, lokale Variable angelegt.

Übrigens ist ein Using Block nicht einfach nur ein Dispose-Aufruf am Ende, sondern, wie man sieht, auch ein Try-Finally-Block.
Dadurch wird sichergestellt, dass das Objekt auf jeden Fall verworfen wird. Auch, wenn eine Exception im Try-Block ausgelöst wird. Und natürlich wird noch überprüft, ob die lokale Variable nicht Nothing ist, da sonst ein Aufruf an die Disposed-Methode eine NullReferenceException auslösen würde.

Storch · 27. September 2013, 07:16

Da soll nun noch einer durchsehen.

Das Fazit, was aus allem jetzt ziehe ist:

VB.NET-Quellcode

Using frm As New Form2

ist im Grunde das selbe wie wie

VB.NET-Quellcode

Using frm = New Form2

denn, egal wie man es schreibt, es wird hier immer eine neue Variable erstellt, egal ob man As oder = schreibt. Für die lokale Variante scheint mir das dann egal zu sein. Aus Gewohnheit würde ich As schreiben.

Global müsste dann also vorher die frm-Variable vollständig deklarieren und belegen:

VB.NET-Quellcode

Private frm As New Form2
Using frm
'Mach Was
End Using
frm = Nothing

Aber man müsste die Variable selbst nach End Using auf Nothing setzen, bei Bedarf.

????????????????????????????

@Niko
ich verstehe nicht, wie ich Deinen Code für mich nutzbar machen kann!!??

ErfinderDesRades · 27. September 2013, 09:01

Using ist eiglich nur sinnvoll mit lokalen Variablen.
Es ist zwar möglich, Using auch auf vor-initialisierte Variablen zu setzen, aber dassis extrem unüblich. Denn man erschafft ja vor-initialisierte Variablen genau aus dem Grund, dass man sie mehrmals benutzen will. Using ist aber so, dasses nur einmal used, und dann hauts den Kram weg.
Bei letzterem musste auch nix auf Nothing setzen, denn nach verlassen des Using-Blocks ist die Variable eh aussm Scope raus, nicht mehr erreichbar, und also Fressen für den GC.

sonne75 · 27. September 2013, 09:08

Storch schrieb:

Global müsste dann also vorher die frm-Variable vollständig deklarieren und belegen:

VB.NET-Quellcode

Private frm As New Form2

Using frm

'Mach Was

End Using

frm = Nothing

Aber man müsste die Variable selbst nach End Using auf Nothing setzen, bei Bedarf.

Wie schon gesagt:

sonne75 schrieb:

Gut, das hat @SpaceyX: dann beantwortet:

Zitat von »SpaceyX«
Using kannst Du nur innerhalb eines Methodenrumpfes verwenden.

Storch schrieb:

@Niko
ich verstehe nicht, wie ich Deinen Code für mich nutzbar machen kann!!??

Für dich nicht, es hat gezeigt, wie intern mit dieser Problematik umgegangen wird: globale und lokale Variable mit gleichem Namen. Es war ein Beweis an "ungläubige"

, dass es tatsächlich so ist.

Niko Ortner · 27. September 2013, 09:24

(Edit: Seit ich den Post angefangen habe, sind knappe 2 Stunden vergangen)

@Storch:
Garnicht. Es macht üblicherweise keinen Sinn, eine globale Variable (oder eine bereits deklarierte, lokale Variable) in einem Using-Block zu verwenden. Deshalb wird auch immer eine neue, lokale Variable angelegt.
Der Sinn von Using ist ja, dass man lokal, für begrenzte Zeit, eine Ressource hat, die unbedingt wieder verworfen werden muss.
Ein Beispiel:

VB.NET-Quellcode

Private Sub SaveToBitmap()
Using Bpm As New Bitmap(Width, Height)
Using g = Graphics.FromImage(Bpm) 'Der Unterschied besteht hier nur in der praktischeren Schreibweise
g.DrawStuff()
End Using
Bpm.Save("C:\....")
End Using
End Sub

Also wenn Du Using verwendest, musst Du weder irgendwas disposen noch auf Nothing setzen. (Und einfach keine bereits existierenden Variablen im Using-Block verwenden.)

Edit 2:
Um das Problem mit der globalen Variable zu erklären: Das ist ein Bug der IDE. Wenn man mit der Maus über den Namen einer Variable fährt, dann wird nicht die tatsächliche Variable angezeigt, sondern die relativ zur aktuellen Codezeile "lokalste" Variable mit diesem Namen, die gefunden wird.
Beispiel:

VB.NET-Quellcode

Public Class Program
Public Shared Sub Main()
HasLocal()
End Sub
Private Shared Bar As Foo
Private Shared Sub HasLocal()
Dim Bar As New Foo("Local")
HasNoLocalButArgumentInstead(Bar)
End Sub
Private Shared Sub HasNoLocalButArgumentInstead(Argument As Foo)
Dim bp = 0
End Sub
Class Foo
Public InternalValue As String
Public Sub New(NewValue As String)
InternalValue = NewValue
End Sub
End Class
End Class

Die globale Variable ist immer Nothing, aber wenn man bei Zeile 11 wartet (also noch nicht in die Methode hineingeht), dann wird bei beiden Bars das Objekt der lokalen Variable angezeigt. Sobald man aber bis Zeile 15 debuggt, ist Bar plötzlich wieder Nothing (auch die lokale Bar-Variable der HasLocal-Methode, obwohl man diese Variable eigentlich nicht sehen kann (kann man auch nicht, die IDE zeigt in Wirklichkeit die globale Variable an). Stattdessen bekommt man das Objekt der lokalen Variable über das Argument.
Macht man in der Aufrufliste einen Doppelklick auf die HasLocal-Methode, hat man wieder den Zustand von vorhin.

Und deshalb, meine Freunde, gibt man Variablen möglichst eindeutige Namen.

Using und globale Variable

VB.NET-Quellcode

VB.NET-Quellcode

SpaceyX schrieb:

VB.NET-Quellcode

Storch schrieb:

Storch schrieb:

Storch schrieb:

Storch schrieb:

SpaceyX schrieb:

Storch schrieb:

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

C-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

Storch schrieb:

VB.NET-Quellcode

sonne75 schrieb:

Storch schrieb:

VB.NET-Quellcode

VB.NET-Quellcode

Ähnliche Themen

8 Benutzer haben hier geschrieben