delphi – 如何从库的角度处理COM(un)初始化？

通过阅读本网站上的几个答案,我学到了 CoInitialize(Ex) should be called by the creator of a thread.然后,在该线程中运行的任何代码都可以使用COM.如果该代码恰好自己调用CoInitialize(Ex),那将是无害的,因为它没有任何效果.它不应该调用CoUninitialize – 这也应该由线程的创建者完成 – 但如果它检查CoInitialize(Ex)的(保存的)结果将是S_FALSE则不会.如果创建者不负责执行初始化,则该线程处于该代码的“左右”以选择适当的线程模型,从那时起该模型将不可更改.

所有这些对于编写和使用库有什么影响？

当所有代码都是您自己的代码,并且您拥有一个小团队时,可以很好地组织COM(un)初始化调用.但是,对于库,用户不需要知道他们如何做他们做的事情,例如COM参与其中.我不想在文档中有什么可以在代码中处理.此外,除非涉及VCL代码,否则不应对库的代码运行的线程进行任何假设.

我检查过的大多数开源库都在初始化部分调用CoInitialize(Ex),在完成部分调用CoUninitialize,甚至不检查初始化是否成功.有些人调用了InitProc,但有些人首先检查了IsLibrary.

他们真的应该做什么？如果我自己写一个单元,我希望任何人都可以在没有多少考虑的情况下使用该怎么办？在线程中包装触及COM的所有内容并让该线程执行自己的COM(un)初始化？

与那些开源单位一样,它真的天真有多糟糕？在VCL应用程序中使用它们时,它们的COM(un)初始化将始终在主线程上运行,该主线程已经具有该performed first by Forms.TApplication.Create.这是否使得单元中的调用无辜但无用？如果在表单之前的.dpr中列出了任何单位怎么办？那些非VCL应用程序或DLL呢？在纠正之前我不应该使用这些装置吗？我是否应该以某种方式防范他们可能会尝试做什么,通过预防性地初始化COM？

这是一个相当复杂的问题,但这一切都归结为：如何(容易)避免COM(un)初始化方面的麻烦？