跨进程边界的 CRT 类型
我正在从 activeX 控件中拖放。在拖动时，我提供了一个 CComQIPtr，它实现了 COM 方法以将信息传递到放置目标。放置时，放置目标的进程会调用我的 COM 方法来获取信息。
我是否不允许在接口边界附近使用 CRT 类型或指向 CRT 类型的指针？我希望我的 IDataObject 有一个私有 std::list 和一些 std::strings，并且在接口的外部能够调用可以访问这些私有成员的 COM 方法。
我认为这没关系，因为我实际上并没有跨越边界传递 CRT 类型。
I'm doing drag/drop out of an activeX control. On drag, I provide a CComQIPtr which has COM methods implemented to pass information to the drop target. On drop, the drop target's process calls my COM methods to get information.
Am I not allowed to use CRT types or pointers to CRT types near that interface boundary? I would love for my IDataObject to have a private std::list and some std::strings, and on the foreign side of the interface be able to call my COM methods which can access those private members.
I think it's OK because I'm not actually passing CRT types across the boundary.
MSDN: Potential Errors Passing CRT Objects Across DLL Boundaries
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以在 com 对象的实现中使用您喜欢的任何内容，因为它始终保留在创建它的进程（或 dll）中。
您需要在 COM 接口中坚持使用 COM 类型，以便可以在使用对象的进程和创建对象的进程之间对这些类型进行编组。
你是对的。该文章不适用于这种情况，因为您没有跨越边界传递任何内容。 COM 基础结构负责为您跨边界编组 COM 类型。
只要确保捕获 COM 方法中的所有异常，就不能允许它们从函数中泄漏，因为 COM 基础结构不知道如何处理它们。
就我个人而言，我倾向于使用一层薄薄的 COM 代码来处理 COM 类型和“普通”类型之间的转换，然后调用执行实际工作的代码（请参阅 此处）。该层包括一个异常处理程序，可以捕获所有内容并转换为适当的 HRESULT。
You can use anything you like in the implementation of your com object as that always stays in the process (or dll) that creates it.
You need to stick to COM types in your COM interface so that the types can be marshalled between the process where your object is used and the process where your object was created.
You are correct. That article doesn't apply to this situation as you aren't passing anything across the boundary. The COM infrastructure deals with marshalling the COM types across the boundary for you.
Just be sure that you catch all exceptions within your COM methods, you can't allow them to leak out of the function as the COM infrastructure wont know what to do with them.
Personally I tend to have a thin layer of COM code that deals with conversion between COM types and 'normal' types and then calls into the code that does the real work (see here). This layer includes an exception handler that catches everything and converts to appropriate HRESULTs.