Gibt es Untersuchungen zur Verwendung von RAII in GC-Sprachen?

9

Hinweis: Objektlebensdauer RAII nicht mit / mit Blockbereich RAII

Es scheint, als wäre es möglich, eine zusätzliche GC-Kategorie, kurzlebige Objekte (gc-Kategorie etwas häufiger), langlebige Objekte (gc-Kategorie seltener) und Ressourcenobjekte (gc-Kategorie sehr häufig) zu verwenden. Oder möglicherweise mit einem zusätzlichen Referenzzähler für Ressourcenobjekte.

Es scheint, dass die Verwendung / mit Stil einige Vorteile durch die Förderung eines funktionaleren Stils (verzeihen Sie mir, wenn ich falsch liege und dies ist nicht der funktionale Stil) von I / O einige O / I entmutigen der Ort gegen die Flexibilität von objektbasierten RAII (weil es einfacher ist). Aber einige Probleme erfordern wahrscheinlich schwer zu verfolgen Ressource Lebenszeiten.

Gibt es neben der Vermeidung von GC-Komplexität und -Geschwindigkeit auch Gründe dafür, dass dies in den Mainstream-Sprachen nicht der Fall ist? (Ich verstehe, dass einige Sprachen Reference Counting als Teil von gc in ihren Hauptimplementierungen verwenden weil ich glaube, dass ihre Spezifikation keine Referenzzählung für irgendeinen Typ von Objekten / oder allen Objekten spezifiziert und dass andere Implementierungen, die von Menschen verwendet werden, keine Referenzzählung haben, die Verwendung von Objektlebensdauer RAII in diesen Sprachen einschränkt.

PS: Haben sie c ++ RAII in Perl?

    
Roman A. Taycher 10.09.2010, 15:14
quelle

1 Antwort

4

Viele Sprachen machen es viel einfacher, einen benutzerdefinierten inneren Blockprozessor zu schreiben, als es traditionell in C ++ war (dies wurde möglicherweise in den aktuellen Entwürfen des neuesten Standards angesprochen). Wenn Sie diese haben, wird viel von der Anforderung der Verwendung von RAII für die genaue Ressourcenbehandlung viel weniger dringlich; Sie können so etwas tun:

%Vor%

anstelle von:

%Vor%

Es gibt wirklich keinen großen Unterschied, außer dass, wenn Sie mehrere verschachtelte using -Konstrukte haben, die Reihenfolge der Ressourcenfreigabe viel klarer ist. (Es ist auch IMO einfacher, spezielle Behandlung zu tun, wenn eine Ausnahme ausgelöst wird, nützlich für Dinge wie Transaktionen, bei denen Sie bei einem Fehler zurückrollen möchten, aber ich erwarte nicht, dass alle mir dort zustimmen.) Beachten Sie auch Es gibt viele verschiedene Möglichkeiten, using -Konstrukte zu schreiben, einige sehr viel schwerer als andere, aber wir brauchen die Unterschiede hier nicht wirklich zu erforschen.

Wenn man bedenkt, dass die genaue Ressourcenbehandlung anders gehandhabt wird, gibt es viel weniger Nachfrage nach dem C ++ RAII-Stil und es ist sinnvoll, stattdessen Garbage Collection (GC) zu verwenden, da es komplexe Fälle handhabt (dh wo auch immer) ist schwierig, Objektlebensdauer an einen bestimmten Bereich zu binden) viel einfacher. Um fair zu sein, gibt es Fälle, in denen Sie eine genaue Ressourcenverwaltung mit einer nicht-trivialen Lebensdauer benötigen, aber diese Fälle sind für alle unangenehm .

Perl verwendet Garbage Collection und hat billige Subroutinenblöcke, wie auch die meisten anderen Skriptsprachen in der einen oder anderen Form (weil die Aufteilung zwischen Code und Daten in Skriptsprachen lockerer ist als in traditionelleren kompilierten Sprachen). Die einzige große Skriptsprache, von der ich weiß, dass GC nicht GC ist, ist Tcl, und zwar deshalb, weil das Wertesystem dort aus technischen semantischen Gründen schleifenfrei garantiert ist, und daher ist eine Referenzzählung ausreichend. Codeblöcke sind dort allerdings immer noch sehr .

Wenn wir uns hauptsächliche kompilierte Sprachen ansehen (dh keine Skriptsprachen), dann sehen wir wirklich eine Kluft in etwa 1990. Sprachen von vorher (einschließlich C ++) tendieren dazu, keine Garbage Collection anzunehmen (mit einigen Ausnahmen wie Lisp, Smalltalk) und die funktionalen Programmiersprachen), während Sprachen ab diesem Punkt (insbesondere Java und C #) tun GC annehmen. Ich vermute, dass es zu diesem Punkt eine wesentliche philosophische Verschiebung gab, die wahrscheinlich mit einigen cleveren Implementierungen verbunden war, die sich mit den ungeheuerlichsten Problemen in GC vor diesem Punkt beschäftigten. Wenn Sie GC haben, denken Sie einfach nicht an RAII als Lösung; Es ist sehr verwurzelt in C ++ 's Modell der Welt.

Ich habe gerade diesen Ausdruck gemacht.

    
Donal Fellows 09.10.2010 06:54
quelle