vergesst C++ ...

[groovemaster]

O'Rakl schrieb:

Python-Programme haben eine Eleganz und Kürze

Obwohl ich für sowas immer zu haben bin, ist das wirtschaftlich gesehen praktisch bedeutungslos. Dort kommt es hauptsächlich darauf an, dass ein Produkt funktioniert (Kunde) und dass es wartbar ist (Entwickler). Kurze Entwicklungszeiten sind zwar immer gern gesehen, aber Eleganz und wenig Code stehen oftmals in keinem direkten Verhältnis dazu.

O'Rakl schrieb:

Das liegt eben wesentlich an der dynamischen Typisierung und der
Orthogonalität.

So hat halt jede Sprache ihre Vor- und Nachteile und damit ihre Einsatzgebiete. Hast du schon mal versucht, mit Python einen Emulator zu schreiben? Vermutlich nicht. Irgendwie hast du noch kein gutes Argument gebracht, warum man C++ wegen Python vergessen sollte. Und GC ist erst recht keines, da man in C++ schon lange bewährte Ressourcenmechanismen verwendet, die stetig verbessert werden, um mehr Sicherheit zu bekommen. Egal ob das jetzt über Sprachmittel realisert wird (zB Smart Pointer) oder über Compilerverbesserungen. Und GC ist dafür kein Allheilmittel, im Gegenteil, es hat nicht zu unterschätzende Nachteile. Nichtlineares Laufzeitverhalten ist zB einer, dh in Echtzeit Systemen ist GC praktisch nutzlos. Zudem ist das wichtigste immer noch, dass man Ressourcen sicher benutzen kann und nicht, dass diese automatisch freigegeben werden.
Ausserdem sei noch erwähnt, so wie ich Orthogonalität verstehe, magst du gegenüber C Recht haben, aber C++ bietet da wesentlich mehr. Sicher gibt es auch hier Einschränkungen (zB keine Referenzen auf Referenzen), aber die wesentlichen Unterschiede, die dann über Eleganz und Codelänge entscheiden, liegen bei den syntaktischen Gegebenheiten. Und da spielt idR auch der persönliche Geschmack eine Rolle. Bisher hab ich nur einige Beispile in Python gesehen, die mich nicht wirklich vom Hocker gehauen haben. Dennoch würde ich nicht behaupten, dass man Python vergessen kann, weil C++ viel besser ist.

O'Rakl schrieb:

Ansonsten: Zeigerarithmetik, Pointer-Casting ("(void*)"...)

Scheinbar denkst du zu viel C.

O'Rakl schrieb:

und Garbage Collection gleichzeitig geht nicht

GC ist ein Konzept und beschreibt keine konkrete Implementierung. Mit konsequenter Benutzung von Smart Pointern hast du auch in C++ GC.

[Gast]

kingruedi schrieb:

@Optimizer

IMHO kann man sowas nur auf Sprachebene einschränken und nicht mit einem selbstgebauten Typ.

So ein quatsch. Wenn eben jemand Zeiger manipuliert, dann ist er selbst schuld, wenn der GC ihm um die Ohren fliegt. Du könntest genauso behaupten, dass man mit C++ nicht programmieren kann, weil

int *i=0x0;
*i=10;

möglich ist.

C++ ist eben eine Sprache, die den Programmierer nicht vor sich selbst schützt. Das kann man meinetwegen an C++ kritisieren (oder auch lieben).

Ach komm, warum habe ich extra zweimal erwähnt, dass man dazu nicht mutwillig die Arbeit des GC sabotieren muss?
Es reicht eine simple Übergabe eines Objekts per Referenz (und damit meine ich eine C++-Referenz), die kann intern auf einen Zeiger abgebildet werden und bumm. Oder ich hab ein char[], was natürlich vom GC verwaltet werden soll und geb nen char* mal schnell an ne DLL rüber, während der GC das bereinigen anfängt. Bumm.
Warum meinst du, habe ich geschrieben

Optimizer schrieb:

Du könntest mir jetzt natürlich Böswilligkeit unterstellen und C++ soll vor Böswilligkeit ja gar nicht schützen - aber schon das Übergeben eines Objekts als Referenz (&) kann intern das Übergeben eines Zeigers sein. Rohe Zeiger machen alle Sicherheit beim GC-Heap kaputt und solange man von allem die Adresse holen kann, ob beabsichtigt oder nicht, ob explizit oder nicht ...

damit du es nicht liest?

groovemaster schrieb:

Zudem zeigt es, dass GC unter C++ möglich ist, auch wenn man diesbezüglich Erweiterungen benötigt.

Hach ja. Dann sind wir uns doch einig.

Ich finde es nur etwas seltsam einer Sprache vorzuwerfen, dass sie kein GC erlaubt, obwohl sie dafür nie konzipiert war.

Es war nie als Vorwurf formuliert. Bitte sag mir wie ich mich noch vorsichtiger ausdrücken kann als mit "dass _kann_ man als Nachteil auffassen, _wenn_ man einen GC mag..."

[Ben04]

Vor einiger Zeit hab ich mich an einem GC für C++ versucht. Eigentlich war alles lösbarer Natur bis auf das Verschieben der Objekte. Der Knackpunkt heißt this. Das Problem ist, dass man in keiner Methode einen Heap komprimiren kann. Dies könnte ja den this Pointer verändern wodurch sämtliche Zugriffe auf das Objekt danach fehlschlagen. Mit Smartpointer ist hier nur mit einem sehr hässlichen Syntax etwas zu machen und sobald mehrer Threads ins Spiel kommen ist es nicht meher lösbar. Höchstens noch ein Hack der den this Pointer verändern würde.

C++ braucht um GC fähig zu werden eine Spracherweiterung. GC-Spracherweiterung sind dazu allerdings nicht nötig. Legentlich muß man den this Pointer konsequent duch einen Smartpointer ersetzen können.

[Power Off]

Ben04 schrieb:

C++ braucht um GC fähig zu werden eine Spracherweiterung.

So ein Käse. Es gibt GC System für C++, die auch funktionieren.

Wichtig ist auf jeden Fall die Verwendung einer eigenen Referenz-Klasse, damit Objekte, die noch benutzt werden, nicht vom GC hopps genommen werden können. Das ist doch logisch, oder!

[groovemaster]

Optimizer schrieb:

Es war nie als Vorwurf formuliert. Bitte sag mir wie ich mich noch vorsichtiger ausdrücken kann als mit "dass _kann_ man als Nachteil auffassen, _wenn_ man einen GC mag..."

Die Bemerkung von mir bezog sich vielmehr aufs Orakel und nicht auf dich. Wer GC unbedingt möchte, kann das durchaus als Nachteil bei C++ empfinden. Nur finde ich es seltsam, der Sprache dies vorzuwerfen. Immerhin beschwere ich mich bei Assembler auch nicht, dass dort kein OO Konzept vorhanden ist. Verstehst du, was ich meine?

[Gast]

Power Off schrieb:

Ben04 schrieb:

C++ braucht um GC fähig zu werden eine Spracherweiterung.

So ein Käse. Es gibt GC System für C++, die auch funktionieren.

Wichtig ist auf jeden Fall die Verwendung einer eigenen Referenz-Klasse, damit Objekte, die noch benutzt werden, nicht vom GC hopps genommen werden können. Das ist doch logisch, oder!

Versteh halt, dass der C++-Compiler implizit bei einer ganzen Reihe von Gelegenheiten Zeiger verwendet, rohe Zeiger, nicht deinen Referenztyp. Und die vorhandenen GCs funktionieren nicht toll, Stichwort Sicherheit und Performance. Sicherheit kann man irgendwie noch erreichen, wenn man sich selber an enge Regeln hält, für deren Einhaltung kein Compiler und keine Sprachbeschränkung sorgt, die daher leicht verletzt werden können, ohne dass böse Absicht dahinter steht. Die Performance ist ohne die Möglichkeit, Objekte zu verschieben, für die meisten Allokationsprofile im Eimer.

groovemaster schrieb:

Optimizer schrieb:

Es war nie als Vorwurf formuliert. Bitte sag mir wie ich mich noch vorsichtiger ausdrücken kann als mit "dass _kann_ man als Nachteil auffassen, _wenn_ man einen GC mag..."

Die Bemerkung von mir bezog sich vielmehr aufs Orakel und nicht auf dich. Wer GC unbedingt möchte, kann das durchaus als Nachteil bei C++ empfinden. Nur finde ich es seltsam, der Sprache dies vorzuwerfen. Immerhin beschwere ich mich bei Assembler auch nicht, dass dort kein OO Konzept vorhanden ist. Verstehst du, was ich meine?

Klar, zu 100%.

[O'Rakl]

<Über virtuelle Basisklassen.>

Eben. Objektorientierter Assembler. Ich bin sicher, es gibt auch einen
Weg, mit C++ Listenkomprehension nachzubilden oder Funktionen als Parameter an
generische Algorithmen zu übergeben, wahrscheinlich wird das ein halbes
Dutzend Bildschirmseiten voll von STL-Code erfordern und beim Lesen nur noch an
der Endung .cpp vom Compilat zu unterscheiden sein.

Mit Python macht man sowas mit eins, zwei Zeilen. Und zwar so, daß man es
in Kapitel 1 auf Seite 3 einer Python-Einführung -- für Leute, die noch nie zuvor eine Zeile programmiert haben -- erklären kann und nicht
erst in Kapitel 45 auf Seite 1200 eines Buches für Programmierer mit
Hochschulausbildung.

Das ist das, was ich mit "vergesst C++" meinte.

[Power Off]

Optimizer schrieb:

Versteh halt, dass der C++-Compiler implizit bei einer ganzen Reihe von Gelegenheiten Zeiger verwendet, rohe Zeiger, nicht deinen Referenztyp.

Das ist doch völlig wurscht, was der Compiler macht.

Eine richtige Garbage Collection greift nur für die Objekte, die dort sauber an- und abgemeldet werden. Ein Refernzzähler verhindert bei Zuweisungen etc., daß Objekte gekillt werden, die noch verwendet werden. Natürlich muß der Programmierer mit dem Ding auch entsprechend umgehen.

Lies doch mal ein Buch über Algorithmen oder Software-Techniken in C++, es gibt auch in solchen Büchern gelegentlich Referenz-Implementationen von verschiedenen Garbage Collector Typen. Wenn man die Sache versteht und richtig einsetzt, dann funktioniert das auch.

Es gibt in der Industrie massig Systeme, die für C++ GC einsetzen, aus was für Gründen auch immer. Das ist gar nicht so ungewöhnlich.

[Ben04]

Power Off schrieb:

So ein Käse. Es gibt GC System für C++, die auch funktionieren.

Ich meinte ein GC nach Java/.NET/... Vorbild.

Power Off schrieb:

Wichtig ist auf jeden Fall die Verwendung einer eigenen Referenz-Klasse, damit Objekte, die noch benutzt werden, nicht vom GC hopps genommen werden können. Das ist doch logisch, oder!

Ach und wie sieht deine Reference-Klasse aus? Also boost::shared_ptr ist jedenfals nicht sicher. A referenziert B und B A aber niemand sonst A oder B. boost::shared_ptr wird das nicht fangen. Der Java GC aber. Desweiteren ist ein heapkomprimierender Java GC in der Speicherfreigabe und Reservierung in der Geschwindigkeit und Speicherausnutzung nicht zu schlagen. Den Heap kann man komprimieren wann man will. C++s new und delete machen die Arbeit genau dann wenn man sie aufruft und nicht dann wenn man nichts besseres zu tun hat.

C++s new und delete haben sicher Vorteile aber ein GC nach Java Stil auch.

[Gast]

Power Off schrieb:

Optimizer schrieb:

Versteh halt, dass der C++-Compiler implizit bei einer ganzen Reihe von Gelegenheiten Zeiger verwendet, rohe Zeiger, nicht deinen Referenztyp.

Das ist doch völlig wurscht, was der Compiler macht.

Eine richtige Garbage Collection greift nur für die Objekte, die dort sauber an- und abgemeldet werden. Ein Refernzzähler verhindert bei Zuweisungen etc., daß Objekte gekillt werden, die noch verwendet werden. Natürlich muß der Programmierer mit dem Ding auch entsprechend umgehen.

Nein, das ist kein richtiger Garbage Collector. So ein GC erkennt zum Beispiel keine zirkulären Abhängigkeiten. Und es erklärt auch nicht, warum es wurscht sein soll, wenn irgendwo noch ein temporärer roher Zeiger auf ein Objekt vorhanden ist.

Lies doch mal ein Buch über Algorithmen oder Software-Techniken in C++, es gibt auch in solchen Büchern gelegentlich Referenz-Implementationen von verschiedenen Garbage Collector Typen. Wenn man die Sache versteht und richtig einsetzt, dann funktioniert das auch.

Das würde ich dir mal empfehlen, du hast es dringender nötig. Eat this:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx
http://de.wikipedia.org/wiki/Garbage_Collector#Mark_.26_Compact-Algorithmus
und lerne, wie eine anständige garbage collection funktioniert.

Es gibt in der Industrie massig Systeme, die für C++ GC einsetzen, aus was für Gründen auch immer. Das ist gar nicht so ungewöhnlich.

Den Eindruck konnte ich nicht gewinnen.

[Power Off]

Ben04 schrieb:

Ach und wie sieht deine Reference-Klasse aus? Also boost::shared_ptr ist jedenfals nicht sicher. A referenziert B und B A aber niemand sonst A oder B. boost::shared_ptr wird das nicht fangen. Der Java GC aber. Desweiteren ist ein heapkomprimierender Java GC in der Speicherfreigabe und Reservierung in der Geschwindigkeit und Speicherausnutzung nicht zu schlagen. Den Heap kann man komprimieren wann man will. C++s new und delete machen die Arbeit genau dann wenn man sie aufruft und nicht dann wenn man nichts besseres zu tun hat.

Ach was! Der Java GC ist saulahm. Mit einer schnelleren GC wäre Java viel besser. Außerdem blockiert der Java GC die Ausführung sämtlichen VM-Codes. Das ist doch totaler Blödsinn. Wenn die Architektur richtig ist, dann kann man den Heap im Hintergrund kompakten ohne die Objekte zu betreffen, die gerade in der Verwendung sind. Die sollten auch mal ein Buch lesen.

[Gast]

LOL, du weißt es natürlich besser als die Luschen von Sun. Naja, die haben halt einfach nichts drauf. Und wenn sie dich nicht um Hilfe bitten, warum solltest du dich aufdrängen, da hast du natürlich schon Recht.

Scherz beiseite. Dass der GC die Ausführung ewig blockiert ist natürlich Unsinn. Die Threads werden nur in der Remark- und in der Kompaktierungsphase angehalten, was der kleinste Teil der Arbeit ist. Und dass der GC saulahm ist, ist natürlich auch nicht richtig. Ich habe Gen0-Zeiten von ein paar hundertstel Millisekunden, bei denen einige Megabyte frei werden. Wenn die Anwendung nicht mit aller Gewalt so allokiert, dass die Objekte alle genau den Eden- und Surviver-Space gerade noch überleben, dann kann der GC gar nicht langsam sein. Ein bisschen tunen kann oft einiges bewirken und ein klassischer Heap mit Freispeicherliste ist auch lahm. Mit angepassten Allokatoren kann man natürlich eine allgemeine GC-Implementierung übertreffen, wie es Volkard vor einiger Zeit mal geschafft hat. Irgendwie ein paar Jahre oder so hat er gebraucht bis er das nötige Wissen zusammenhatte, meinte er dazu. Vielleicht findest du den Thread wieder, er hieß "@Gregor" oder so.

[Ben04]

O'Rakl schrieb:

Eben. Objektorientierter Assembler. Ich bin sicher, es gibt auch einen
Weg, mit C++ Listenkomprehension nachzubilden oder Funktionen als Parameter an
generische Algorithmen zu übergeben, wahrscheinlich wird das ein halbes
Dutzend Bildschirmseiten voll von STL-Code erfordern und beim Lesen nur noch an
der Endung .cpp vom Compilat zu unterscheiden sein.

Und? Der STL Code muß ja nicht von einem Compilat zu unterscheiden sein (auch wenn er es ist!). In Pyhton ist es sogar ein Compilat von daher sehe ich nicht wo da ein Vorteil sein.

Power Off schrieb:

Eine richtige Garbage Collection greift nur für die Objekte, die dort sauber an- und abgemeldet werden. Ein Refernzzähler verhindert bei Zuweisungen etc., daß Objekte gekillt werden, die noch verwendet werden. Natürlich muß der Programmierer mit dem Ding auch entsprechend umgehen.

lol Mal darüber nachgedacht wie sich ein Objekt denn Abmelden soll wenn es keine Destruktoren gibt? Ein GC funktioniert nicht nach dem Prinzip, dass sich Objekt anmelden und abmelden sondern, dass sie sich melden oder besser, dass sie gemeldet werden. Der Stack meldet sämtlich Objekt auf ihm. Diese melden sämtliche Objekte die sie enthalten. Dies wird fortgesetzt bis keine neue Objekte mehr auftauchen. Nun werden alle gefundenen Objekt irgendwo hintereinander im Speicher plaziert. Jede nachfolgende Allokation kostet dann eine Addition und die Freigabe gibt es für lau. Und weißt du was das beste ist? Man kann egal wann Speicher holen und nicht nur dann wenn man gerade bei Reservieren ist.

Und wenn dir das nicht reicht kann ich dir dein boost::shared_ptr nochmal brechen. Vielleicht verstehts du dann die Problematik mit this denn dies ist genau die gleiche Schwachstelle.

class Foo;
vector<Foo*>foo_register;

class Foo
{
public:
  void do_register(){
    foo_register.push_back(this);
  }
};
void bar(){
  {
    shared_ptr<Foo>ptr(new Foo);
    ptr->do_register();
  }
  use_register(); // Bum
}

Ach ja ich darf ja keinen rohen Zeiger übergeben, aber wie mache ich das? Hab ja nur this.

Um ehrlich zu sein gibt es Möglichkeiten den this Pointer in einen Smartpointer zu verwandeln. Dies geht bei speziellen referencezählenen Smartpointer und bei jedem GC. Diesen mußt du kann auch konsequent einsetzen! Das heist

class Foo{
public:
  void foo();
  void bar(){
    smart_ptr<Foo>real_this(make_this(this));
    real_this->foo();
  }
  // und nicht etwa
  void func(){
    foo(); // Bumm!
  }
};

Wenn jetzt noch Threads ins Spiel kommen dann geht diese Konvertirungskrücke gar nicht mehr! Es könnte ja sein, dass zwischen Funktionseintritt und real_this this verändert wird. Affig nicht?

Die einzige Lösung ist aus this einen Smartpointer zu machen.

Power Off schrieb:

Ach was! Der Java GC ist saulahm. Mit einer schnelleren GC wäre Java viel besser. Außerdem blockiert der Java GC die Ausführung sämtlichen VM-Codes. Das ist doch totaler Blödsinn. Wenn die Architektur richtig ist, dann kann man den Heap im Hintergrund kompakten ohne die Objekte zu betreffen, die gerade in der Verwendung sind. Die sollten auch mal ein Buch lesen.

Nur mal so als Frage : Was stellst du dir bei einem referenzählenden Smartpointer unter Heapkompaktirung vor?

[groovemaster]

O'Rakl schrieb:

Funktionen als Parameter an
generische Algorithmen zu übergeben, wahrscheinlich wird das ein halbes
Dutzend Bildschirmseiten voll von STL-Code erfordern und beim Lesen nur noch an
der Endung .cpp vom Compilat zu unterscheiden sein.

Nö, da täuschst du dich. Mit C++ sind sogar teilweise Sachen relativ einfach zu realisieren, die ich selbst nicht für möglich gehalten hätte. Als Lektüre kann ich dir dazu boost.lambda empfehlen.

O'Rakl schrieb:

Mit Python macht man sowas mit eins, zwei Zeilen. Und zwar so, daß man es
in Kapitel 1 auf Seite 3 einer Python-Einführung -- für Leute, die noch nie zuvor eine Zeile programmiert haben -- erklären kann und nicht
erst in Kapitel 45 auf Seite 1200 eines Buches für Programmierer mit
Hochschulausbildung.

Du willst uns also sagen, dass C++ umfangreicher ist und nicht von Dummies erlernt werden kann, im Gegensatz zu Python. Hmm...wirft irgendwie kein gutes Licht auf Python Programmierer, oder? Dass C++ keine Sprache ist, die einfach ist oder in 21 Tagen erlernt werden kann, ist kein Geheimnis. Dafür ist sie zu "mächtig". Erzähl uns doch einfach mal was neues.

[Power Off]

Optimizer schrieb:

LOL, du weißt es natürlich besser als die Luschen von Sun. Naja, die haben halt einfach nichts drauf. Und wenn sie dich nicht um Hilfe bitten, warum solltest du dich aufdrängen, da hast du natürlich schon Recht.

Lies mal ein Buch über VM-Design oder Compilerbau, dann siehst Du, was für ein Müll die Java VM ist.

- stackbasiert mit FORTH-Konstruktionen: schwierig optimierbar.
- steinaltes GC Konzept.
- language specification hinkt der Implementation hinterher: konzeptionslos.
- primitiver Compiler (siehe Source), fernab jeglicher geordneter Compiler-Modelle (zu deutsch: wirres Flickwerk).

Optimizer schrieb:

Scherz beiseite. Dass der GC die Ausführung ewig blockiert ist natürlich Unsinn. Die Threads werden nur in der Remark- und in der Kompaktierungsphase angehalten, was der kleinste Teil der Arbeit ist.

Kommt darauf an, wieviel Objekte Du hast. Schätz mal, warum JBuilder oder Eclipse so lahm sind. Importier mal ein Real-Life Projekt (z.B. ein Framework mit 3000-6000 Java-Klassen) in JBuilder, und dann kannst Du Dir Kaffee und Kuchen, sowie Zigaretten nebendran stellen.

Optimizer schrieb:

Wenn die Anwendung nicht mit aller Gewalt so allokiert, dass die Objekte alle genau den Eden- und Surviver-Space gerade noch überleben, dann kann der GC gar nicht langsam sein. Ein bisschen tunen kann oft einiges bewirken

Das ist nicht die Aufgabe des Java-Programmierers, seine Programme auf die GC hin zu designen, da ja der GC transparent sein soll.

Es ist Aufgabe von Sun, seinen Java-Kunden eine ordentliche VM zu liefern, sonst wandern die von Java schnell zu C# (was auch nicht besser wäre) oder zu C++.

(Es gibt auch kommerzielle, gute VMs für Java, und gute Compiler, ich weiß, ich weiß, aber die hinken der aktuellen defacto Implementation von Sun immer hinterher)

[Power Off]

Ben04 schrieb:

lol Mal darüber nachgedacht wie sich ein Objekt denn Abmelden soll wenn es keine Destruktoren gibt? Ein GC funktioniert nicht nach dem Prinzip, dass sich Objekt anmelden und abmelden sondern, dass sie sich melden oder besser, dass sie gemeldet werden. Der Stack meldet sämtlich Objekt auf ihm.

Wie wär's Du lernst erstmal C++ richtig, bevor Du solche Behauptungen aufstellst.

Objekte für einen GC werden meist mit Placement-new und -delete erzeugt, sowie natürlich im Konstruktor und virtuellen Destruktor registriert / deregistriert. Solche Objekte müssen von einer virtuellen Basisklasse abgeleitet werden (z.B. "GC_Object"), die die Implementation für Placement-new und -delete sowie den passenden Konstruktor und Destruktor, sowie Copy-Construktor und Copy-Assignment mitbringt.

Selbstverständlich müssen sich Objekte direkt oder indirekt am GC anmelden, damit er weiß, welche Objekte wo sind.

So funktioniert auch die Absicherung für Multithread-GCs.

[Gast]

Power Off schrieb:

Kommt darauf an, wieviel Objekte Du hast. Schätz mal, warum JBuilder oder Eclipse so lahm sind. Importier mal ein Real-Life Projekt (z.B. ein Framework mit 3000-6000 Java-Klassen) in JBuilder, und dann kannst Du Dir Kaffee und Kuchen, sowie Zigaretten nebendran stellen.

Hmmmm also beim Starten von Eclipse geht bei mir eine halbe Sekunde mit garbage collection drauf. Das ist zwar wesentlich mehr als ich erwartet hatte, macht aber prozentual bei einem Warmstart höchstes ein Zehntels aus, bei einem Kaltstart mit ständigem Festplattenzugriff natürlich noch weniger. Wo genau soll Eclipse wegen GC langsam sein?

Das ist nicht die Aufgabe des Java-Programmierers, seine Programme auf die GC hin zu designen, da ja der GC transparent sein soll.

Dann gehen wir doch von einem Java-Entwickler aus, der seine Anwendung nicht auf den GC hin optimiert. Der ist meistens besser dran, wie einer, der einen klassischen Heap benutzt und auch nicht spezielle Allokatoren für seine Anwendung schreibt. Der Vorteil manueller Speicherverwaltung kommt nur zum Tragen, wenn man spezielle für das Anwendungsprofil angepasste Allokatoren schreibt.

Selbstverständlich müssen sich Objekte direkt oder indirekt am GC anmelden, damit er weiß, welche Objekte wo sind.

Das ist so nicht völlig korrekt. Objekte melden sich für die Finalisierung an (im Falle von Java heißt das, falls die Klasse java.lang.Object.finalize() redefiniert). Das sind die wenigsten.

Objekte für einen GC werden meist mit Placement-new und -delete erzeugt

Zusammen mit der obigen Aussage komme ich zu dem Schluss, dass du dir nicht darüber im klaren bist, wie ein kopierender Kollektor arbeitet. Ein kopierender Kollektor muss gar nichts über die Objekte wissen und sowas wie delete braucht er nicht, weil er referenzierte Objekte verschiebt und über den anderen Speicher einfach darüber allokiert. Warum siehst du dir nicht zur Abwechslung mal die von mir verlinkten Artikel an oder suchst dir selber welche heraus?

[Power Off]

Optimizer schrieb:

Warum siehst du dir nicht zur Abwechslung mal die von mir verlinkten Artikel an oder suchst dir selber welche heraus?

OK, mach ich -- morgen!

Das Thema interessiert mich.

Aber ich finde, dass delete und Destruktoren auf jeden Fall bei C++ dazugehoeren. Sonst sind die Probleme ja nicht weiter verwunderlich.

[kartoffelsack]

Und wenn es doch ginge,
gäbe es keine Standard-Collection für C++ und damit wären Klassen nicht mehr
zwengsläufig untereinander kompatibel, wenn sie auf verschiedenen
Collection-Mechanismen angewiesen sind.

Das ist in C++/CLI meines wissens auch so. Entweder GC oder new. Mach die Sache natürlich noch komplexer.

Wenn die simple Aufgabe, einen Speicherbereicht sicher zu belegen und
vor allem sicher wieder freizugeben, mehr als 1500 Seiten Lektüre erfordert,
dann -- da werden wir uns doch einig sein -- stimmt mit einer solchen
Programmiersprache didaktisch und womöglich konzeptuell etwas ganz entschieden nicht.

Es ist definitiv ein didaktisches Problem. 90% aller Bücher für einsteiger behandeln char* und Zeigerarithmetik in zig Kapiteln und erst ganz am Schluss findest Du vielleicht etwas über std::string (aber das schein mit neueren Büchern ja jetzt langsam besser zu werden). std::auto_ptr ist auch kein allgemein einsetzbarer Smartpointer. D.h. einfach wird es erst, wenn man sich mal boost geholt hat. Das ist natürlich ne Rieserhürde. Und selbst wenn man das alles toll richtig installiert und compiliert nach der Installation der IDE Deiner Wahl da wäre, bin ich mir immer noch nicht sicher, ob mans nem Anfänger empfehlen kann. Zwar ist es prinzipiell einfach schön und elegant. Aber kleine Fehler führen zu völlig kryptischen Compilerfehlern ...
Und wenn man dann schon mal ein bisschen was kann, brauch man immer noch ewig, nur um sich ne Bibliothek zu suchen, wenn man was über UDP verschicken will ...

Wars Volkard oder Marc++us der mal gemeint hat, dass die c++-Comunity so lang gebraucht hat, die Templates zu kapieren, dass sie alles andere vergessen haben.

Naja, aber wenn man C++ mal ein bisschen kann, naja, dann ist es schon viel geiler als andere Sprachen und ich denk man ist durch die besseren Ausdrucksmöglichkeiten langfristig auch produktiver (die gewonnene Zeit verbringt man aber beim Suchen nach irgendwelchen soap, xml oder GUI-Bibliotheken). Ist halt ein steiniger Weg.

[maximAL]

groovemaster schrieb:

So hat halt jede Sprache ihre Vor- und Nachteile und damit ihre Einsatzgebiete. Hast du schon mal versucht, mit Python einen Emulator zu schreiben?

gut, dass das noch kommt, nachdem man seitenlang alles getan hat um klar zu machen, das C++ eh alles kann, nur natürlich viel besser.
schön auch das obligatorische low-level beispiel.