Boxing und Unboxing in C#

[jfheins]

Der Sinn (oder zumindest ein großer Vorteil) ist, dass du mittels boxing eine generische Klasse/Funktion schreiben kannst, die wirklich alle Typen unterstützt.
Einer Funktion, die einen Object Parameter erwartet, kann also wirklich alles übergeben werden. Und diese kann dann auch auf ihren Parameter .toString() aufrufen, da diese Funktion ja in object deklariert ist.

Eine List<int> und eine List<double> benutzen also die gleiche List<T> wie List<String> oder List<StringBuilder>

Genaueres können dir bestimmt Phoenix oder Elvis erzählen, die kennen sich noch besser mit .net aus

[-187-]

Zitat von jfheins:

Der Sinn (oder zumindest ein großer Vorteil) ist, dass du mittels boxing eine generische Klasse/Funktion schreiben kannst, die wirklich alle Typen unterstützt.

Okay das macht schonmal Sinn

Zitat von jfheins:

Und diese kann dann auch auf ihren Parameter .toString() aufrufen, da diese Funktion ja in object deklariert ist.

Ich kann auch wie folgt zugreifen:

Delphi-Quellcode:

int i = 0;
string s = i.ToString();

Zitat von jfheins:

Eine List<int> und eine List<double> benutzen also die gleiche List<T> wie List<String> oder List<StringBuilder>

Das hab ich nicht verstanden ?

[SebE]

Zitat von -187-:

Ich kann auch wie folgt zugreifen:

Delphi-Quellcode:

int i = 0;
string s = i.ToString();

Ich denke hier wird implizit das Boxing angewandt.
Es geht auch kürzer:

Code:

(5).ToString()

[-187-]

Achso da wird quasi im Hintergrund "geboxt" ? Hmm .. seltsam das Ganze... Aber Anhand deiner Erklärung habe ich folgenden Code aufgestellt. Der Vorteil ist deutlich sichtbar:

Code:

        private void Form1_Load(object sender, EventArgs e)
        {
            int i = 50;
            string s = "50";
            object o = i;
            //object o = s;
            MessageBox.Show(testFunction(o));
        }

        private string testFunction(object o)
        {
            return Convert.ToString(o);  
        }

Ich kann über's "Boxing" eine Funktion mit jedem x beliebigen Datentyp aufrufen. Ok, wann und ob ich es brauche wird sich zeigen ...

[jfheins]

Zitat von SebE:

Delphi-Quellcode:

int i = 0;
string s = i.ToString();

Ich denke hier wird implizit das Boxing angewandt.
Es geht auch kürzer:

Code:

(5).ToString()

Da der Typ Int32 zum Glück die .toString() Methode überschreibt, wird hier nicht geboxt. Also schlechtes Beispiel ^^

Aber man deklariere sich einen beliebigen struct und siehe da, man kann toString() aufrufen obwohl das gar nicht deklariert wurde


Zum Beispiel in Java kann man keine generische ArrayList<double> deklarieren, weil die Klasse einen Referenztype haben möchte. Dafür gibt es dann die Wrapperklasse Double (großegeschrieben) ... sowas wollte man sich vll. ersparen.

[SebE]

Zitat von jfheins:

Da der Typ Int32 zum Glück die .toString() Methode überschreibt, wird hier nicht geboxt. Also schlechtes Beispiel ^^

Aber man deklariere sich einen beliebigen struct und siehe da, man kann toString() aufrufen obwohl das gar nicht deklariert wurde

Ja, da hast du recht. Auch Int, Bool, ... sind - wie alle Structs - von object abgeleitet (und besitzen u.a. ToString()).

Folgende Ableitungshierachie finde ich irgendwie komisch.
object <-- valueType <-- struct <-- int, wobei object eine Klasse und struct (wie der Name schon sagt) keine ist.
Alles nach valueType (structs, int, ...) liegt auf dem Stack, alle Verweistypen auf dem Heap, wo liegt object?

[jfheins]

Zitat von SebE:

Ja, da hast du recht. Auch Int, Bool, ... sind - wie alle Structs - von object abgeleitet (und besitzen u.a. ToString()).

Folgende Ableitungshierachie finde ich irgendwie komisch.
object <-- valueType <-- struct <-- int, wobei object eine Klasse und struct (wie der Name schon sagt) keine ist.
Alles nach valueType (structs, int, ...) liegt auf dem Stack, alle Verweistypen auf dem Heap, wo liegt object?

object liegt auf dem Heap, wie jeder andere Verweistyp. Falls ein Wert-Typ nach object gecastet wird, wird automatisch ein Objekt erstellt dass den Werttyp beinhaltet.

Das mag am Anfang komisch sein. Aber wenn man darüber Bescheid weiß, ist das halt eine kleine Eigenart die man beachten sollte. In Delphi z.B. ist es nicht ohne weiteres möglich, eine Funktion mit einem Parameter beliebigen Typ zu erstellen. Entweder man überlädt sie x-mal mit TObject, int, long, double, string oder man nimmt einen Variant. Wobei ein Variant mehr Overhead haben dürfte als das boxing.

Btw.: Sooo häufig ist mir das Boxing noch nicht in die Quere gekommen seit ich mit C# einwickle. Eigentlich noch nie. Häufig kann man ja statt structs auch Klassen verwenden, dann hat sich das mit dem Boxing eh erübrigt.

An vielen Stellen wo geboxt wird, wird die nicht geboxte Kopie auch weggeworfen. Zum Beispiel:

Code:

Mein_Eventhandler
{
var abc = new(MyStruct);
abc.Name = NameTxt.Text;
abc.Age = (int)AgeNum.value;
Contactlist.Add(abc);
abc.Haircolor = Color.Green;
}

Jetzt hast du natürlich die Situation dass die Haarfarbe nicht mehr in der Kontaktliste steht. Wenn myStruct eine Klasse wäre, würde es noch übernommen.
Aber der Code sieht ja auch komisch aus. Erst alle Felder befüllen und dann in die Liste rein

[implementation]

Zitat von SebE:

Ich denke hier wird implizit das Boxing angewandt.
Es geht auch kürzer:

Code:

(5).ToString()

Es geht auch noch kürzer:

Code:

5.ToString()
// ... oder ...
"Hello!".ToUpper()

Und SebE: Ein object ist ein Verweistyp -> Heap.
Die Value-Typen sind nicht wirklich von object abgeleitet, dort kommt nur wieder das Boxing ins Spiel.

[Medium]

Es ist übrigens sehr wohl möglich, primitive Datentypen als var- oder out-Parameter zu übergeben. AFAIK wird dabei auch nicht im Hintergrund rumgeboxed, sondern lediglich die Zeigernatur (wie auch in Delphi) via Sprachmitteln verborgen. Ebenso ist die Typsicherheit durch den Compiler gewährt. Alles in allem ist das ja eigentlich "nur" konsequentes OOP Durchziehen, so dass - zumindest semantisch - immer alles Objekte sein können.
Ich bin zudem nicht völlig davon überzeugt, dass die Runtime da hinter den Kulissen wirklich in vollem Umfang ein Objekt nach "allen Regeln der Kunst" aufbaut. Ich mutmaße auch dort eine Portion Compiler- bzw. Runtimemagic mehr, damit solche Dinge nicht allzu teuer werden.
Ich war auch zu Beginn von .NET recht skeptisch und hielt das für Humbug, aber man erhält einfach eine Fülle von Freiheiten und Komfort auf diese so einfache Weise, die man wirklich erst merkt, wenn man die 100ste List<float> nicht separat neu ableiten musste . Und der Preis ist doch eher marginal. Ich habs argwöhnisch erwartet, und lieben gelernt.

[Elvis]

Zitat von Medium:

Es ist übrigens sehr wohl möglich, primitive Datentypen als var- oder out-Parameter zu übergeben. AFAIK wird dabei auch nicht im Hintergrund rumgeboxed, sondern lediglich die Zeigernatur (wie auch in Delphi) via Sprachmitteln verborgen.

ref parameter sind tatsächlich Zeiger. Aber das macht die CLR nur mit Parametern. (Weshalb man zum Beispiel keine ref-Parameter für Iteratoren nutzen kann. Denn dort landen diese ja als Felder, und Felder dürfen keine Referenzen sein.

Zitat:

Ich bin zudem nicht völlig davon überzeugt, dass die Runtime da hinter den Kulissen wirklich in vollem Umfang ein Objekt nach "allen Regeln der Kunst" aufbaut. Ich mutmaße auch dort eine Portion Compiler- bzw. Runtimemagic mehr, damit solche Dinge nicht allzu teuer werden.

Natürlich ist eine Box keine eigene Klasse, das wäre ja kaum zu verschleiern und dadurch nicht transparent. Außerdem braucht die Box keine eigenen Metadaten oder Implementierungen der Methoden und spart damit auch einen Batzen an Verwaltung.
Aber der Aufwand der Instanzierung einer Box ist gleichzusetzen mit dem einer Klasse, welche dein Struct als Feld hat. Zaubern kann das CLR Team ja auch nicht. Und sie werden richtige Klassen wohl kaum langsamer instanzieren lassen, nur damit Boxes relativ schneller sind.