作为一名C++开发人员,Java和.NET中缺少RAII(资源获取是初始化)一直困扰着我.清理的责任从班级作者转移到其消费者(通过try finally.NET的using构造)这一事实似乎显然是劣等的.
我明白为什么在Java中不支持RAII,因为所有对象都位于堆上,而垃圾收集器本身并不支持确定性破坏,但在.NET中引入了values-types(struct)我们有(看似) RAII的完美候选人.在堆栈上创建的值类型具有明确定义的范围,并且可以使用C++析构函数语义.但是,CLR不允许值类型具有析构函数.
我的随机搜索发现了一个论点,如果一个值类型被装箱,它就属于垃圾收集器的管辖范围,因此它的破坏变得不确定.我觉得这个论点不够强大,RAII的好处足以说明带有析构函数的值类型不能被装箱(或用作类成员).
简而言之,我的问题是:为了将RAII引入.NET,是否有任何其他原因无法使用值类型?(或者您认为我关于RAII明显优势的论点有缺陷吗?)
编辑:我必须没有明确表达这个问题,因为前四个答案已经错过了重点.我知道关于Finalize其不确定性的特点,我知道的using结构,我觉得这两个选项都逊色于RAII.using是一个阶级的消费者必须记住的另一件事(有多少人忘了把它StreamReader放在一个using街区?).我的问题是关于语言设计的哲学问题,为什么它是这样的,它可以改进吗?
例如,对于通用的确定性可破坏的值类型,我可以使using和lock关键字冗余(可以通过库类实现):
public struct Disposer<T> where T : IDisposable
{
T val;
public Disposer(T t) { val = t; }
public T Value { get { return val; } }
~Disposer() // Currently illegal
{
if (val != default(T))
val.Dispose();
}
}
Run Code Online (Sandbox Code Playgroud)
我忍不住以我曾经看过的apropos报价结束,但目前无法找到它的起源.
当我的冷死手超出范围时,你可以采取我的确定性破坏.- 匿名