There are a lot of samples for C#, but only some code snippets for C++ on MSDN. I have put it together and I think it will work, but I am not sure if I am releasing all the COM references I have to.
相关问题
- Inheritance impossible in Windows Runtime Componen
- How do I restart a COM+ application on a remote se
- Java COM bridge
- Listview applies a check to other listview items h
- Powershell - add catch to pick up if there are no
相关文章
- Signing an F# Assembly (Strong name component)
- Show flyout using BottomAppBar
- Python instrument drivers
- Get English exception message instead of local lan
- How To Programmatically Enable/Disable 'Displa
- How to remove an element from an IGrouping
- Exception when reading text from the file using Fi
- Reading data from Excel in Haskell
Your code is correct--the reference count on the
IBufferByteAccess
interface of*buffer
is incremented by the call toQueryInterface
, and you must callRelease
once to release that reference.However, if you use
ComPtr<T>
, this becomes much simpler--withComPtr<T>
, you cannot call any of the three members ofIUnknown
(AddRef
,Release
, andQueryInterface
); it prevents you from calling them. Instead, it encapsulates calls to these member functions in a way that makes it difficult to screw things up. Here's an example of how this would look:The call to
bufferInspectable.As(&bufferBytes)
performs a safeQueryInterface
: it computes the IID from the type ofbufferBytes
, performs theQueryInterface
, and attaches the resulting pointer tobufferBytes
. WhenbufferBytes
goes out of scope, it will automatically callRelease
. The code has the same effect as yours, but without the error-prone explicit resource management.The example uses the following two utilities, which help to keep the code clean:
Observant readers will notice that because this code uses a
ComPtr
for theIInspectable*
we get frombuffer
, this code actually performs an additionalAddRef
/Release
compared to the original code. I would argue that the chance of this impacting performance is minimal, and it's best to start from code that is easy to verify as correct, then optimize for performance once the hot spots are understood.This is what I tried so far: