Diskussion:C++/CLI

Die Seite ist seit 2007 eher nur noch auf sprachlicher Ebene, aber nicht inhaltlich aktualisiert worden. seitdem ist es mit der sprache nicht unbedingt bergauf gegangen. Die Integration von c++/cli wurde beginnend mit VisualStudio 2012 entfernt bzw. versteckt . Die zugrunde liegenden Implementierungsdateien waren anfangs noch vorhanden, sind aber seit VS 2013 RC/RTM entfernt. Die primäre Absicht von C++/CLI war Interop-Lösungen zu bieten, und nicht eine weitere Sprache mit vollem .NET Funktionsumfang. Für .NET basierte Desktop-Anwendungen sind C# oder VB.NET die Sprachen für die Zukunft. Sie können derzeit noch C++/CLI Winform Projekte entwickeln, aber die .NET Integration wird nie so vollständig sein wie in C# und VB, sondern im Gegenteil veraltern. Ausserdem ist man gezwungen eine veralterte Entwicklungsumgebung zu nutzen. (nicht signierter Beitrag von Titus36 (Diskussion | Beiträge) 11:28, 29. Jan. 2014 (CET))

Unverständlich bleibt mir (als jemand, der schon mal "zum Spaß" mit C++ herumgespielt hat, aber keineswegs die Sprache versteht) hier manches:

Das Akronym CLR ist nicht erklärt oder zumindest aufgelöst.

Es wird im gleichen Absatz einmal gesagt, daß nach Destruktion eines Objekts der Speicher von der automatischen Garbage Collection freigegeben wird. Kurz danach heißt es "Im Unterschied zu anderen Sprachen mit automatischer Speicherbereinigung (z.B. C# oder Java) wird hier also erstmals die Freigabe von Speicher und anderen Ressourcen nicht mehr zusammen mit Hilfe der Speicherbereinigung abgewickelt." (Hervorhebung von mir).

Die beiden Aussagen klingen widersprüchlich. --Spauli 13:28, 28. Aug 2004 (CEST)

Ok, ich habe mal versucht, die Sache etwas besser aufzudröseln. Die Betonung liegt jetzt auf der Unterscheidung zwischen einerseits Speicher und andererseits anderen Ressourcen. Schreib mal, ob es jetzt etwas verständlicher geworden ist. Poldi 18:43, 9. Okt 2004 (CEST)

Ist jetzt viel besser verständlich. Vielleicht kann man im letzten Absatz noch einen Verweis auf <CLR> einbauen, weil dort die Begriffe "managed" und "unmanaged" Code erklärt werden. Spauli 17:58, 10. Okt 2004 (CEST)

Performance-Vorteil gegenüber C#

Gibt es Quellenangaben zur Bemerkung mit den massiven 20%-25% Performancevorteilen gegenüber C#? Die Begründung scheint mir bzgl. des neuen Kontextes (CLR+MSIL) als nicht ganz stichhaltig..? -- 84.226.57.108 13:22, 5. Feb 2005 (CET)

Ich finde die Stelle zu 20%-25% Performancevorteil nicht mehr, habe aber folgende Quelle aufgetan: C++/CLI-Performance. Darin ist von 5%-30% die Rede. Was findest du an der Begründung nicht stichhaltig? Poldi 21:25, 8. Mär 2005 (CET)

Die angegebene Webseite gibt es nicht mehr, und die Historie des Compilers dürfte nach so vielen Jahren nicht mehr relevant sein. Ich nehme die betreffenden Stellen mal raus, bis jemand seriöse Quellen angibt. -- Gerd Fahrenhorst 22:06, 7. Okt. 2010 (CEST)

Vorteile von C++/CLI ggü. ISO-C++?

Irgendwie sind mir beim Lesen die Vorteile von dieser neuen Microsoft-Idee nicht ganz klar.

1. Kompatibilität

Wenn man eh Code umschreiben muss, kann man ihn auch so schreiben, dass er "klassischen" C++-GCs benutzt.

Es geht aber darum, dass er auf der CLI laufen soll. (Auch zur Interaktion mit in anderen Programmiersprachen geschriebenem Code.) Poldi 21:25, 8. Mär 2005 (CET)

Wenn ich also unveränderten C++-Code hernehme, läuft dieser also nicht mehr? Welche C++-Features funktionieren denn nicht mehr und warum? --RokerHRO 09:13, 9. Mär 2005 (CET)

Doch, der unveränderte C++-Code läuft noch! Poldi 20:41, 9. Mär 2005 (CET)

Also auch die ganzen "dreckigen" Teile von C++? Die C-"Erben", die ja auch Teil von C++ sind? Hmmm... --RokerHRO 08:32, 10. Mär 2005 (CET)

Ja, auch die. Wie das funktioniert, wäre sicher ein Thema für den Artikel. :-) Poldi 21:42, 10. Mär 2005 (CET)

2. Destruktor / Finalisierer

Der Destruktor ~Foo() gibt vom Objekt belegte Ressourcen frei. Was macht dann noch der der Finalisierer !Foo()?

Eigentlich nichts Bedeutungsvolles mehr. Ggf. vorteilhaft bei Handportierung von in anderen CLI-Sprachen geschriebenem Code. Poldi 21:25, 8. Mär 2005 (CET)

Hm. Das hilft mir auch nicht weiter. ;-( ---RokerHRO 09:13, 9. Mär 2005 (CET)

Aber es zwingt dich doch niemand, den Finalisierer zu benutzen. Wo ist das Problem? :-) Vielleicht liegt da ein Verständnisproblem vor - weder Destruktor noch Finalisierer machen für sich genommen überhaupt irgendetwas, wenn du sie nicht mit eigenem Code "befüllst". Poldi 20:41, 9. Mär 2005 (CET)

Ja, schon klar. Ich wollte wissen, wofür man eben diese beiden speziellen Methoden braucht. In welchen Fällen man einen (selbstgeschriebenen) Destruktor braucht und wann man eben den Finalisierer mit eigenem Code "füllen" muss. Das geht aus der knappen Beschreibung im Artikel nicht hervor. --RokerHRO 08:32, 10. Mär 2005 (CET)

Du musst den Finalisierer gar nicht verwenden. Du solltest es sogar vermeiden, überhaupt nur daran zu denken, den Finalisierer zu verwenden. Finalisierer sind pfui! :-) Näheres dazu unter Finalisierung. Poldi 23:40, 10. Mär 2005 (CET)

Hm, wieso führt man ein Feature ein, mit der Maßgabe, dieses doch bitte nicht zu verwenden, weil es total unnütz und pfui ist? Irgendeinen Verwendungszweck müssen sie doch haben. Oder eine Daseinsberechtigung, warum hat man sie sonst eingeführt? --RokerHRO 09:16, 11. Mär 2005 (CET)

Das habe ich ja schon eingangs beantwortet. (s.o.) :-) Poldi 16:19, 13. Mär 2005 (CET)

Ein Destruktor hingegen ist eine segensreiche Erfindung und sollte benutzt werden. Am besten erstellt man ihn gleichzeitig mit dem Konstruktor (im Sinne der RAII). Der wesentliche Punkt am Destruktor ist, daß dieser zu einem klar definierten Zeitpunkt garantiert aufgerufen wird - was man vom Finalisierer nicht sagen kann. ---84.63.103.172 10:52, 19. Apr 2006 (CEST)

In C++/CLI wird der Finalizer vom GC aufgerufen, aber nicht der Destruktor, dafür wird der Finalizer nicht aufgerufen wenn das Objekt auf dem Stack liegt da wird dann nur der Destruktor aufgerufen. Wenn man ein Objekt mit gcnew erstellt hat und es mit delete wieder freigibt, dann wird auch der Destruktor aufgerufen und nicht der Finalizer. Generell gilt es als beste Technik das ganze wie folgt zu machen:

public ref class Beispiel{
public:
    Beispiel(){} //C'tor
    ~Beispiel(){ this->!Beispiel(); } //D'tor ruft Finalizer auf
    !Beispiel(){} // Finalizer
};

Wichtig hierbei ist das this-> for dem Finalizeraufruf, denn ein Aufruf von !Beispiel() würde eine neue Temporäre Instanz von Beispiel erstellen und darauf den den operator! anwenden. Das ist ein Bug im aktuellen C++/CLI Compiler.--80.133.15.254 14:19, 14. Okt. 2006 (CEST)

Ist das wirklich ein Compiler-Bug? Meines Erachtens haben die da einfach beim anflanschen ihrer neuen Finalizeraufruf-Syntax gepfuscht, aber wenigstens korrekterweise der alten Verwendung im Zweifelsfall den Vorrang gelassen. 178.6.4.42 (01:18, 29. Okt. 2013 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

3. Was ist der Vorteil von diesen "Objektzeigern" gegenüber C++-Smartpointern?

Objektzeiger sind wie "normale" Zeiger mit einigen künstlich auferlegten Einschränkungen. Wenn du sie mit Smartpointern vergleichst, dann geht es eigentlich um den Unterschied zwischen Speicherverwaltung mit oder ohne Garbage-Collection (s. dort). Poldi 21:25, 8. Mär 2005 (CET)

In ISO-C++ sind ja auch Smartpointer realisierbar, deren "Smartness" eben darauf beruht, dass sie die Speicherverwaltung über einen GC abwickeln. --RokerHRO 09:13, 9. Mär 2005 (CET)

Eine GC basiert aber normalerweise nicht auf Smartpointern. (Auch die Objektzeiger sind übrigens keine Smartpointer!) Poldi 21:51, 9. Mär 2005 (CET)

Nunja, worauf die "Smartness" von Smartpointern beruht, variiert zw. den verschiedenen Smartpointer-Konzepten. Die einen machen Referenzzählung, die anderen "melden das Objekt bei einem GC an", andere stellen nur eine Debug-Schnittstelle zur Verfügung usw. - Was genau sind denn nun diese "Objektzeiger"? Was können sie? Was unterscheidet sie von normalen Zeigern? Was können sie, was man mit "herkömmlichen" Smartpointern nicht auch erschlagen könnte? --RokerHRO 08:32, 10. Mär 2005 (CET)

Nein, man verwendet keine Smartpointer, um Objekte bei der GC anzumelden - so funktioniert das einfach nicht. Du hast da eine falsche Vorstellung. - Nochmal: Objektzeiger sind keine Smartpointer. Objektzeiger sind sogar noch weniger als herkömmliche Zeiger. Man kann nicht einmal Zeigerarithmetik damit betreiben. Ein Objektzeiger zeigt immer auf den Anfang eines Objektes (im Gegensatz zu "normalen" Zeigern, die überallhin zeigen können!). Die Stärke der Objektzeiger besteht gerade in diesen Einschränkungen. Poldi 23:40, 10. Mär 2005 (CET)

Also sind Objektzeiger nur so eine Art "Handle", richtig? --RokerHRO 09:31, 11. Mär 2005 (CET)

Im Großen und Ganzen sind sie wie normale Zeiger. Auch in Programmiersprachen, in denen man mit Zeigern Grundsätzlich keine Zeigerarithmetik durchführen kann, heißen sie "Zeiger". Poldi 16:19, 13. Mär 2005 (CET)

Smartpointer haben mit GC im Sinne von .NET überhaupt nichts zu tun, da sie die Speicherverwaltung über Referenzzähler abwickeln, die GC von .NET hingegen mark-and-sweep-basiert ist. Das sind zwei völlig verschiedene Welten. Die .NET-GC ist (empirisch) effizienter als Smartpointer und kommt ohne jede Sonderbehandlung mit Referenzzyklen klar, dafür ist die Speicherbereinigung nichtdeterministisch. Und mark-and-sweep-GC lässt sich in reinem C++ auch überhaupt nicht implementieren, oder allenfalls mit erheblichem Aufwand für den Programmierer und exzessivem Einsatz von Template-Metaprogrammierung. Für mark-and-sweep-GC müssen nämlich Referenzen vom Stack aus verfolgbar sein, was ja schon mal nur funktionieren kann, wenn bekannt ist, welcher der Werte auf dem Stack ein Pointer ist und welcher nicht. (Diese Information steht in C++-Programmen zur Laufzeit standardmäßig nicht zur Verfügung und müsste daher vom Programmierer manuell „mitgeschleift“ werden. In .NET kümmert sich die Runtime um das alles.)

C++/CLI ist KEINE Erweiterung von ISO C++?

Es fehlen wesentliche und zentrale Elemente von ISO C++ (siehe z.B. http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=274&rl=1 und http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=275&rl=1). Es scheint sich daher nur um eine für Windows geeignete mit C++ nicht näher als Java oder C# verwandet Sprache zu handeln. Da Microsoft zu versuchen scheint, die mangelnde ISO/IEC 14882-Konformität herunter zu spielen oder gar zu verschleiern, erscheint mir ein Hinweis auf diesen wichtigen Punkt durchaus mehr als angebracht.

Die Aussage, dass wesentliche und zentrale Elemente von ISO-C++ fehlen, stimmt nicht. --Poldi 18:17, 28. Feb. 2007 (CET)

Es fehlt echte Mehrfachvererbung (es gibt nur Mehrfachvererbung von "interfaces", wie bei Java), es fehlt eine ISO-C++-konforme Standardbibliothek (<iostream> u.a.), diese würde Mehrfachvererbung benötigen. Die beiden Artikel zeigen weitere Inkompatibilitäten. Wenn ein korrektes ISO-C++-konformes Programm unter C++/CLI nicht mehr funktioniert oder etwas anderes tut, dann ist C++/CLI meiner Meinung nach keine Erweiterung von ISO-C++, sondern allenfalls ein inkompatibler C++-Dialekt, oder gar eine andere Sprache, die an C++ angelehnt ist. --RokerHRO 11:57, 1. Mär. 2007 (CET)

Es gibt sowohl Mehrfachvererbung als auch <iostream>, usw.

Die Artikel zeigen keine Inkompatibilitäten, sondern dass deren Autor ein Problem mit Logik hat. --Poldi 16:02, 1. Mär. 2007 (CET)