Delphi – 为什么是TObject.InitInstance public?

前端之家收集整理的这篇文章主要介绍了Delphi – 为什么是TObject.InitInstance public?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我对Delphi有点新鲜,这个问题只是我好奇. (我也只是试图用它偶然发现我不应该.)

如果您查看TObject.InitInstance的文档,它会告诉您不要使用它,除非您重写NewInstance.该方法也是公开的.为什么不保护用户永远不应该调用它?

解决方法

自从我在这个整个德尔福的事情在1992年中期开始之前,这个问题可能有几个答案.如果您在Delphi 1中查看TObject的原始声明,TObject上没有任何受保护/私有成员.那是因为Delphi的开发很早,与引入语言异常一致,异常从其他对象分配给不同的堆.这是NewInstance / InitInstance / CleanupInstance / FreeInstance功能的起源.在类类型上覆盖这些函数,您可以从字面上控制对象分配的位置.

近年来,我已经使用这个功能来创建一个字面上被“回收”的对象实例的缓存.通过拦截NewInstance和FreeInstance,我创建了一个系统,其中实例在解除分配时不会返回到堆中,而是放置在无锁/低锁的链表上.这使得分配/释放特定类型的实例更快,并消除了对内存管理器的大量偏差.

通过使InitInstance public(与之相反的是CleanupInstance),这将允许从其他实用程序函数调用这些方法.在上述情况下,我提到,InitInstance可以调用现有的内存块,而不必仅从NewInstance调用.假设NewInstance调用管理上述缓存的通用功能.类实例的“范围”丢失,所以调用InitInstance的唯一方法是公开.

在这些日子之中,我们可能会发布执行上述内容代码,现在它是内部“研究”项目的一部分.

哦,作为一个旁边,还有一点历史课…在Delphi 1发行之前,如何将Exception实例分配/释放的设计返回到使用与所有其他对象相同的堆.由于总体集体的错误,我们假设我们需要分配所有Exception对象实例来“保护”内存不足的情况.我们推断,如果我们尝试引发异常,因为内存管理器是“内存不足”,那么我们如何分配异常实例呢?我们已经知道那时没有记忆!所以我们决定一个单独的堆对于所有的异常是必要的,直到Chuck Jazdzewski或者Anders Heijlsberg(我忘记了哪一个),想出了一个简单而又聪明的解决方案…只需预先分配内存异常在启动时!我们仍然需要控制是否应该实际释放异常(异常实例在被处理后被自动释放),所以整个NewInstance / FreeInstance机制仍然存在.

猜你在找的Delphi相关文章