Diskussion:C++/CLI

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)

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)

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

Letzter Kommentar: vor 18 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)Beantworten

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)

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.