GC 语言中是否有关于 RAII 的研究（或更好的使用）？
注意：对象生命周期 RAII 不使用/使用块作用域 RAII
似乎可以使用额外的 gc 类别、短寿命对象（稍微频繁地检查 gc 类别）、长寿命对象（不太频繁地检查 gc 类别）和资源对象（检查gc 类别非常频繁）。或者可能对资源对象进行额外的引用计数 gc。
看起来 using/with 风格可以通过提升 I/O 的功能性风格（请原谅我，如果我错了，这不是功能性风格）来带来一些好处，从而阻止大量 I/O 分散在各处基于对象的 RAII 的灵活性（因为它更容易）。但有些问题可能需要很难跟踪资源的生命周期。
除了避免 gc 复杂性和速度之外，是否还有其他原因导致主流语言没有这样做？（我知道有些语言在其主要实现中使用引用计数作为 gc 的一部分，因此 RAII 可能在那里工作，但我相信他们的规范没有指定某些类型的对象/或所有对象的引用计数，并且人们使用的其他实现没有引用计数，限制了这些语言中对象生命周期 RAII 的使用
PS：他们是否有 c++ 类型 RAII 。珀尔？
Note: Object Lifetime RAII not using/with block scope RAII
It seems like its possible using an extra gc category, short lived objects(check gc category somewhat frequently), long lived objects(check gc category less frequently), and resource objects(check gc category very frequently). Or possibly with an extra reference counting gc for resource objects.
It seems like the using/with style can have some benefits by promoting a more functional style(forgive me if I'm wrong and this is not the functional style) of I/O discouraging lots of I/O spread out over the place vs the flexibility of object based RAII (because it's easier). But some problems probably require hard to track resource lifetimes.
Are there reasons besides avoiding gc complexity and speed, that this has not been done on mainstream languages?(I understand that some languages use reference counting as part of gc in their main implementations and as such, RAII may work there, but as I believe their spec doesn't specify reference counting for some type of objects/or all objects and that other implementations used by people don't have reference counting, limiting use of object lifetime RAII in those languages.
P.S.:Do they have c++ type RAII in perl?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
许多语言使得编写自定义内部块处理器†比传统的 C++ 更容易（这可能已在最新标准的当前草案中得到解决）。当您拥有这些时，使用 RAII 进行精确资源处理的大部分要求就变得不那么紧迫；你可以做这样的事情：
而不是：
实际上并没有太大的区别，除了当你有多个嵌套
using构造时，资源释放的顺序更清楚。 （在我看来，在抛出异常的情况下进行特殊处理也更容易，这对于您想要在错误时回滚的事务之类的事情很有用，但我不希望每个人都同意我的观点。）另请注意使用using构造的编写方式有很多种，其中一些比其他更重量级，但我们实际上不需要在这里探讨其中的差异。鉴于精确的资源处理是以这种不同的方式处理的，对 C++ RAII 风格的需求要少得多，并且使用垃圾收集 (GC) 是可行的，因为它可以处理复杂的情况（即，在难以处理的任何地方）。将对象生命周期绑定到特定范围）更容易。公平地说，在某些情况下，您需要在不平凡的生命周期内进行精确的资源管理，但这些情况对每个人来说都是令人讨厌的。
Perl 使用垃圾收集并具有廉价的子例程块，就像大多数其他脚本语言以一种或另一种形式一样（因为脚本语言中代码和数据之间的划分比更传统的编译语言更宽松）。据我所知，唯一不使用 GC 的大型脚本语言是 Tcl，这是因为出于技术语义原因，那里的值系统保证无循环，因此引用计数就足够了。不过，代码块仍然非常便宜。
如果我们看看主流编译语言（即，不是脚本语言），那么我们确实在 1990 年左右看到了分歧。那时的语言（包括 C++）往往不假设垃圾收集（除了一些例外，例如 Lisp、Smalltalk 和函数式语言）。编程语言），而此后的语言（特别是 Java 和 C#）确实采用 GC。我猜想关于这一点存在重大的哲学转变，可能与一些巧妙的实现相结合，这些实现解决了在那之前 GC 中最严重的问题。当您使用 GC 时，您根本不会将 RAII 视为解决方案；而是将 RAII 视为解决方案。它深深植根于 C++ 的世界模型。
†我刚刚提出了这个词。
Many languages make it a lot easier to write a custom inner block processor† than it was traditionally in C++ (this may have been addressed in the current drafts of the latest standard). When you have these, much of the requirement of the use of RAII for exact resource handling becomes much less pressing; you can do something like this:
instead of:
There's not a huge difference really except that when you have multiple nested
usingconstructs it's much clearer what the order of resource release is. (It's also IMO easier to do special handling in the case where an exception is thrown, useful for things like transactions where you'd want to roll back on error, but I don't expect everyone to agree with me there.) Also note that there are many different ways of writingusingconstructs, some much more heavyweight than others, but we don't really need to explore the differences here.Given that exact resource handling is dealt with in this different way, there's a lot less demand for the C++ RAII style and it is viable to use Garbage Collection (GC) instead, as that handles complex cases (i.e., anywhere where it is difficult to tie object lifetime to a specific scope) far more easily. To be fair, there are cases when you need exact resource management with a non-trivial lifetime, but those cases are nasty for everyone.
Perl uses Garbage Collection and has cheap subroutine blocks, as do most other scripting languages in one form or another (because the division between code and data is looser in scripting languages than more traditional compiled langs). The only big scripting language that I'm aware of that doesn't use GC is Tcl, and that's because the value system there is guaranteed loop-free for technical semantic reasons and so reference counting is sufficient. Code blocks are still very cheap there though.
If we look at mainstream compiled languages (i.e., not scripting languages) then we really see a divide in about 1990. Languages from before then (including C++) tend to not assume garbage collection (with some exceptions such as Lisp, Smalltalk and the functional programming languages) whereas languages from after that point (notably Java and C#) do assume GC. I guess there was a substantial philosophical shift about that point, probably coupled to some clever implementations that dealt with the most egregious problems in GC before that point. When you have GC, you simply don't think of RAII as a solution; it's very rooted in C++'s model of the world.
† I just made that term up.