WPF like GarbageCollector
-
otze schrieb:
Kellerautomat schrieb:
Kann man, aber wozu sollte man das wollen? RAII ist viel besser.
Nein ist es nicht. Manchmal ist das Eine besser, mal das andere. Besonders die Fähigkeit, Speicher zu komprimieren kann bei vielen kleinen Objekten sehr viel ausmachen.
Soso, wann ist denn ein GC besser? Ein GC unterstuetzt in ueblichen Managed-Sprachen nicht mal Dtoren, da faengts schon mal an.
Und fuer kleine Objekte benutzt du eben einen Small Object Allocator, dann ist das naemlich wurscht.Ansonsten wuerde mich interessieren, ob das auch schonmal jemand in der Praxis nachgemessen hat. Klingt in der Theorie toll, aber ich kenne niemanden, ders auch mal getestet hat.
-
Unter den Features von C++11 steht was von "Minimal support for garbage collection and reachability-based leak detection". Geht das in die Richtung?
-
TNA schrieb:
Unter den Features von C++11 steht was von "Minimal support for garbage collection and reachability-based leak detection". Geht das in die Richtung?
Ja, das ist es, worauf ich mich bezog. Dies definiert ein Interface für GCs und macht das Verhalten einiger Operationen auf Pointern undefiniert (sofern GC aktiv).
An implementation may have relaxed pointer safety, in which case the validity of a pointer value does not
depend on whether it is a safely-derived pointer value. Alternatively, an implementation may have strict
pointer safety, in which case a pointer value that is not a safely-derived pointer value is an invalid pointer
value unless the referenced complete object is of dynamic storage duration and has previously been declared
reachable (20.6.4). [ Note: the effect of using an invalid pointer value (including passing it to a deallocation
function) is undefined, see 3.7.4.2. This is true even if the unsafely-derived pointer value might compare equal
to some safely-derived pointer value. — end note ] It is implementation defined whether an implementation
has relaxed or strict pointer safety.Die üblichen Implementierungen haben relaxed pointer safety, das heißt all die Schweinereien, die einen GC total durcheinander bringen würden, sind nach wie vor erlaubt. Und die Spezialfunktionen, um Pointer rechable/unreachable zu erklären sind einfach leer.
Aber prinzipiell stehen sinnvolle Regeln zur Verfügung, was in einem Programm mit GC erlaubt ist und was nicht.
-
Kellerautomat schrieb:
Soso, wann ist denn ein GC besser? Ein GC unterstuetzt in ueblichen Managed-Sprachen nicht mal Dtoren, da faengts schon mal an.
Nein, das ist falsch. Sie unterstützen zumeist keine _deterministischen_ dtoren. Ich wünschte mir, du wärst bei GCs genauso pedantisch wie beim C++ Sprachstandard, dann müssten wir diese diskussionen gar nicht führen, weil unnötig.
-
Oh, ich glaube nicht, dass es im Interesse einer sachlichen Diskussion ist, wenn man nichtdeterministische "Destruktoren" (aka Finalizer) Destruktoren nennt oder sogar diese Benennung einfordert. Die Konzepte sind doch stark verschieden. Und das sag ich als pro-GC eingestellter. Unwind-protect ist doch auch nett.
-
tut mir leid, aber der Name stammt nicht von mir.
-
Sondern? C# nennt Finalizer auch Destruktoren, und sonst? Kann man unter Marketing-Sprech von MS verbuchen, um die C++ler ins Boot zu holen.
Der Rest der Welt:
http://de.wikipedia.org/wiki/Destruktor#Destruktoren
http://en.wikipedia.org/wiki/Destructor_(computer_programming)
-
Di englische Wikipedia die selbst genannt hast, nennt es auch so, merkt nur an, das sie nicht deterministisch sind. Auch bei einer natürlich wissenshaftlich unfundierten google suche nach "destructor <language>" oder "destructor object oriented programming" bringt ein ähnliches resultat hervor: die existenz einer Methode die vom System aufgerufen wird, wenn ein Objekt aufgeräumt wird, wird dtor genannt. Das Konzept des dtors hat aber mehrere ausprägungen.
-
otze schrieb:
Di englische Wikipedia die selbst genannt hast, nennt es auch so, merkt nur an, das sie nicht deterministisch sind.
Zitat bitte, du scheinst eine andere Wikipedia zu haben.
Auch bei einer natürlich wissenshaftlich unfundierten google suche nach "destructor <language>" oder "destructor object oriented programming" bringt ein ähnliches resultat hervor: die existenz einer Methode die vom System aufgerufen wird, wenn ein Objekt aufgeräumt wird, wird dtor genannt.
Wissenschaftlichkeit ist egal, es ist keine wissenschaftliche Frage. Aber Nachvollziehbarkeit wäre schon schön.
Das Konzept des dtors hat aber mehrere ausprägungen.
Und eine davon hat einen besseren Namen: Finalizer.
-
Kellerautomat schrieb:
Soso, wann ist denn ein GC besser?
Einige Ansätze der nebenläufigen Programmierung lassen sich mit einem Garbage-Collector _bedeutend_ einfacher implementieren.
-
Wenn man eine Unterscheidung machen will, dann sollte man immer deterministische Finalisierung (C++) bzw. nichtdeterministische Finalisierung (GC Zeugs) sagen (schreiben).
Ich finde es auch dämlich dass die Managed-Fraktion den Begriff Destruktor gehijackt hat, aber da dieser Zug wohl bereits abgefahren ist, muss man es halt akzeptieren. D.h. in Konversationen, zumindest wenn einem etwas daran liegt nicht falsch verstanden zu werden, auch die unmisverständlichen Alternativen verwenden.
Und wenn wir schon bei Begriffen sind: komprimieren tun der Lempel und der Ziv, wenn sie zusammen Party machen. Der GC tut höchstens kompaktieren.
---------------------------
Zurück zum Thema:
Um nen GC mit C++ zu implementieren muss man auf jeden Fall plattformabhängigen Code schreiben, ohne geht es nicht. Und auch dann ist nur ein simpler nicht-kompaktierender Collector drinnen.
Ich würde aber erstmal die Frage stellen: wieso willst du überhaupt nen GC? Bzw.: Bist du dir sicher dass du nen GC willst. Ich bin mir nämlich fast sicher dass du eher nen schlauen, cachenden Resource-Manager willst. Und den kann man in einer C++ GUI Library genau so gut implementieren wie in anderen Sprachen.
Die GUI Library wird nämlich nicht viel vom GC haben, und auch nicht viel von irgendwas was nicht-deterministisch finalisiert.
Bzw. das schlaue Resource-Management ist natürlich nur ein Teil. Es kommt dann noch dazu dass die Library einen schlau aufgebauten Layout-Prozess verwendet. Und dass sie beim Rendering ein System verwendet welches ausreichend gut skaliert. Bzw. allgemein die "UI-Element" Klassen so aufgebaut sind, dass das Anlegen und Zerstören von tausenden kleinen Objekten kein Performance-Problem macht. Game-Engines bekommen das auch gebacken, wieso sollte ein GUI Toolkit das dann nicht schaffen?
-
Hi hustbaer, was meinst du genau mit einem Resourcen-Management? Ich könnte natürlich jede Resource in einem ResourceManager registrieren. Aber wie stelle ich nun fest, ob diese Resource noch benötigt wird oder gelöscht werden kann? Im Prinzip wäre das dann mein "GC". "Kompaktieren" wäre auch nicht so wichtig.
Da alle Klassen des Frameworks von einer gemeinsamen Basis-Klasse abgeleitet sind, wäre es evtl. auch denkbar in dieser einen entsprechenden Mechanismus zu implementieren.
SmartPointer siehe anderer Thread kommen wohl auch nicht in Frage, da für mein Problem kein passender existiert und ich nicht anfangen werde in einem Framework mit knapp 400 Klassen irgendetwas rumzufrickeln nur weil es nicht besser geht.
-
Mh, wenn du schon ein riesiges Framework hast, wo du Smart-Pointer nicht reinfrickeln willst/kannst, dann wirst du genauso wenig halbwegs ordentliche Gargabe-Collection da rein bekommen, denke ich.
