C++ --> C# (Pointerproblem)
-
Ich habe mal etwas rumprobiert und glaube, daß Referenztypen garnicht erst in einen Pointertyp gewandelt werden können.
MyClass *tmp;Compilermeldung:
Cannot take the address of, get the size of, or declare a pointer to a managed type ('Babtec.CaqNet.Business.Rules.Antananarivo.Unsafe.MyRefClass'
-
Die Plattformunabhängigkeit verlierst du aber nur durch die DLL, wobei es ja kein Problem ist auf einem Unix-System eine so(?)-Datei zu erstellen und diese dann zu verwenden. C# läuft eh nur auf Windows und teils auf Unix oder hat sich da etwas sehr stark getan (abgesehen von WindowsCE oder so)? C++ selbst ist ja Plattformabhängig.
Ansonsten sehe ich das wie Talla, durch Referenzen wirst du wohl kaum an Performance verlieren. Das einzige wo evtl. unsafed von nützen sein könnte ist bei einem Sortier- und Suchverfahren (zumindest wenn es sich um Bäume handelt).
-
Ja das ist richtig. Jedoch dachte ich dass dies aus der Compilermeldung klar ersichtlich wäre
Deshalb schrieb ich in meinem vorherigen Beitrag, dass es mit structs geht und Du in der (managed) Class auf Struct-Pointern arbeiten könntest.
-
Das ist ja alles hochinteressant! Nun, bin ich auf ein weiteres ungewöhnliches Phänomen gestoßen und zwar, daß man nicht gerade viel Speicherpaltz reservieren kann.
int copies = 200000; int *pSource = stackalloc int[copies];Das gibt schon einen Stackoverflow! Das sind grad mal 800 kb!!!! Das ist aber sehr schmal!
-
ChrisPlusPlus schrieb:
Ich habe mal etwas rumprobiert und glaube, daß Referenztypen garnicht erst in einen Pointertyp gewandelt werden können.
Das ist so. Alle Klassen, die von System.Object erben sind für die Verwendung mit Zeigern verboten. Die Ausnahme bilden natürlich Typen, die von System.ValueType erben, sowie Arrays von diesen. Weil Arrays aber Referenztypen sind, musst du diese erst "pinnen", damit du einen Zeiger benutzen darfst.
ChrisPlusPlus schrieb:
int copies = 200000; int *pSource = stackalloc int[copies];Das gibt schon einen Stackoverflow! Das sind grad mal 800 kb!!!! Das ist aber sehr schmal!
Normalerweise würde man auf dem Heap allokieren. Der Stack ist nicht dafür gedacht, grosse Mengen von Daten aufzunehmen.
-
Das ist ja alles hochinteressant! Nun, bin ich auf ein weiteres ungewöhnliches Phänomen gestoßen und zwar, daß man nicht gerade viel Speicherpaltz reservieren kann.
int copies = 200000; int *pSource = stackalloc int[copies];Das gibt schon einen Stackoverflow! Das sind grad mal 800 kb!!!! Das ist aber sehr schmal!
-
Davon ab dürfte der Stack nicht der Ort sein wo Du das allokieren möchtest, da er sich mit jedem Aufruf, mit jedem Return und mit jeder lokalen Variable verschiebt, will heissen ich glaube nicht dass ein Stack-Allokierter Speicherbereich länger als bis zum nächsten } lebt
-
stackalloc reserviert ohnehin nur innerhalb des Scopes. Nach verlassen des Scopes wird dieser Speicherbereich für den Garbagecollector wieder freigegeben!
-
ChrisPlusPlus schrieb:
stackalloc reserviert ohnehin nur innerhalb des Scopes. Nach verlassen des Scopes wird dieser Speicherbereich für den Garbagecollector wieder freigegeben!
Des mitm Scope hat ja LordJaxom schon gesagt. Aber des mitm GC stimmt wiederum nicht, weil der hat aufn Stack nichts zu suchen, jedenfalls was Aufräumarbeiten zu tun hat, der geht nur übern Heap.
-
Ups, pardon! Das ist ja klar!
