Integer to String ???

LordJaxom

Da hinter Int32 auch in Deinem Beispiel kein Dach ist, wird der Wert genauso wie ein builtin-int nicht auf dem verwalteten Heap abgelegt. Darüberhinaus hielte ich es auch für höchst ineffizient, Werte, deren Storage kleiner ist als die einer verwalteten Referenz (Zeiger, Refcounter usw. liegen auch irgendwo rum) auf dem Heap anzulegen. Man muss die Performance ja auch nicht verschwenden

Nicht zuletzt liegen selbst in den reinen .NET-Sprachen (C#) Werttypen auf dem Stack.

Jochen Kalmbach

Es liegt *nur* etwas auf dem Heap, wenn es ein ^ hat!!!

Also

Int32 i;

und

int i;

ist gleichbedeutend und hat nix mit dem Heap zu tun.

Genauso:

Object o;

liegt auch nicht auf dem Heap!

Guckst Du hier

http://msdn2.microsoft.com/de-de/library/ms235267(VS.80).aspx

Dann erkläre uns doch mal bitte den Unterschied zwischen...

Double und double
Boolean und bool

usw....

Guckst Du da weita...

http://download.microsoft.com/download/9/2/3/923d72fb-0076-49b6-96c4-aac1c255a60e/2023_S87_126OK.pdf

Helium

Melle schrieb:

Guckst Du da weita...

http://download.microsoft.com/download/9/2/3/923d72fb-0076-49b6-96c4-aac1c255a60e/2023_S87_126OK.pdf

Gelesen?

Um den
Unterschied zwischen Verweis- und Wertetypen zu verstehen –
eine grundlegende Unterscheidung im CTS –, müssen Sie
zunächst wissen, wie den Instanzen der einzelnen Typen Speicher
zugeordnet wird. Im verwalteten Code gibt es dafür zwei Möglichkeiten1:
auf dem Stack oder auf dem Heap, die beide von der
CLR verwaltet werden.

Jochen Kalmbach

Und was hat das mit dem Unterschied zwischen "Double" und "double" zu tun???

System::Double == double
System::Float == float
System::Boolean == bool
(und das gilt natürlich noch für viele andere Typen...)

Toller Unterschied.
Leuchtet mir ein.
Was willst Du mir damit sagen
Danke.

Helium

Melle schrieb:

Toller Unterschied.
Leuchtet mir ein.
Was willst Du mir damit sagen
Danke.

An wen gerichtet?

Du hast behauptet, dass Int32 auf dem Heap liegen würde, bringst dann selbst Papers, die aussagen, das sie auf dem Stack liegen.

Reicht das???

Variablen und referenzierende .NET Typen
Referenzierende .NET Typen werden grundsätzlich auf der vom Garbage Collector verwalteten Halde angelegt. Ebenso grundsätzlich kann es keine Variablen eines referenzierenden Typs geben. Das bedeutet, dass die folgende Zeile nicht korrekt compiliert werden kann:

http://www.microsoft.com/germany/msdn/library/net/cplusplus/CPlusPlusManagedExtensions.mspx?mfr=true

Siehe unter...
"Variablen und referenzierende .NET Typen"

Jochen Kalmbach

Ich glaube Du hast irgendwas nicht ganz verstanden...

In C++/CLI kann man anhand des Datentyp überhaupt nicht feststellen, wo dieser liegt!!!
Du kannst sowohl ein ref-object auf dem Stack anlegen als auch ein Value-Object auf dem Heap!

Also, nochmals: Der Datentyp spielt in C++/CLI *gar keine Rolle*!!!

Das *einzige* was zählt ist: Wie wurde die Variable deklariert:

Stack:

Int32 i1;
int i2;
bool b:
DateTime dt;
StreamWriter sw;

Heap (also GC verwaltet):

Int32 ^i1;
int ^i2;
bool ^b:
DateTime ^dt;
StreamWriter ^sw;

So nun nochmal.
Guckst Du Seite 3
http://www.courseptr.com/downloads/bonus/009638_BonusCh02.pdf
Und nun sag nicht wieder das ist alles gleich wenn nicht sogar das gleiche.

Melle schrieb:

So nun nochmal.
Guckst Du Seite 3
http://www.courseptr.com/downloads/bonus/009638_BonusCh02.pdf
Und nun sag nicht wieder das ist alles gleich wenn nicht sogar das gleiche.

Ach ja und mit dem Dach ^ legst Du eine Handle an.
Nur so nebenbei.

LordJaxom

Ja, ein Handle auf den verwalteten Heap. Ergo kann etwas was kein Handle ist nicht auf dem verwalteten Heap landen.

Nebenbei: Int32 ist kein referenzierender Typ, und "managed" bedeutet nicht zwangsläufig "referenced".

Jochen Kalmbach

Melle schrieb:

So nun nochmal.
Guckst Du Seite 3
http://www.courseptr.com/downloads/bonus/009638_BonusCh02.pdf
Und nun sag nicht wieder das ist alles gleich wenn nicht sogar das gleiche.

Was willst Du mir jetzt damit sagen?
Das ich recht habe?

Helium

OK, es gibt nen Stack und nen Heap. Um an dinge auf dem Heap zu kommen braucht man Verweise darauf. Es gibt einen verwalteten (managed) Heap und einen unverwalteten (unmanaged) Heap. In den unverwalteten Heap verweist du in der Regel mit Zeiger (*) (auch wenn es auch mit Referenzen (&) möglich ist). In den Managed-Heap kannst du nur mit Handles (^) verweisen (bzw. entsprechend geht das ganze natürlich auch mit den entsprechenden Referenzen. Über pin-Pointer, etc. will ich jetzt nicht reden. Du merkst aber, dass immer eine Indirektion für Zugriffe auf alle Objekte auf dem Heap notwenidg ist.)
Hast du kein Handle (^) kommst du auch nicht an ein Objekt auf dem verwalteten Heap. Int32 ist kein Handle, kommt also auch nicht an etwas, was auf dem verwalteten Heap liegt. ein entsprechendes Objekt liegt auf dem Stack.
Es kann aber passieren, dass das Objekt geschachtelt wird (Boxing). Dann landet eine Kopie des Objekts auf dem Heap und du bekommst - wer hätte es gedacht - einen Handle darauf.

Int32 foo = 42;
object^ bar = foo;  // Schachtelung, bemerkst du den Handle?

Wenn du entschachtelst bekommst du natürlich wieder direkt ein Objekt auf dem Stack:

Int32 baz = static_cast<Int32>(bar); // kein Handle!

Ich lass mich gern eines Besseren belehren.
Ist aber so auch nicht ganz richtig Helium.
Diese Antwort habe ich von meinem Dozenten bekommen.

die von Ihnen genannten Variablen, werden bei der Definition nicht auf dem Heap gespeichert, sondern auf dem Stack.
Nur Objekte, die Sie mit "new" erzeugen, werden auf dem Heap abgelegt.

So und nun
Ich denke doch mal ihr habt auch sicher dafür eine Erklärung
Gruß Melle

Jochen Kalmbach

Also, dann ist die Erklärung etwas irreführend...
Um es genauer zu sagen:
Der GC verwaltet nicht nur Dinge die auf dem Heap liegen, sondern auch Objekte (Referenzen) die thread-lokal sind; d.h. in methoden drin; und natürlich auch noch statische Objekte!

Beispiel:

void func()
{
  int i = 32;
  Object ^o = i; // so, ab hier wird ein *neues* Object angelegt, welches vom GC verwaltet wird!

  // ... mache hier was mit "o"
  // ... wenn ab hier nichts mehr mit "o" gemacht wird, dann kann es sein, dass es der GC schon wieder aufgeräumt hat!
}

PS: Neue Obekte legt man in C++/CLI nit mit "new" an, sondern mit "gcnew"!

Jochen Kalmbach

Für mehr Infos siehe:
http://msdn.microsoft.com/msdnmag/issues/1100/gci/
http://msdn2.microsoft.com/en-us/library/ms973837.aspx
http://msdn2.microsoft.com/en-us/library/f144e03t.aspx

Wenn ich meinem Lehrstoff so Glauben schenken sollte, steht das "gc" in "gcnew" für Garbage Collection.

Ein Handle das mit "new" erzeugt wurde, wird zwar auf dem Heap abgelegt, aber nicht vom Garbage Collector verwaltet.

Ein Handle das mit "new" erzeugt wurde, muss auch wieder über "delete" gelöscht werden, um den belegten Speicher freizugeben.

Ferner werden auch Variablen mit dem Dach ^ auf dem Heap abgelegt, aber nicht vom Garbage Collector verwaltet.

Irres Thema.

Möchte jetzt hier auch nicht das ganze Forum mit dem Quatsch zunageln.

Ich werde dieses Thema jetzt auch an die Wand hängen und warten bis mein nächster Dozent wieder da ist.

Aber Danke nochmal für die Hilfe und die Geduld.

Ich denke mal diese C++/CLI Gesichte ist für manche Dozenten auch noch ein Buch mit 7 Siegeln.

Helium

Melle schrieb:

Nur Objekte, die Sie mit "new" erzeugen, werden auf dem Heap abgelegt.

So und nun
Ich denke doch mal ihr habt auch sicher dafür eine Erklärung

Jetzt kann ich ja sowas machen:

Int32^ sinnlos()
{
   return gcnew Int32(17);
}

Diese Funktion legt ein Objekt mit Hilfe von gcnew auf dem (verwalteten) Heap an und gibt den Handle darauf zurück. Wenn ich sie aufrufe sehe ich ja nicht, was intern passiert.

Ähnlich, wie diese (sinnlose) Funktion das Erstellen eines Objekts auf dem Heap versteckt tut das auch das Schachteln. Auch hier wird intern ein Objekt auf dem Heap angelegt und ich bekomme einen Handle darauf.

Aus

object ^ foo = 42;

macht der Compiler sowas, wie:

object ^ foo = __box(42);

, wobei __box eben die Funktion ist, die intern ein Objekt auf dem Heap anlegt.