强调混合C ++ .NET应用程序中的托管或非托管?

时间:2009-02-19 17:08:32

标签: unmanaged managed

我工作的应用程序是一个WinForms应用程序,几乎完全是在2003年的Visual C ++中编写的。在我到达现场之前,.NET被选中,因为UI构建框架,但绝大多数代码都是开发的在非管理的土地上。部分内容是绝对必要的 - 我们对一些非常大的数据集进行了一些实时图像处理,使用了一些需要指向图像缓冲区的英特尔图像处理库,我们真的 < 1%的表现至关重要的情况。

应用程序本身是一个大型可执行文件,它是通过将UI代码链接到几个静态库而形成的,每个静态库对应一个功能子系统 - 数据采集,图像处理等等。自从我加入以来,我通过编写托管包装器将其中的几个子系统拆分为DLL,我们在其他应用程序中重用它们,但主应用程序仍然是由静态链接库组成的。

我的同事和我在进一步发展是否应该强调不受管理或管理方面存在很大差异。除了我提到的情况之外,没有规定非托管代码的性能要求。我们坚定地致力于.NET,因此跨平台不是问题。除非另有说明,否则我认为我们应该支持管理。

上个月,我的同事开发了一套管理子系统的类;他没有将它们作为ref类实现并向.NET接口添加一些事件,而是编写了几个Observer实现,使用gcroot来保存托管客户端的句柄,并允许自己留在非托管的土地上。这在我看来是错的,只是因为为什么要写一些你可以免费获得的东西?但我想知道我是不是太僵硬了。

有什么想法吗?

2 个答案:

答案 0 :(得分:0)

没有一个正确或错误的答案,除了说你倾向于托管和你的同事倾向于不受管理是绝对错误的。无论你选择哪一种,你都需要达成一致,以免出现管理一些代码和一些代码无法管理的问题。

你说“我们坚定地致力于.NET”。谁在这里“我们”?是你的公司还是你和你的同事?听起来你的同事并不是那么致力于.NET。如果公司承诺并且同事不是,那么有人需要向你的同事重申他是团队的一员,需要遵循公司的指示。

如果这个决定真的取决于你们两个人而你们的同事不会让步,那么你应该考虑默许。

我们还有一个大型的托管/非托管应用程序,除非我们绝对必须,否则我们绝不会考虑做任何非托管的事情。该应用程序的大部分都是管理的。这样做要好得多。但这是我的意见,而不是事实。

答案 1 :(得分:0)

托管与非托管编程的禅宗:

良好的非托管代码将通过内存管理错误与等效托管代码相比没有明显的缺点来举例说明。

良好的托管代码将通过在性能方面没有明显的劣势而非等效的非托管代码来举例说明。

两者之间的互操作没有任何好处;)