Re: IUnknown, Identity rule for 'nested objects'
asnowfall@gmail.com wrote:
COM identity rules are only about interface pointers returned by
QueryInterface. It is perfectly fine, and quite common, to have a
method (other than QueryInterface) on one interface return an
interface implemented by a different object with its own distinct
COM identity.
When you 'perfectly fine', are you also including the case where
Marshalling is involved?
Yes I am.
My understanding is, marshallers call QI().
Yes, they sometimes do.
Let me give an example(x.dll),
CoClass A CoClassB
{ {
Interface IA1; Inteface IB1;
Interface IA2; Interface IB2;
}; };
Assume a method of IA1 returns pointer to IB1 by calling
CoCreateInstance(). Then marshaller may call like this. pIB1-
QueryInterface(IID_IA!);
No. Why would it do that? What reason it has to believe that CoClassB is in any way related to or aware of IA?
In such case IB1 would not know about IA1.
And rightly so.
In effect what I am is, does these COM rules like, Identity/
Transitivity/Reflexivity apply to just the interfaces "within"
coclass?
Yes.
Following is my "main" concern, please comment on this.
If you insist.
In my in-proc DLL, every interface(dual) has its own CoClass, and
these interfaces are being created and returned by methods of other
coclass.
A perfectly reasonable arrangement, generally known as an object hierarchy.
I have not established 'Aggregation' among these CoClasses.
Wise decision.
One among these CoClass, one is ROOT coclass. Now I have to expose
this In-proc dll though an Out-proc sever. And, inside Out-proc
server, I have just one method, to return that root coclass of DLL,
You may have some difficulty figuring out when that out-of-proc server is safe to shut down. You don't want to terminate it while
there are still outstanding references to objects inside the DLL it hosts. I suppose you could check DllCanUnloadNow periodically.
Once, caller gets pVal, he will fetch other interfaces, implemented
inside Dll. DonBox book, under Binary-Composition has similar example
and says 'Aggregation' should be used
You are not doing composition, so that chapter doesn't apply. Composition is a technique whereby two or more objects (either
source-level classes or binary components) cooperate to pretend to be a single COM component (more formally, maintain a single COM
identity). Nothing in your problem statement suggests that you may need or want that.
to let IRootOfDll know that it is being used.
Why does it care?
Then I flashed to me that, to survive Marshalling,
'Aggregation' is needed not just in the above function(in EXE) but
also among the CoClasses that are inside Dll.
In your mind, what precisely is the mechanism by which marshalling would "kill" your arrangement, so that steps to assure "survival"
must be taken?
Have you tried a straightforward implementation? Did it not work for you? In what way did it fail?
Even if I use
'containment' and duplicate the DLL's object heirarchy inside EXE, I
may still have to bolster this containment wrapper with 'aggregation'.
Because otherwise... ?
These are the things that I would like to get clarified these concept
before I start implementing solution.
I hope I was able to alleviate your concerns.
My another major conecern is, applying aggregation to multi-layered
"parent-child" object. I do not even know whether this is possible.
It doesn't make any sense to even try.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925