@Niko Ortner hat hier einmal etwas dazu geschrieben...

@Marcus Gräfe Das ist in VB.NET egal, in C# müssen die Klammern nachg string stehen: string[] x.
Ansonsten setz nen Haltepunkt drauf und sieh Dir den Inhalt an.

Naja, wenn ich lese
dann denk ich mir beim flüchtigen Drüberschauen, dass hier eine einfache Integervariable deklariert wird.
Bei
seh ich sofort: Test ist ein (Typangabe:) Integer-Array.

Leider macht es Mikrosaft aus meiner Sicht kontraintuitiv. Gibt man einer noch nicht geschriebenen Prozedur ein Array an die Hand und lässt den Prozedurrumpf automatisch erstellen, dann kommt raus:

Klammern leider hinter dem Namen, nicht hinter dem Datentyp.

man kann allerdings das Array auch gleich dimensionieren - so:
Wenn wolle gugge auch dies: Grundlagen: Fachbegriffe - da gibts auch einen abschnitt Array.

Marcus Gräfe schrieb:

Für mich als VB6-Entwickler ist das völlig klar: Es ist ein Integer-Array.

Richtig.
Aber sieh dir die Property an, die direkt darunter steht. Sie ist mit der gleichen Syntax geschrieben. Also möchte man meinen, dass der Typ auch ein Integer-Array ist.
Um es mit den Worten von Herbert Grönemeyer auszudrücken: Isses aber nicht.
Denn Properties können Parameter haben:

Es wäre komisch, wenn das bloße Hinzufügen eines Index zur Property plötzlich den Typ von Integer-Array auf Integer ändern würde.


Der Konzeptuelle Unterschied ist der:
Bei C deklarierst du mit int x[10]; quasi "10 Variablen vom Typ int". Dort, wo du die Variable hinschreibst, liegen tatsächlich auch die 10 ints.
In VB sieht Dim x(10 - 1) As Integer auch so aus, ist aber äquivalent zu Dim X As Integer() = New Integer(10 - 1) {}. Da, wo du x hinschreibst, liegen also nicht die 10 Integer, sondern eine Referenz auf einen Speicherbereich, der das eigentliche Array it. Das Konzept, 10 Variablen vom Typ Integer zu deklarieren, ist hier also nicht gegeben. Und um diese Verwirrung zu vermeiden, sollte man die Schreibweise mit den Klammern beim Namen nicht verwenden.

Also ja, es geht um die Lesbarkeit.

Sorry, aber ist das nicht i-Tüpflerei ?

Ob Dim x() As String und Dim x As String() ist ja wirklich egal. Jeder so wie er/sie das besser lesen kann.

Ich persönlich komme von VB und könnte mit der zweiten Variante nichts anfangen weil ich die erste Variante gewohnt bin - ich würde die Klammern einfach überlesen.
Ein C-Programmierer würde mit der zweiten Variante möglicherweise was anfangen - aber der wird höchstwahrscheinlich sowieso in C programmieren und nicht in VB .

Aber dennoch interessant zu wissen, dass es auch diese Variante (die zweite) gibt. Wenn beide das selbe machen, ist es aber wirklich egal welche man nimmt.

Schlussendlich ist nur wirklich das wichtig was man daraus macht - eine g´scheite Anwendung

dive26 schrieb:

Sorry, aber ist das nicht i-Tüpflerei ?

Naja, ich finde, es ist schon wichtig, diesen Unterschied im Konzept zu kennen. Besonders wenn man als Anfänger noch nicht so gut weiß, wie Objekte und Arrays und Variablen und das alles zusammenspielen, finde ich es gut, wenn die Syntax einheitlich und nicht verwirrend ist.
Und es gibt wie gesagt sehr viele Ausnahmen von dieser Syntax. Bzw. müsste man sagen, dass diese Syntax die Ausnahme ist:
Funktionen, die ein Integer-Array zurückgeben, kann man auch nicht mit Function Foo() As Integer deklarieren.
Dim x(10 - 1) As Integer : Console.WriteLine(x.GetType.Name) gibt Int32[] aus, also mit Klammern beim Typ.
Will man bei Dim f As Form eine Instanziierung draus machen, schreibt man Dim f As New Form oder Dim f = New Form, also es ein New vor den Typ zu schreiben, gibt dir eine neue Instanz des Typs. Will man das gleiche bei Dim x() As Integer machen, wäre das Äquivalent Dim x() As New Integer. New Integer wäre in jeder anderen Situation kein Integer-Array, sondern ein einzelner Integer. (Der Compiler erlaubt diese Syntax übrigens explizit nicht. Arrays können nicht mit "New" deklariert werden.. Wahrscheinlich, weil es zu verwirrend wäre.) Und hier noch was Ungünstiges: Dim x(10 - 1) As Integer versteckt das New, was aber ein entscheidendes Schlüsselwort ist.
Also es gibt nur bei primitiven Sprachelementen (Feldern, Parametern und lokalen Variablen) diese Syntax. Alles, was mehr ist (Eigenschaften und Funktionen, und auch einfach alles, wo der Typ nicht in Verbindung mit einem Namen steht), erfordert die Klammern beim Typenname.

Marcus Gräfe schrieb:

Ich habe auch noch nie eine Eigenschaft mit Parameter gesehen.

Unter der Haube vielleicht schon. Immer, wenn du eine List(Of T) hast, und davon per Index auf ein Item zugreifst, verwendest du die Item-Property, die den Index als Parameter entgegennimmt. (Sie ist übrigens als Default deklariert, also wenn du DeineListe(0) hinschreibst, ist das Äquivalent zu DeineListe.Item(0).)

Marcus Gräfe schrieb:

Das ist mir natürlich bewusst.

Uh - das ist eine gefährliche Schein-Selbstverständlichkeit, auch nur in irgendeinem Detail von vb6 auf vb.net zu schliessen.
Haut in diesem Falle ausnahmsweise hin, obwohls eiglich idiotisch ist.
Weil der Datentyp eines Integer-Arrays heisst Integer(), und nicht anders.
Die vb6-Schreibe ist daher völlig unlogisch:Da steht klippnklar: As Integer - und das ist falsch!
Weil x ist hier ein Integer(), und kein Integer - das ist ein Unterschied wie zwischen Praline und Pralinen-Schachtel.

Aber der vb-Compiler versteht das so, und der sitzt letztlich am längeren Hebel.

ErfinderDesRades schrieb:

Aber der vb-Compiler versteht das so, und der sitzt letztlich am längeren Hebel.

Das ist das Problem, dass VB so wenig restriktiv ist, wohl, um .NET Anfängern schmackhaft zu machen.
Da bin ich lieber bei C#.

In C/C++ ist es übrigens die erste Variante.

Hier ist sogar int[2] ein anderer Typ als int[3]. Man deklariert also int a[] hinter dem Variablennamen, aber der Typ ist nicht int sondern int[]. Warum das so ist k.A., aber es ermöglicht Inlinedeklarationen int a, b[2], c[3];.

Das ist das Problem, dass VB so wenig restriktiv ist, wohl, um .NET Anfängern schmackhaft zu machen.
Da bin ich lieber bei C#.

Warum wollt Ihr unbedingt alles kompliziert machen, wenn es doch auch einfach geht?
Ich für meinen Teil nutze Funktionen die mir zur Verfügung gestellt werden .

Diejenigen denen VB zu einfach und zu wenig restriktiv ist, die programmieren ja ohnehin in C#. Wir VB-ler lieben das "wenig restriktive"

dive26 schrieb:

Wir VB-ler lieben das "wenig restriktive"

Ich zähle mich einfach mal nicht dazu , bleibe aber trotzdem bei VB.

Dito.

Ich mag die VB-Syntax mehr als C#, weshalb ich mich durchaus als VBler betrachte.
Und ich mag Restriktionen, weil sie üblicherweise für saubere Programmierung sorgen.

Im diskutierten Fall von Dim x(3) As Integer haben wir zweifache Funktionalität:
1) Instanziiere x als (leeres) Integer-Array
2) Dimensioniere x von 0 bis 3
Also gleichbedeutend mit


Aber wenn ich ehrlich bin, habe ich unter VB.Net eh noch nie freiwillig mit Arrays gearbeitet.
Schließlich gibt es da wesentlich mächtigere Möglichkeiten im Framework.

Weils nunmal so ist.
Das ist die gültige Syntax, und die ist unlogisch, aber nunmal gültig.
Und funktioniert, und braucht man ja auch.

(Es gibt übrigens noch eine weitere Möglichkeit, ein Array zu erzeugen, mit Shared Array.CreateInstance(), das ist zwar logisch aber so verquast und umständlich - dass die unlogische Variante immer noch den besser verständlichen Code ergibt.)

Gonger96 schrieb:

Warum das so ist k.A.,

Siehe:

Niko Ortner schrieb:

Bei C deklarierst du mit int x[10]; quasi "10 Variablen vom Typ int".

@Marcus Gräfe
Um die Verwirrung zu vervollständigen: Es gibt auch die Syntax Dim x(0 To 9) As Integer bzw. Dim x = New Integer(0 To 9) {}. Also 0 bis 9 sind die gültigen Indices. x.UpperBound ist 9 und x.LowerBound ist 0.
Jetzt denkt man sich vielleicht: "Kann LowerBound auch was anderes außer 0 sein?"
"Well, yes, but actually no." Dim x(4 To 9) As Integer meckert der Compiler an: Untere Arraybegrenzung kann nur "0" sein. Die CLR könnte das krasserweise aber: Dim a As Array = Array.CreateInstance(GetType(Integer), {6}, {4}). Das ist aber schon nicht mehr trivial verwendbar. Ich hätte mir vorstellen können, um mit Krams zusammenzuarbeiten, bei dem Array-Indices bei 1 anfangen, wäre es praktisch gewesen, aber DirectCast(a, Integer()) löst eine InvalidCastException aus: Das Objekt des Typs "System.Int32[*]" kann nicht in Typ "System.Int32[]" umgewandelt werden. Man muss umständlich mit a.GetValue und a.SetValue arbeiten und damit ist das eigentlich ziemlich unsinnig.

Marcus Gräfe schrieb:

Mir fällt nämlich keine Sprache ein, wo das nicht geht.

Ich schon: C#
int x[10]; wäre eine Größenangabe bei der Deklaration. Ist in C# nicht erlaubt, weil's eben nicht das Gleiche wie in C und C++ bedeutet.
Außer!
Man verwendet unsafe: unsafe struct Foo { public fixed int x[10]; } bedeutet dann wirklich das Gleiche wie in C und C++!


Ich mag das. Ich könnte mich stundenlang über solche Details unterhalten