[唯一]指针的分配器
我对缺乏有关该问题的文档感到有点困惑,所以我可能完全偏离了轨道:
当我分配内存以便通过我已修改其值的唯一指针返回对象时,我应该使用什么分配器?
文档说我可以提供 MIDL_user_allocate()
和 MIDL_user_free()
并且存根将使用它们 - 但这在 CLSCTX_INPROC_SERVER
中没有意义>,因为调用对象需要使用(并因此解析)我的分配器。
那么,我应该如何在这里分配内存,以便在 DLL 加载到 SVCHOST 中时存根代码可以正确释放列表,并且应用程序仍然可以直接使用 DLL(如果需要)。
idl:
HRESULT GetItems([out] DWORD *count, [out, size_is(,count)] ITEM **items);
cpp:
HRESULT STDMETHODCALLTYPE impl::GetBuffer(DWORD *count, ITEM **items)
{
*count = 0;
*items = reinterpret_cast<ITEM *>(/* ??? */);
if(!*items)
return E_OUTOFMEMORY;
*count = 5;
/* fill in items */
return S_OK;
}
I'm slightly puzzled by the lack of documentation on the issue, so I may be completely off track here:
When I allocate memory in order to return an object through an unique pointer whose value I have modified, what allocater should I use?
The documentation says that I can provide MIDL_user_allocate()
and MIDL_user_free()
and the stub will use these -- however that does not make sense in CLSCTX_INPROC_SERVER
, as the calling object would need to use (and hence resolve) my allocater.
So, how should I allocate memory here, so that the stub code can properly free the list if the DLL is loaded into SVCHOST, and applications can still use the DLL directly if they so desire.
idl:
HRESULT GetItems([out] DWORD *count, [out, size_is(,count)] ITEM **items);
cpp:
HRESULT STDMETHODCALLTYPE impl::GetBuffer(DWORD *count, ITEM **items)
{
*count = 0;
*items = reinterpret_cast<ITEM *>(/* ??? */);
if(!*items)
return E_OUTOFMEMORY;
*count = 5;
/* fill in items */
return S_OK;
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
来自此处:
其中 COM 任务内存分配器 是一组
IMalloc
方法或一组提供相同功能的CoTaskMemAlloc()
/CoTaskMemRealloc()
/CoTaskMemFree()
函数。您提到的
midl_user-*()
函数用于 RPC 内存管理。如果您处理 RPC 接口而不是 COM 接口,则需要它们。From here:
where COM task memory allocator is either the set of
IMalloc
methods or the set ofCoTaskMemAlloc()
/CoTaskMemRealloc()
/CoTaskMemFree()
functions that provide the same functionality.The
midl_user-*()
functions you mention are used for RPC memory management. You need them in case you deal with RPC interfaces, not COM interfaces.