Warum ist in "Dim x = 1" x ein System.Int32?

Warum ist in "Dim x = 1" x ein System.Int32?

  • Comments 4

Eines der neuen Features von VB9 und C# 3.0 sind "Implicitly Typed Local Variables". Bei diesem Feature leitet sich der Typ einer Variablen bei der Deklaration aus dem zugewiesenen Ausdruck ab. Verdeutlichen soll dies ein kleines Beispiel:

Implicitly Typed Local Variables

In diesem Zusammenhang kommt immer wieder die Frage auf woher der Compiler „weiß“ um welchen Datentyp es sich handelt. Warum ist beispielsweise x in obigem Beispiel ein System.Int32 und kein System.Int16 oder System.Int64? Ein Blick in die Visual Basic Language Specification klärt diese Frage:

„The type of a literal is determined by its value or by the following type character. If no type character is specified, values in the range of the Integer type are typed as Integer; values outside the range for Integer are typed as Long. If an integer literal's type is of insufficient size to hold the integer literal, a compile-time error results.“

Mit Hilfe eines Suffixes kann ein Datentyp allerdings explizit definiert werden.

Dim x = 1S ' makes x a Short

Dim x = 1I ' makes x an Integer - the default for smaller integers

Dim x = 1L ' makes x a Long - the default for larger integers

 

Dim x = 1.0F ' makes x a float (Single)

Dim x = 1.0R ' makes x a real (Double)

Dim x = 1D ' makes x a Decimal

 

Dim x = "1"c ' makes x a Char (as opposed to string)

Dim x = #12/31/1905# ' makes x a Date

Schöne Grüße

   Daniel

P.S.: Timothy Ng hat zwei brilliante Artikel zum dem Thema "Type inference in Visual Basic" geschrieben (Type inference in Visual Basic (part 1) und Type inference in Visual Basic (part 2)).

Leave a Comment
  • Please add 8 and 6 and type the answer here:
  • Post
  • PingBack from http://msdnrss.thecoderblogs.com/2007/09/04/

  • Fragwürdiges Feature in meinen Augen, der Vorteil den ich als Programmierer daraus ziehen soll bleibt mir irgendwie verschlossen. Der Code ähnelt so doch eher Spaghetticode von unwissenden legacy VB Programmierern, wenn auch jetzt endlich typsicher. In Hinblick auf Lesbarkeit und Wartbarkeit des Codes ist die implizite Typisierung, meiner Meinung nach, doch eher ein Rückschritt.

  • Hi Jack,

    „Type inference“ ist eines der Features welches u.a. von LINQ benötigt werden. Stell Dir beispielsweise das folgende Szenario vor:

    Dim Person = New With {.Vorname = "Daniel", .Nachname = "Walzenbach"}

    Hier wird ein anonymer Typ erzeugt. Ohne „Type inference“ (also die Fähigkeit des Compilers den Typ entsprechenden abzuleiten) wäre o.g. Beispiel nicht möglich da es keine Möglichkeit gibt den Typ zu zu refernezieren (selbst wenn man wollte). Stell Dir weiterhin eine kleine LINQ Query vor:

    Class Person

       Public Vorname As String

       Public Nachname As String

    End Class

    Dim Personen As New List(Of Person)

    Personen.Add(New Person With {.Vorname = "Daniel", .Nachname = "Walzenbach"})

    Personen.Add(New Person With {.Vorname = "Oliver", .Nachname = "Scheer"})

    Personen.Add(New Person With {.Vorname = "Dirk", .Nachname = "Primbs"})

    Dim _personen = From p In Personen _

                   Where p.Nachname.StartsWith("W")

                   Select p.Vorname, p.Nachname

    In diesem Fall ist _personen ein IEnumerable eines anonymen Typs der wiederum NICHT spezifizierbar wäre.

    Schöne Grüße

      Daniel

  • Hallo Daniel,

    das hatte ich übersehen, vielen Dank für die Erläuterung.

Page 1 of 1 (4 items)