WinAPI-Ersatz in Windows Longhorn
-
Optimizer schrieb:
frage ich mich, wie du zu deiner gegenteiligen Behauptung kommst
Nur um meinen Ruf als CLI/C++-Fan zu retten: Du wolltest den anderen da quoten. Ich hab ein paar Minuten später deine Gedanken gehabt
-
operator void schrieb:
Optimizer schrieb:
frage ich mich, wie du zu deiner gegenteiligen Behauptung kommst
Nur um meinen Ruf als CLI/C++-Fan zu retten: Du wolltest den anderen da quoten. Ich hab ein paar Minuten später deine Gedanken gehabt
Oh verdammt. Das geht natürlich nicht, dass ich dir hier einfach was in die Schuhe schiebe. Aber keine Sorge, ich hab schon einen Schuldigen:
dEUs schrieb:
Optimizer schrieb:
Das stimmt nicht. Tatsächlich kann man nur mit C++/CLI alle Möglichkeiten des Frameworks bis ins letzte Detail nutzen. Ob das jetzt ausschlaggebend ist, muss jeder für sich wissen.
Welche Aspekte von .NET kann man mit C# nciht ausnutzen? (voids Frage kopiert und berichtigt)
Dies hat bei mir den Eindruck erweckt, dass du auch diese Frage gestellt hast und weil ich ja nicht 5 Stunden damit verbringen kann, dein Post durchzulesen, habe ich das nicht groß kontrolliert.
Ne, sorry natürlich.
-
Welche Aspekte von .NET kann man mit C# nciht ausnutzen?
z.B in Generics casten? Templates von Generics? Generische (function-)pointer? Wirklich typisiertes boxing/unboxing von System.ValueType Typen ohne Casting? Zusätzliche Operatoren wie op_PointerDereference und op_MemberSelection? Kontrolle über den Entrypoint der Applikation in die CLR, sowie den Austritt? System::Object via System::IntPtr zuweisen und umgekehrt, sowie von Hand auf Wert setzen (Ich weise System::Object den Wert 0x89ff3ea6 zu)
Theoretischer Direktzugriff auf den nicht gepinnten Speicher, was ziemlich gefährlich sein kann? Unmanaged Zeiger auf managed Zeiger und vielleicht auch umgekehrt? Aber das brauchen wohl nur die wenigsten... 