Integer to String ???

LordJaxom

Melle hat dies behauptet, nicht ich

Aber es stimmt natürlich, dass Int32 ein Werttyp ist. Insofern sehe ich zwischen dem vorherigen Beispiel keinen Unterschied zu dem hier, oder resultiert die Verwendung von builtin-Datentypen wie int automatisch in der Generierung von Unmanaged Code? (Ich verwende C++/CLI so selten)

Der int liegt auf dem Stack und ist unmanaged.
Der Int16; Int32 oder Int64 liegt auf dem verwaltetn Heap.
So hat mir das mein Dozent reingehämmert.
Ich hab ihn damit richtig genervt.
Der int ist ISO C++ und die anderen 3 sind C++/CLI

Gruß Melle

Melle schrieb:

Der int liegt auf dem Stack und ist unmanaged.
Der Int16; Int32 oder Int64 liegt auf dem verwaltetn Heap.
So hat mir das mein Dozent reingehämmert.
Ich hab ihn damit richtig genervt.
Der int ist ISO C++ und die anderen 3 sind C++/CLI
Da der String^ in C++/CLI nur auf dem verwaltetn Heap abgelegt werden kann.
Das ist leicht zumerken, durch das Zeichen Dach ^.
Dadurch werden auch Zeiger auf den verwalteten Heap abgelegt und werden automatisch mit nullptr initialisiert.
Das hat den Vorteil, dass die durch die Garbage Collection (Müllabfuhr) verwalteten werde.
Das heißt, sobald der Zeiger nicht mehr benötigt wird, wird der Speicher wieder automatisch freigegeben und muss nicht mit delete selber Freigegeben werden.
Der Arbeitsspeicher kann auch fragmentieren.
Wie schon gesagt, dass ist der persönliche Stil.
Ich bervorzuge die Garbage Collection nicht weil die neu ist.
Ich finde die Freigabe des Arbeitsspeichers sehr nützlich, die gibt es nämlich in ISO C++ so nicht.
Die Garbage Collection soll auch wirklich funzen.

Musste mich selber Zitieren wollt noch ein bischen mehr schreiben.

Gruß Melle

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"!