eines der Mankos an C++ ist sicherlich die dynamische Speicherreservierung und -freigabe. Hier hat man leider zu viel von C übernommen. Andere Sprachen, wie zB Java, bieten mit GC ein anderes Konzept. Leider ist das imo noch schlechter und nur für "faule" Entwickler brauchbar.

Daher meine Frage, wie würdet ihr ein dynamisches Speichermanagement konzipieren?

Mir schwebt da ein ähnlicher Ansatz wie C/C++'s automatischer Speicher vor. Man könnte ein Schlüsselwort oder Typmodifizierer verwenden, ähnlich wie es C++/CLI mit managed Speicher macht, zB:

foo a("blubb"); // Objekt a vom Typ foo konstruiert in automatischem Speicher
foo^ b("blobb"); // Objekt b vom Typ foo konstruiert in dynamischem Speicher

Und genau wie automatischer Speicher wird dieser am Ende des Scopes freigegeben ohne zusätzlichen Aufwand des Programmierers. Bleibt die Frage, wie man dynamischen Speicher über Scopegrenzen hinweg transferiert ohne zu kopieren. Da hilft wieder die neue Typsignatur:

foo^ bar()
{
    return ...;
}

Ein Compiler kann diese als "Referenz" handeln und so optimieren.
Ihr seht schon, es ist also eine Art in die Sprache integrierter auto_ptr.

Welche Ansätze seht ihr? Wie würdet ihr das machen?

vorab: Mir ist hier noch nicht ganz klar, welches Problem Du mit Deinem neuen Konzept addressieren möchtest.

Zum Konzept: Wann soll wer dem Compiler mitteilen, dass der Speicher freigegeben werden kann ... oder soll das per reference counting doch automatisiert geschehen ?
Soll man statt eines deletes dann den Scope seiner "P^-Variablen" verlassen (was einem aber nur bedingt weiterhilft ... der Aufgerufene hat evtl. den Pointer weitergereicht) ?

Und wo ist dann der Vorteil ggü. einem GC ?

Insgesamt stelle ich mir das nicht ganz einfach vor, wenn man mit diversen Speicherbereichen (bzw. P^-Vars) gleichzeitig arbeitet, die aber überlappende Lebenszyklen haben....(und ich dachte, gerade für solche Fälle sei doch dynamische Speicherverwaltung konzeptionell wichtig. Wenn es nur um die Speichergröße geht, könnte man dem Compiler einfach erlauben, bestimmte Stackobjekte selbst auf dem Heap zu verwalten)....

hmmm, muß ich nochmal drüber nachdenken.....

Prinzipiell sehe ich die dynamische Speicherverwaltung nicht als per se problematisch. Wenn man sich gegen Speicherlecks wehren möchte, würde es IMO genügen ein "deleteAll()" einzuführen, das der Runtime mitteilt, dass an dieser Stelle kein Heapspeicher mehr erwartet wird....

Gruß,

Simon2.

Hi,

eines der Mankos an C++ ist sicherlich die dynamische Speicherreservierung und -freigabe. Hier hat man leider zu viel von C übernommen. Andere Sprachen, wie zB Java, bieten mit GC ein anderes Konzept. Leider ist das imo noch schlechter und nur für "faule" Entwickler brauchbar.

ein paradebsp zum thema wie beginn ich eine sachlich vernuenftige diskussion?

zum rest, wie war noch mal der unterschied zu diversen refcounted /shared (smart)pointern implementierungen, ausser kurz mal compiler umschreiben/erweitern?

Ich weiß deshalb nicht was du willst, weil es für 1. und 2. schon Lösungen gibt. Es gibt Leute die sich dazu Gedanken gemacht haben und Lösungen anbieten. Für 1. gibts z.B. SmartHeap, welches laut c't-Testbericht bis zu 30 fache (nicht 30%!) Leistungssteigungen bei der Heap-Arbeit bringen kann (durchschnitt liegt bei 2 bis 6 fach, immer noch sehr gut).

Für 2. gibts Smartpointer. Gut, ist jetzt von der Syntax nicht wirklich angenehm, wäre besser wenn man ein ^-Zeichen nehmen könnte. Ich mache mir da mir kurze typedefs, dann wirds angenehmer. Z.B. für Strings habe ich folgendes:

typedef std::auto_ptr<std::string> string_ptr;

Damit wird mein Sourcecode trotz des Einsatzes von Smartpointern lesbar. Mit Codevervollständingung ist es sogar angenehmer als noch das ^-Zeichen auf der Tastatur zu suchen.

Wenn dich GC-Technik stört, kann ich dich nicht auf 2009 oder 2010 vertrösten... leider.

Ich verstehe deine Kritikpunkte nämlich nicht völlig. Heutzutage unterscheidet man bei der Resourcenfreigabe oft zwei Arten:

- Resourcen, die sofort freigegeben werden müssen, wenn sie nicht mehr gebraucht werden. Dazu gehören Socketverbindungen, File-Handles, usw. Hier sehe ich Handlungsbedarf. Meiner Meinung nach decken hier weder C++-style Destruktoren noch try-finally Aktionen den Bedarf wirklich ab, da sie ausschließlich Scope-basiert arbeiten.

- Resourcen, die nur freigegeben werden müssen, wenn Bedarf steht, meistens Speicher. Hier verstehe ich nicht, was du gegen GC hast. GC ist meistens effizienter als deterministische Destruktion, weil viel Speicher auf einmal freigegeben werden kann, dagegen wenn du ein komplexes Objekt oft erzeugst und destruierst, dann wird davon der Destruktor aufgerufen der sowas "nutzloses" macht wie den freien Speicher wieder in die Freispeicherliste einzuhängen. Von davon referenzierten Objekten wird der Destruktor aufgerufen, usw. kann ewig aufwändig sein, vor allem völlig nutzlos wenn du gerade gar keinen Bedarf an Heap-Speicher hast.

Deine Frage zielte jetzt anscheinend nur auf Speicherverwaltung ab, also frage ich mich: wo siehst du bei heutigen modernen GCs dringenden Handlungsbedarf? In real-world Applikationen macht der GC meistens weniger als 1% der Laufzeit aus, während Sachen wie Referenzcounnting, scope-basierte Speicherfreigabe oft viel teurer sind und auch nicht immer hinreichend. GC ist also sicherer, effizienter und einfacher als andere Verfahren die es heute gibt (im allgemeinen Fall).

Trotzdem würde mich dein Vorschlag natürlich auch interessieren. Die Begründung "faul" ist übrigens eher etwas, was für GC spricht.

vorab: Mir ist hier noch nicht ganz klar, welches Problem Du mit Deinem neuen Konzept addressieren möchtest.

Kein konkretes. Mir geht es lediglich darum, wie man grundlegend ein dynamisches Speichermanagement konzipieren könnte, ohne auf bisherige Konzepte Rücksicht nehmen zu müssen, aber trotzdem alle Vorteile zu vereinen ohne die entsprechenden Nachteile.

Simon2 schrieb:

Zum Konzept: Wann soll wer dem Compiler mitteilen, dass der Speicher freigegeben werden kann ... oder soll das per reference counting doch automatisiert geschehen ?
Soll man statt eines deletes dann den Scope seiner "P^-Variablen" verlassen (was einem aber nur bedingt weiterhilft ... der Aufgerufene hat evtl. den Pointer weitergereicht) ?

Und wo ist dann der Vorteil ggü. einem GC ?

Darum geht es ja eben. Die Antworten darauf kann ich dir nicht geben, deshalb wollte ich wissen, was ihr für ein gutes Konzept haltet. Oder seit ihr mit den bisherigen wunschlos glücklich?

daHa schrieb:

ein paradebsp zum thema wie beginn ich eine sachlich vernuenftige diskussion?

Nein, da hast du was falsch verstanden. Das soll keine Diskussion werden, sondern vielmehr eine Ideensammlung. Wer dieses oder jenes Konzept anpreisen oder darüber ablästern will, zB GC, soll das in einem anderen Thread machen.

Artchi schrieb:

Also ich verstehe dein Problem nicht. Worauf willst du hinaus? Willst du darüber diskuttieren, was man an C++' dynamischer Speicherverwaltung bessern könnte?
1. Rein vom Backend? Also was passiert zur Laufzeut?
2. Oder willst du die Handhabung für den Programmierer z.B. über neue Features verbessern?

Nein, ja und ja. Mir geht es zwar nicht konkret um C++, aber man könnte zB eine "fiktive" C++ Sprache erstmal als Orientierung nehmen. Wie würde das dynamische Speicherhandling in "Fiktiv C++" aussehen, wenn es keine Zeiger gäbe? Ich hoffe, du verstehst worauf ich hinaus will. Und dabei geht es mir um Kernfunktionalität der Sprache, und nicht um irgendwelche zusätzlichen Klassen, Bibliotheken oder konkrete Implementationen bzw. den darin benutzten Strategien. Also grob gesagt, wie kann ich in meinem Quellcode den Compiler veranlassen, ein dynamisches Objekt anzulegen bzw. zu zerstören? Und was passiert dabei bzw. mit diesen Objekten hinter den Kulissen?

OK, um es vllt. nochmal etwas zu verdeutlichen. Momentan stören mich beim C++ Speichermanagement folgendes:

- eingeschränkte Funktionalität und aufwändige Syntax beim Erzeugen/Zerstören über new/delete
  - ähh, wie kann man nochmal Arrays bei der Erzeugung initialisieren?
  - wieso muss ich delete [] mitgeben, wenn ich ein Array habe?
    (die Antwort ist mir schon klar, da anhand eines Zeigers nicht festgestellt werden kann, ob Array oder nicht; aber da kommen wir zum nächsten Punkt)
  - wieso werden Zeiger verwendet? ich möchte zB dynamische Objekte genauso einfach und unkompliziert wie automatische verwenden können
- Sicherheitsmängel
  - delete a; delete a; zu schreiben ist kein Problem, die Anwendung ist damit jedoch kaputt
  - vergessene deletes verursachen Speicherleichen
  - ein "unbeabsichtigt" überschriebener Zeiger, der vorher das Ergebnis von new enthielt, hinterlässt ebenfalls Speicherleichen
  - nicht exception-safe

Mehr fällt mir jetzt erstmal nicht, gibt aber bestimmt noch weitere Sachen.

Zum Thema GC. Den schliesse ich erstmal aus folgenden Gründen aus:

- aufgrund der Unberechenbarkeit von Freigaben nur bedingt geeignet für Real-Time Systeme
- unzureichende Effizienz
  zB wird innerhalb eines Scopes ein dynamisches Objekt angelegt
  sobald der Scope verlassen wird, soll auch dieses Objekt sterben und damit der Speicher freigegeben werden
  ein GC lässt sich hier jedoch unbestimmt viel Zeit mit der Freigabe

Optimizer schrieb:

Trotzdem würde mich dein Vorschlag natürlich auch interessieren. Die Begründung "faul" ist übrigens eher etwas, was für GC spricht.

Ja, das war ja auch nicht negativ gemeint. Programmierer sind grundsätzlich faul, und da ist es gut, wenn man soviel wie möglich Arbeit abgenommen bekommt. Nur ist das momentan der einzige Punkt, den ich bei einem GC positiv bewerten würde. Das soll jetzt aber kein Diskussionsthread zum Thema GC werden. Also zurück zum eigentlichen Thema.

- unzureichende Effizienz
zB wird innerhalb eines Scopes ein dynamisches Objekt angelegt
sobald der Scope verlassen wird, soll auch dieses Objekt sterben und damit der Speicher freigegeben werden
ein GC lässt sich hier jedoch unbestimmt viel Zeit mit der Freigabe

Das erhöht die Effizienz. Wir reden hier ja von Speicherverwaltung, nicht von Socket-Verbindung-Verwaltung. Jedes kleine Fitzel 16B explizit in die Freispeicherliste hundertmal einzutragen anstatt 1mal 1,6 KB freizuräumen ist langsamer. Das musst du dir wirklich bewusst machen, wenn du über Speicherverwaltung nachdenkst.

Also zurück zum eigentlichen Thema.

Gerne. Kannst du das Thema bitte noch genauer eingrenzen, Speicherverwaltung gehört dazu, aber GC nicht? Ich will mich echt konstruktiv beteiligen, aber mir ist das manches nicht klar. Beschränkst du dich auf nicht-automatische Speicherverwaltung?

Deine Frage zielte jetzt anscheinend nur auf Speicherverwaltung ab, also frage ich mich: wo siehst du bei heutigen modernen GCs dringenden Handlungsbedarf? In real-world Applikationen macht der GC meistens weniger als 1% der Laufzeit aus, während Sachen wie Referenzcounnting, scope-basierte Speicherfreigabe oft viel teurer sind und auch nicht immer hinreichend. GC ist also sicherer, effizienter und einfacher als andere Verfahren die es heute gibt (im allgemeinen Fall).

GCs eignen sich aber nicht dazu kritische Ressourcen freizugeben, da destruieren eben nicht garantiert ist.

groovemaster schrieb:

- unzureichende Effizienz
zB wird innerhalb eines Scopes ein dynamisches Objekt angelegt
sobald der Scope verlassen wird, soll auch dieses Objekt sterben und damit der Speicher freigegeben werden
ein GC lässt sich hier jedoch unbestimmt viel Zeit mit der Freigabe

Das erhöht die Effizienz. Wir reden hier ja von Speicherverwaltung, nicht von Socket-Verbindung-Verwaltung. Jedes kleine Fitzel 16B explizit in die Freispeicherliste hundertmal einzutragen anstatt 1mal 1,6 KB freizuräumen ist langsamer. Das musst du dir wirklich bewusst machen, wenn du über Speicherverwaltung nachdenkst.

Darüber hinaus kommt hinzu, dass moderne GC-Verfahren grade bei kurzlebigen Objekten (d.h. die nur in einem engen Scope existieren) besonders effektiv sind - Stichwort Generation Scavenging. Heutzutage gibt es wirklich keinen Grund mehr, vor Garbage-Collection angst zu haben. Höchstens man ist auf Echtzeitfähigkeit angewiesen.

tfa

Optimizer schrieb:

groovemaster schrieb:

- unzureichende Effizienz
zB wird innerhalb eines Scopes ein dynamisches Objekt angelegt
sobald der Scope verlassen wird, soll auch dieses Objekt sterben und damit der Speicher freigegeben werden
ein GC lässt sich hier jedoch unbestimmt viel Zeit mit der Freigabe

Das erhöht die Effizienz. Wir reden hier ja von Speicherverwaltung, nicht von Socket-Verbindung-Verwaltung. Jedes kleine Fitzel 16B explizit in die Freispeicherliste hundertmal einzutragen anstatt 1mal 1,6 KB freizuräumen ist langsamer. Das musst du dir wirklich bewusst machen, wenn du über Speicherverwaltung nachdenkst.

Darüber hinaus kommt hinzu, dass moderne GC-Verfahren grade bei kurzlebigen Objekten (d.h. die nur in einem engen Scope existieren) besonders effektiv sind - Stichwort Generation Scavenging. Heutzutage gibt es wirklich keinen Grund mehr, vor Garbage-Collection angst zu haben. Höchstens man ist auf Echtzeitfähigkeit angewiesen.

tfa

wobei mir einraetsel ist warum zeugs das sowieso nur in einem bekannten scope exestiert ueberhpt in den gc kommen soll/muss.

wie kanns performatner sein wenn ich eine komponete hab die ueber was nachdenken muss anstatt ohne nachdenken das richtige zu machen?

und das 100x16b vs 1x1,6kb freigeben, woher weis der gc das es durchgaengige speicherbereiche sind die er einfach so als block freigeben kann?
wurde da schon zeit vorverbraten um zu analysieren und organisieren?
und wird diese zeit in der effizienzberechnung nicht beruecksichtigt?

Darüber hinaus kommt hinzu, dass moderne GC-Verfahren grade bei kurzlebigen Objekten (d.h. die nur in einem engen Scope existieren) besonders effektiv sind - Stichwort Generation Scavenging. Heutzutage gibt es wirklich keinen Grund mehr, vor Garbage-Collection angst zu haben.

nur wenn man es selbst schon richtig managed, dann ist ein GC nur ueberfluessig.

tfa schrieb:

Darüber hinaus kommt hinzu, dass moderne GC-Verfahren grade bei kurzlebigen Objekten (d.h. die nur in einem engen Scope existieren) besonders effektiv sind - Stichwort Generation Scavenging. Heutzutage gibt es wirklich keinen Grund mehr, vor Garbage-Collection angst zu haben.

nur wenn man es selbst schon richtig managed, dann ist ein GC nur ueberfluessig.

Managt man es denn richtig? Es ist doch grade der Vorteil, dass man mit GC sehr viel weniger selber managen muss. Die eingesparte Zeit kann man prima nutzen, um Software zu entwicklen, statt sich tagelangen Debug-Sessions hinzugeben um Speicherlecks zu finden.
Die Performance-Einbußen durch GC sind meiner Meinung nach auch zu vernachlässigen. Die Steigerung der Entwickler-Performance allerdings ganz und gar nicht.

tfa

wobei mir einraetsel ist warum zeugs das sowieso nur in einem bekannten scope exestiert ueberhpt in den gc kommen soll/muss.

Soll/muss keineswegs so sein. Was ich sinnvoll auf den Stack packen kann, sollte ich da auch hintun, GC sollte IMHO kein Ersatz für Stack-Allokationen sein. Es soll ein Ersatz für new ... delete sein, für Auto-Pointer und so stuff.

und das 100x16b vs 1x1,6kb freigeben, woher weis der gc das es durchgaengige speicherbereiche sind die er einfach so als block freigeben kann?
wurde da schon zeit vorverbraten um zu analysieren und organisieren?
und wird diese zeit in der effizienzberechnung nicht beruecksichtigt?

Moderne GCs deallokieren Objekte nicht explizit und fassen dann freie Speicherblöcke zusammen. Stattdessen verschieben sie die Objekte die noch gebraucht werden in einen anderen Bereich, der Rest ist dann per Definition wieder freier Speicher. Allokieren geht dann auch deutlich schneller, weil nicht ein freier Speicherblock gesucht wird, denn der freie Speicher ist imer defragmentiert. Man erhöht genauso wie beim Stack einfach den "free space" Pointer.

Du kannst dir mal diesen Artikel ansehen: http://msdn.microsoft.com/msdnmag/issues/1100/GCI/
Da ist ein bisschen Wirtschaftler-Geblubber drin wie toll GC ist, aber man gewinnt einen guten Überblick darüber, wie sie funktioniert.

rapso schrieb:

tfa schrieb:

Darüber hinaus kommt hinzu, dass moderne GC-Verfahren grade bei kurzlebigen Objekten (d.h. die nur in einem engen Scope existieren) besonders effektiv sind - Stichwort Generation Scavenging. Heutzutage gibt es wirklich keinen Grund mehr, vor Garbage-Collection angst zu haben.

nur wenn man es selbst schon richtig managed, dann ist ein GC nur ueberfluessig.

Managt man es denn richtig? Es ist doch grade der Vorteil, dass man mit GC sehr viel weniger selber managen muss. Die eingesparte Zeit kann man prima nutzen, um Software zu entwicklen, statt sich tagelangen Debug-Sessions hinzugeben um Speicherlecks zu finden.
Die Performance-Einbußen durch GC sind meiner Meinung nach auch zu vernachlässigen. Die Steigerung der Entwickler-Performance allerdings ganz und gar nicht.

tfa

rapso meint sowas, worauf du nicht eingehst:

void foo()
{
   std::string str;
}

Wo muß ich da mehr managen und nachdenken, als wenn ich einen GC hätte? Genau das mache ich, wenn ich ein Objekte anlege, das nur in einem Scope Gültigkeit haben soll. In DEM Fall, ist ein GC in keiner Weise hilfreicher. Und der GC räumt mein str-Objekt auch nicht schneller auf, als wenn der Compiler nur den Stackpointer hoch oder runter zählt.

Klar, wenn ich mit new etwas anlege, halt dynamisch (worum es hier in dem Thread auch geht!!!), kann mir ein GC Zeit beim Entwickeln einsparen. Richtig. Aber das werden wir in C++ auch ab 2009 laut neuen Standard machen können. Da es in diesem Thread aber laut groovemaster nicht speziell um C++ geht, ist das eigentlich auch nebensächlich.

Und falls es um Performance geht: wie kann ein GC generell schneller sein als ein new/delete? Notfalls nimm ich SmartHeap dazu. was aber auch beweist, das ein Heap-Management nur "schlau" implementiert sein muß. Völlig unabhängig ob ich einen GC nehme oder eine Library wie SmartHeap. Ein GC ist schliesslich keine Zauberei, oder doch? Und weiterhin: auch ei GC kann schlecht implemntiert und designed sein. Wer garantiert mir, wenn ich einen GC nehme, das ich auch Perfomancevorteile bekomme? Rein Zufällig mögen die GC von MS gut sein, aber die SUN Java-GC ist z.B. schlechter als der von anderen Java-Implementierern. Auch wenn ich das Weltbild einiger SUN-Fans damit zerstöre...

Artchi

PS: Mist, ich habe jetzt Java mit ins Spiel gebracht. Das wird mir jetzt zum Verhängnis!

groovemaster schrieb:

Ihr seht schon, es ist also eine Art in die Sprache integrierter auto_ptr.

wozu sollte man auto_ptr in die Sprache integrieren, wenn man es genauso gut als Template-Klasse schreiben kann, wie es bisher ist?

wozu sollte man auto_ptr in die Sprache integrieren, wenn man es genauso gut als Template-Klasse schreiben kann, wie es bisher ist?

Das Argument vieler ist halt, das alles Buildin sein muß. Egal ob es Sinn macht oder nicht. Genau das werden wir aber in Zukunft in C++ weniger sehen, laut C++ Komitee. Mehr über Libraries und Templates, in die C++-Core nur noch das nötigste.

auch ei GC kann schlecht implemntiert und designed sein. Wer garantiert mir, wenn ich einen GC nehme, das ich auch Perfomancevorteile bekomme? Rein Zufällig mögen die GC von MS gut sein, aber die SUN Java-GC ist z.B. schlechter als der von anderen Java-Implementierern. Auch wenn ich das Weltbild einiger SUN-Fans damit zerstöre...

Einen schlechten GC kann man ja leicht ersetzen (also leicht im Sinne von ich nehme einen besseren GC und packe den dazu und entferne den schlechten, nicht leicht im Sinne von ich schreib mir mal eben einen guten GC ;)). Die manuelle Verwaltung zu ändern dürfte deutlich schwieriger sein

Wenn es um Performance geht (GC soll schneller sein), sage ich, dann kann ich einfach die Standardlibrary durch eine bessere tauschen (z.B. die SmartHeap nutzt). Hab ich also auch einen Austausch vorgenommen. Muß ich zwar neu kompilieren, interessiert aber den Endanwender nicht, welche Lib ich nutze. Hauptsache das Ding rennt.

Wenn es um den Programmierer geht: spielt das "Austauschen können" des GCs keine Rolle. Entweder ich nimm einen GC oder nicht. Beides kann ich heute machen. Ich kann es manuell machen, ich kann Smartpointer nehmen, oder ich nehme einen GC. Und ab 2009 haben wir eh offiziell einen GC im ISO-C++. Die Diskussion werden wir ab dann hoffentlich hier nicht mehr haben.

Wobei man zu den Geschwindigkeitsvorteilen die Optimizer aufgezählt hat aber sagen muss, dass dies oft nur die Frage des Allokators/Deallokators ist. Man kann ja auch einen Allokator/Deallokator schreiben, der wie ein moderner GC funktioniert. Der Deallokator sagt einfach nur "der Speicher hier ist zwar noch reserviert aber eigentlich frei" und der Allokator durchsucht diese Liste bevor er neuen Speicher anlegt (oder so ähnlich).

Hmmm. Ein Grundproblem bleibt aber auch mit eigenen Allokatoren bestehen: Du machst jede Freigabe explizit. Der Allokator kann das natürlich ansammeln und dann größere Bereiche auf einmal freigeben, aber *irgendetwas* machst du immer beim Deallokieren. Ein gescheiter GC dagegen deallokiert nicht.

Artchi schrieb:

Und falls es um Performance geht: wie kann ein GC generell schneller sein als ein new/delete?

IEs ist in der Praxis wirklich oft so (ich sag jetzt mal absichtlich nicht "meistens"). Das hat viele Gründe, new muss freien Speicher suchen, delete muss ausgeführt werden (ein guter GC macht kein delete), Speicher kann fragmentieren und schlechte Lokalität haben, es gibt hunderte Gründe, warum ein GC schneller oder langsamer ist. Du wirst natürlich trotzdem immer was konstruieren können, wo eine klassische Heap-Verwaltung geiler ist. In der Praxis ist er aber oft schneller. Ein eigener Allokator kann wieder noch besser sein, aber darauf hast du doch auch eher selten Lust.

aber die SUN Java-GC ist z.B. schlechter als der von anderen Java-Implementierern

Der ist wirklich grottig, hat Pause-Times im Zehntelsekunden-Bereich, da schaudert's mich echt. Die, die am meisten rumlabern, bauen echt den schlechtesten.

Und ab 2009 haben wir eh offiziell einen GC im ISO-C++. Die Diskussion werden wir ab dann hoffentlich hier nicht mehr haben.

Was glaubst du, wie die dann erst losgeht. "soll ich ihn verwenden oder nicht?"

@Optimizer
dieses irgend was ist aber vermutlich nicht der Rede wert. Wenn doch, dann kann man bei der manuellen Verwaltung die Freigabe ja einfach auf einen günstigeren Zeitpunkt verlegen. (So wie man den meisten GCs ja auch sagen kann "Nerv getz nich!" ;))

Artchi schrieb:

Ja, worum geht es denn nun? Um die Manuelle Verwaltung vs. Automatische Verwaltung? Oder um Performance?

Wenn es um Performance geht (GC soll schneller sein), sage ich, dann kann ich einfach die Standardlibrary durch eine bessere tauschen (z.B. die SmartHeap nutzt). Hab ich also auch einen Austausch vorgenommen. Muß ich zwar neu kompilieren, interessiert aber den Endanwender nicht, welche Lib ich nutze. Hauptsache das Ding rennt.

Bei manueller Verwaltung kannst du natürlich die Allokatoren austauschen, aber du kannst nicht einfach die interne Verwaltung umstricken. Das wollte ich eigentlich sagen. Man kann ja teilweise die GCs sogar vor dem starten einer Anwendung wählen.

Wenn doch, dann kann man bei der manuellen Verwaltung die Freigabe ja einfach auf einen günstigeren Zeitpunkt verlegen.

Dann ist dieses Vormerken dieses etwas und spätestens das kannste nicht verlegen. Wie ich sagte, man kann die Deallokationen ansammeln und wird sicherlich auch gemacht. Am Ende steht man aber immer 2 Nachteilen da:
- man muss beim delete *irgendwas* machen
- man muss freie Speicherbereiche wieder zusammenfassen
Man hat viel rumgeforscht an manueller Speicherverwaltung, schon länger als an GCs und da gibt es alle möglichen Tricks. <Troll>Deshalb ist sie überhaupt noch gerade so konkurrenzfähig. </Troll>

Der GC hat natürlich auch Arbeit die manuelle Speicherverwaltung nicht hat, zum Beispiel Referenzen ändern und Write-Barriers implementieren. Scheint aber durchaus sehr tragbar zu sein. Vor allem aber kann ich beim GC nahezu beliebig mehr Laufzeit einsparen und dafür mehr Speicher verbrauchen, also eintauschen, das ist schon sehr nett.

rapso schrieb:

tfa schrieb:

Darüber hinaus kommt hinzu, dass moderne GC-Verfahren grade bei kurzlebigen Objekten (d.h. die nur in einem engen Scope existieren) besonders effektiv sind - Stichwort Generation Scavenging. Heutzutage gibt es wirklich keinen Grund mehr, vor Garbage-Collection angst zu haben.

nur wenn man es selbst schon richtig managed, dann ist ein GC nur ueberfluessig.

Managt man es denn richtig?

Die meisten scheinen dazu unfaehig zu sein. Leuten die soeinen anschein machen empfehle ich auch aus voller ueberzeugung auf Java/C#/VB zu setzen.

Es ist doch grade der Vorteil, dass man mit GC sehr viel weniger selber managen muss.

alles hat seinen preis, lange ladezeiten, suboptimale leistung, massig speicherverschwendung, einmal laenger nachdenken oder immer diese kosten in kauf nehmen... aber vielen faellt das garnicht mehr auf, leider.

Die eingesparte Zeit kann man prima nutzen, um Software zu entwicklen, statt sich tagelangen Debug-Sessions hinzugeben um Speicherlecks zu finden.

wenn man kontrolle abgibt, hat man weniger ahnung was passiert und dadurch kommen erst die langen debugsessions. es waere unsinnig zu glauben, dass nur weil ein objekt "garbage" ist statt deletet zu werden, dass man sich nicht um sein ableben kuemmern muss, denn resourcenfreigabe usw. muss dann immer noch gemacht werden, was viele programmierer von sprachen mit GC absolut nicht drauf haben ala "das liegt am GC, mein program hat kein Leak, das kann garnicht sein, das passiert nur in C++."

Die Performance-Einbußen durch GC sind meiner Meinung nach auch zu vernachlässigen.

ich finde den imensen speicheranstieg von manchmal 10fach gegenueber dem vorher existierendem tool in anderen sprachen nicht vernachlaessigbar. die manchmal langen ladezeiten bei denen man sich wundert, ob das OS den doppelklick realisiert hat und die starke traegheit der anwendungen sehr uebel.

Die Steigerung der Entwickler-Performance allerdings ganz und gar nicht.

die entwicklungsgeschwindigkeit ist nicht trvial zu messen. jemand der mit C# anfaengt ist zu anfang sicherlich viel schneller als jemand der in assembler schreibt, aber sobald man seine sprache beherrscht ist die entwicklungsgeschwindigkeit von jedem individuell und nicht sonderlich von der highlevel-sprache abhaengig, vor allem wenn man sein Hirn oefter trainiert und nicht auf vorgefertigtes setzt, kann mann bessere leistung bringen... ist wie mit dem kopfrechnen.