WinAPI-Ersatz in Windows Longhorn
-
operator void schrieb:
Welche Aspekte von .NET kann man denn mit CLI/C++ nicht ausnutzen?
z.B. bieten die Generics einige Feinheiten, auf die man nur mit C++ Zugriff hat, wie auch Herb Sutter vor kurzem in seinem Interview erwähnt hat (siehe C++ Forum).
Dann kommt die Interoperabilität der mächtigen C++ Features mit den Features des Frameworks, was mit anderen Sprachen einfach so nicht möglich ist. Sehr interessant dazu ist folgendes: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/BakerDozen.aspWie auch immer, selbst wenn das nicht die Welt ist (ist es auch nicht), frage ich mich, wie du zu deiner gegenteiligen Behauptung kommst, dass man nur mit C# das Framework ausreizen könne.
-
net schrieb:
aber am besten ist es, wenn man zur .NET-basierten entwicklung c# nutzt. nur damit kann man .NET voll ausreizen.
Beweise?
Kann ich nach diesem Artikel nämlich nicht bestätigen:
http://msdn.microsoft.com/netframework/archive/default.aspx?pull=/library/en-us/dnvs05/html/movnetwfx.aspC++/CLI gives you tremendous choice for how to access the functionality offered by the CLR (and by WinFX). If you have a new application to write, the advantages of writing it in C++/CLI to target the CLR are overwhelming. You can have robustness and reliability, access to important managed APIs, and developer productivity from available managed libraries, without giving up access to native libraries or to any C++ paradigms. This decision is clear: write new applications for Windows in C++/CLI as managed applications.
...
C++/CLI gives you all the power and flexibility of C++ on the CLR, gives you true deterministic destruction even for managed types, and gives you the highest-performance interop. It's a natural choice for any C++ programmer who has an application that should target the CLR.Nach diesem Artikel würde ich C# nicht mal mehr mit Kneifzange anfassen!
Nein, im ernst: C++/CLI erlaubt "mehr" unter .NET, wie z.B. das man Objekte selbst deleten darf. Was hier sogar als Vorteil genannt wird. Und da man C++ und C++/CLI mixen darf, kann man sogar rechenintensive Codeteile in nativen C++ coden, so das man das optimale aus seiner Applikation raus holen kann.
-
Artchi schrieb:
net schrieb:
aber am besten ist es, wenn man zur .NET-basierten entwicklung c# nutzt. nur damit kann man .NET voll ausreizen.
Beweise?
keine beweise
hab' dunkel in erinnerung dass mal einer problemchen hatte irgendwas in c++ unter .NET hinzukriegen, was mit c# ganz einfach gewesen wäre.
-
also rede doch nicht so ein scheiss. das kommt doch erst mit visual studio .net 2005. das kannst du doch noch gar nicht ausprobiert haben.
-
aus wikipedia.de :
Vergleich mit anderen .NET-Sprachen
Ein weiterer Grund, warum mit C++/CLI erstellte Programme etwas schneller sind, als in anderen .NET-Sprachen erstellte Programme, ist der C++-Compiler, den es im Vergleich mit anderen Sprachen wie z.B. C# schon viel länger gibt, und in den schon beträchtlich mehr Aufwand zur Optimierung des erzeugten Codes gesteckt wurde. Zur Zeit (2004) sind .NET-Programme, die mit C++/CLI erstellt werden etwa 20 bis 25 Prozent schneller als andere.
Eine Besonderheit von C++/CLI ist die Mischbarkeit von managed und unmanaged Code. Bisher ist C++/CLI die einzige Sprache, mit der man sowohl managed als auch unmanaged Code in einer einzigen Programmdatei mischen kann.
Gibts da ein Tut drüber, über das CLI meine ich?
-
asdfasdf schrieb:
also rede doch nicht so ein scheiss. das kommt doch erst mit visual studio .net 2005. das kannst du doch noch gar nicht ausprobiert haben.
Der Tonfall ist nicht angemessen.
Was kommt erst mit VS2005?
-
asdfasdf schrieb:
also rede doch nicht so ein scheiss. das kommt doch erst mit visual studio .net 2005. das kannst du doch noch gar nicht ausprobiert haben.
hab' ich auch nicht. war wer anders. ausserdem geht bei meinem ollen vs2002 das auch schon. schimpft sich 'verwaltete c++ anwendung'
-
@net: Die Rede war von C++/CLI und nicht von Managed C++.
-
@asdf! Ach? Und ManagedC++ ist nicht C++/CLI? Du bist ja ein ganz lustiges Kerlchen. ManagedC++ ist C++/CLI 1.0 und mit VC++ 2005 kommt C++/CLI 2.0. ManagedC++ wird als Begriff jedoch nicht mehr verwendet. Alles klar? Also mach hier die Forenmitglieder nicht so blöde an.
-
alles klar
-
net schrieb:
asdfasdf schrieb:
also rede doch nicht so ein scheiss. das kommt doch erst mit visual studio .net 2005. das kannst du doch noch gar nicht ausprobiert haben.
hab' ich auch nicht. war wer anders. ausserdem geht bei meinem ollen vs2002 das auch schon. schimpft sich 'verwaltete c++ anwendung'
Verwaltete C++ Anwendung = ManagedC++ = C++/CLI 1.0
Passt schon!
-
Ok, nennen wie es Version 1 und 2. Aber zwischen diesen Versionen liegen gewaltige Unterschiede.
-
Artchi schrieb:
Verwaltete C++ Anwendung = ManagedC++ = C++/CLI 1.0
Nur zu deiner Information: _ICH_ habe Visual C++.Net 2005 bereits ausprobiert und kann sagen, dass Managed C++ gar nicht == C++/CLI ist. Ehrlich gesagt ist es eine völlig neue Sprache; inkompatibel
allen alten managed C++ Source umschreiben, oder einen Compilerschalten benutzen, der die neue Syntax disablet! C++/CLI wurde als Bezeichnung erst nach manageD C++ erfunden, da sonst wohl von Anfang an von C**/CLI die Rede gewesen wäre.
-
Das ändert nichts daran, das nur die Syntax geändert wurde. Das steht auch in dem von mir geposteten Artikel. Und nicht ich oder wir "nennen es mal" Version 1 und 2, sondern das ist orig. von MS und der ECMA so benannt, das die neue Syntax C++/CLI 2.0 heißt. Und du kannst auch in VC++ 2005 die alte Syntax per Compiler-Parameter reaktivieren. Lies mal deine Compiler-Hilfe durch, es kommt am Ende immer Code der selbe Code raus.
-
Ich freu mich schon auf Avalon
-
ich freu mich nicht auf ein betriebssystem was so langsam ist wie java.
-
Brauchst dich nciht drauf zu freuen, kannst jetzt schon damit rumspielen
-
Ich werd auch damit rumspielen, sobald ich mal wieder Platz auffa platte hab
-
Irendwie versteh ich das mit der VM nicht richtig.
Wenn .net die WinAPI ersetzen soll dann muss es ja auch in allen Bereichen wo noch WinAPI eingesetzt wird einsetzbar sein. Was ist denn jetzt mit den ganz einfachen exes? zb Notepad und Minesweefer. Werden denn auch die alle in einer VM laufen oder werden da doch noch die ganz normalen PEs eingesetzt?
Ich meine wer sagt, dass .net eine VM braucht und, dass die WinAPI von .net abgelöst wird der sagt doch eigentlich auch, dass das PE exe Format begraben wird. Ds baut ja auf nativ Code auf und nicht auf irgendeinem interpretirten Code, also .net fällt aus, und die WinAPI ist ja nicht mehr einsetzbar.
Irgenwie erscheint mir das ganze nicht so richtig geheuer.
Bitte um Aufklärung.
-
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