Pointer in unsafe code eriner VCL.Net-Anwendung

[barf00s]

was hat das mit VCL zu tun?

VCL = VISUAL COMPONENT LIBRARY

[edit]
weil ich grad das wort "migrieren" les ...
DANN solltest du auch von linkedlists records mit fiesen pointern (oder was auch immer das da sein soll bei dir) auf classes umstellen, dann schreibst auch sicheren .NET code und musst nicht mit unsafe kram rumgurken - was ja wieder dem .NET dings (eigentlich) wiederspricht

[Robert_G]

Mit der VCL.Net kannst du schon aus Prinzip nicht auf CAS zurückgreifen. Das Ding ist doch fast nur Win32...
Kommt mir jetzt *bitte* nicht damit, dass auch SWF P/I nutzt. SWF kann das, als trusted Asssembly, durch Internalcalls und somit ohne CAS zu sehr einzuschränken.

Nach dem 3. Schritt hast du CAS. Und wenn es SWF aus .Net 2.0 ist dürfte Avalon auch nicht mehr so weh tun.

[Luke1410]

@barf00s:
k, vertan, forget it VCL -> .Net-Umsetzung, dann stimmt der Satz wieder

Wie schon im letzten Post (ganz unten) beschrieben, fällt safed code erstmal flach (sofern es anders machbar ist), weil einfach zu aufwendig.

@Robert_G: Okok, schieben wir den Vorteil, CAS verwenden zu können ans Ende der Liste. Ändert leider nichts daran, dass zuerst unsafe code erstellt werden sollte.

[barf00s]

das klingt irgendwie komisch -

als ob DICH jemand zwinkt erst son dummfug zu produzieren, der dann sowieso NOCHEINMAL umgestellt wird?


Win32 -> unsafe blah -> pures .NET

sehr merkwürdig

[Robert_G]

Zitat von barf00s:

als ob DICH jemand zwinkt erst son dummfug zu produzieren, der dann sowieso NOCHEINMAL umgestellt wird?
Win32 -> unsafe blah -> pures .NET

Ist gar nicht dumm.
Ich denke mal, er will während des Portierens weiterhin kompilieren können. So kann seine App zu einer .Net App "reifen".

[Luke1410]

Jo, genau so sollte es sein.

Btw. ist das Problem weiterhin ungelöst... Werde wohl zwangsweise wirklich zu Klassen wechseln.
Nur kann ich immer noch nicht glauben, dass ich der einzige sein soll, der sich mit diesem Problem rumschlägt...

[Robert_G]

Zitat von Luke1410:

Jo, genau so sollte es sein.
Btw. ist das Problem weiterhin ungelöst... Werde wohl zwangsweise wirklich zu Klassen wechseln.

Die IMHO einzige, saubere Lösung für einen PBloodyRecord wäre eine TNiceClass. (Wobei man auf lange Sicht die T-Prefixe über board werfen sollte, sieht einfach "falsch" aus in .Net )

Zitat von Luke1410:

Nur kann ich immer noch nicht glauben, dass ich der einzige sein soll, der sich mit diesem Problem rumschlägt...

Ich selbst sehe keinen Grund für die Verwendung von Zeiger auf Records. Klassen sind genau dafür da. In .Net wirst du sogar dazu gezwungen, da value types immer per "Assignment by Copy" gehandhabt werden.
Das werden viele eingesehen haben und deshalb gar nicht mit dem Problem zu kämpfen gehabt haben.