有没有一种语言具有 RAII +没有不安全指针算术的引用计数?

发布于 2024-08-18 07:17:56 字数 173 浏览 11 评论 0原文

RAII = 资源获取就是初始化

引用计数 = “穷人的 GC”

它们在一起非常强大(就像一个持有 VBO 的引用计数 3D 对象,当它的析构函数被调用时,它会释放它)。

现在的问题是——除了 C++ 之外,RAII 是否存在于任何语言中?特别是一种不允许指针算术/缓冲区溢出的语言?

RAII = Resource Acquisition is Initialization

Ref Counting = "poor man's GC"

Together, they are quite powerful (like a ref-counted 3D object holding a VBO, which it throws frees when it's destructor is called).

Now, question is -- does RAII exist in any langauge besides C++? In particular, a language that does not allow pointer arithmetric / buffer overflows?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

凡间太子 2024-08-25 07:17:56

D 有 RAII,但仍然有指针算术:( 但是,你实际上不必使用它。请注意,让 D 工作对我来说是一件痛苦的事,所以我只是说。

D has RAII but still has pointer arithmetic :( BUT, you don't really have to use it. Please note getting D to work was a pain in the butt for me so IM JUST SAYING.

森林迷了鹿 2024-08-25 07:17:56

虽然不完全是 RAII,Python 有 with 语句,而 C# 有 使用声明。

While not exactly RAII, Python has the with statement and C# has the using statement.

挥剑断情 2024-08-25 07:17:56

Perl 5 具有引用计数和析构函数,当所有引用超出范围时,保证调用它们,因此 RAII 在该语言中可用,尽管大多数 Perl 程序员不使用该术语。

Perl 5 不公开 Perl 代码的原始指针。

然而,Perl 6 有一个真正的垃圾收集器,并且实际上允许关闭垃圾收集器;所以你不能依赖以任何特定顺序收集的东西。

我相信 Python 和 Lua 使用引用计数。

Perl 5 has ref counting and destructors that are guaranteed to be called when all references fall out of scope, so RAII is available in the language, although most Perl programmers don't use the term.

And Perl 5 does not expose raw pointers to Perl code.

Perl 6, however, has a real garbage collector, and in fact allows the garbage collector to be switched out; so you can't rely on things being collected in any particular order.

I believe Python and Lua use reference counting.

幸福不弃 2024-08-25 07:17:56

perl、python (C)、php 和 tcl 是引用计数的,并且具有在引用计数为零时销毁对象的机制,一旦变量超出范围,就会发生这种情况。内置类型会自动释放。用户定义的类有一种方法来定义析构函数,该析构函数将在发布时被调用。

有一些边缘情况:全局变量可能直到最后才被释放,循环引用可能直到最后才被释放(尽管 php 最近实现了一个 gc 来处理这种情况,并且 python 2 添加了一个循环检测器)。

perl, python (C), php, and tcl are reference counted and have mechanisms to destroy an object once its reference count goes to zero, which can happen as soon as a variable goes out of scope. built-in types are released automatically. user-defined classes have a way to define a destructor that will get called upon release.

there are some edge cases: global variables might not be released until the end and circular references may not be released until the end (though php has recently implemented a gc that handles this case and python 2 added a cycle detector).

泡沫很甜 2024-08-25 07:17:56

Python(标准 CPython,不是 Jython、Unladen Swallow 和 IronPython 等变体)对其对象使用引用计数。

除此之外,它还具有 RAII 和(大部分)确定性垃圾收集功能。例如,这应该可以确定性地关闭文件:

def a():
   fp = open('/my/file', 'r')
   return fp.read()

注意 fp.close() 永远不会被调用。一旦fp超出范围,该对象就应该被销毁。但是,在某些情况下,无法保证确定性终结,例如:

  • 某些情况抛出异常并且当前正在处理回溯,或者保留对其的引用(注意 sys.last_traceback 保留最后的回溯)
  • 对象中存在循环引用,导致引用计数不为零

因此,虽然 python 理论上具有确定性终结,但最好显式关闭可能导致异常(如 IOError 等)的任何资源保持存活的对象。

Python (the standard CPython, not variants like Jython, Unladen Swallow and IronPython) uses reference counting for its objects.

With that, it also has RAII and (mostly) deterministic garbage collection. For example, this is supposed to work deterministically closing files:

def a():
   fp = open('/my/file', 'r')
   return fp.read()

Note fp.close() is never called. As soon as fp goes out of scope, the object should be destroyed. However, there are some cases where deterministic finalization is not guaranteed, such as in:

  • Something throws an exception and the traceback is currently being handled, or a reference is kept to it (note sys.last_traceback keeps the last traceback)
  • Cyclic references exist in an object, causing the reference count to not go to zero

Therefore, while python theoretically has deterministic finalization, it is better to explicitly close any resources where it's possible an exception (like IOError or the like) could cause the object to remain live.

七度光 2024-08-25 07:17:56

Vala 的对象内存管理是基于引用计数的,并且它具有 RAII(某种意义上)它的析构函数被确定性地调用)。典型的用例是创建 GUI,其中重新计数的开销通常可以忽略不计。您可以使用指针并绕过引用计数,例如为了互操作性,或者如果您需要额外的性能,但在大多数情况下您可以不用指针。它还做了一些聪明的事情,您可以将引用标记为 ownedunowned 并转移所有权,并且在许多情况下,它能够消除引用计数(如果对象不例如,转义函数)。 Vala 与 GObject/GTK 紧密相连,因此只有当您想在该生态系统中工作时才有意义。

另一个有趣的候选者是 Rust。虽然它也有指针和垃圾收集,但两者都是可选的。您可以完全使用相当于 C++ 的智能指针来编写程序,保证不会泄漏,并且它支持 RAII。它也有一个引用所有权的概念,就像 Vala 一样,但更复杂一些。从本质上讲,Rust 让您可以完全控制内存管理方式。您可以在裸机级别工作,甚至可以在其中编写内核,或者您可以使用 GC 或介于两者之间的任何东西在高级别工作,并且大多数时候它可以保护您免于泄漏内存或其他指针 -相关错误。缺点是它非常复杂,并且由于它仍在开发中,事情可能会发生变化。

Vala's memory management of objects is based on reference counting, and it has RAII (in the sense that it's destructors are called deterministically). The typical use case is to create GUIs, where the overhead from refcounting is often negligible. You can use pointers and bypass the refcounting, for example for interoperability, or if you need the extra performance, but in most cases you can live without pointers. It also does something clever, you can mark references as owned or unowned and transfer ownership, and in many cases it is able to elide the reference counting (if an object does not escape a function, for example). Vala is closely connected to GObject/GTK, so it only makes sense to use if you want to work in that ecosystem.

Another interesting candidate would be Rust. While it also has pointers and garbage collection, both are optional. You can write programs completely with an equivalent of C++'s smart pointers, with guaranteed no leaks, and it supports RAII. It also has a concept of reference ownership, like Vala, but a bit more complex. Essentially, Rust gives you complete control over how you manage memory. You can work at the bare metal level, and could even write a kernel in it, or you can work at a high level with a GC, or anything in between, and most of the time it protects you from leaking memory or other pointer-related bugs. The downside is that it is pretty complex, and since it is still in development things might change.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文