TypeLib containment refcounting

[Mike Hearn]

> Another way is the addref the type library when the ITypeInfo wherever a
> ITypeInfo interface is initially created (like in GetTypeInfoOfGuid) but I
> think this is more dangerous, since then you have to have some way for this
> refcount to go away, and ITypeInfo_Release() doesn't know who created it,
> just that it was created.  If you are careful enough to always put an addref
> on the library when you create a new ITypeInfo pointer (GetTypeInfoOfGuid,
> GetTypeInfo, IDispatch::GetTypeInfo, etc.) but this seems like a unwieldy
> task to guarantee that the code is right in all of these places.  It's much
> easier to make the ITypeInfo_AddRef() and ITypeInfo_Release() call
> ITypeLib_AddRef() and ITypeLib_Release() on the containing ITypeLib
> implementation when appropriate.

Yes, this is true. I hadn't considered that, it would be better to put
the TypeLib addref in the TypeInfo addref. This feels a bit odd though,
it would lead to the TypeLib having a reference count that was "too
high" (though I suppose it doesn't really matter) if the receiver did
their own AddRef on the TypeInfo, as the refs would propogate up. Still,
the actual value of the refcount doesn't matter.

> As far as C++ stuff vs. C stuff, in essence the pointer to the data
> structure (including the VMT) is simply a C++ style class without the C++,
> and with some special requirements...  You can just replace my p->method()
> with OBJECT_method(p) if you like to make it look like what I've seen from
> wine.  I'm still pretty new to the wine source, so it may not be like this
> everywhere, I just don't have the time to look.

True, what I meant was that there is no object constructor, unless you
count the code where the struct is allocated and appended to the end of
the linked list.

thanks -mike

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center