Re: another COM-Question: how to inject a type-lib into a dll?



Axel Bock <axel.bock.news@xxxxxxxxxxxxxx> wrote:
> actually the passing of an Interface Pointer to a COM method might
> exactly be what he is looking for.
> But let me ask just another question on this: If this pointer is
> returned from a COM method, it is internally represented by an object,
> right?

Well, there is some piece of code behind an interface - the code that
gets run when you call an interface's method. If we are going to give
this piece of code a name, we can just as well call it "object".

> So if this object was newly created on the COM side

What's the "COM side"? What do you call the other side? What exactly are
they sides of?

> it would
> be possible to interact with it via the COM methods.

Right. This is why the object exposes the COM interface in the first
place.

> BUT internally ... would the interface pointer, which is passed to the
> COM method, internally resolve to an object pointer?

What's an object pointer? As far as COM is concerned, an "object" is a
set of COM interfaces. It is fully and completely defined by the
interfaces it implements. A COM object is an abstact concept. Only
interfaces have physical existence, represented by interface pointers.

> ----- APP side -----
> InterfaceOfSomeObject *pISomeObject;
> hr = SomeCOMMethod(x,y,z, &pIPointerOfSomeObject);
> hr = SomeOtherCOMMethod(a,b,c, pIPointerOfSomeObject);
>
> ---- COM side ----
> STDMETHODIMP SomeCOMMethod(..., **ppv)
> {
> // quick'n very dirty.
> *ppv = (InterfaceOfSomeObject*) (new SomeObject);

Make sure SomeObject has a reference count of 1 at this point.

> return S_OK;
> }
>
> STDMETHODIMP SomeOtherCOMMethod(..., **ppv)

The declaraion of SomeOtherCOMMethod has a different signature. You are
losing me here.

> {
> SomeObject *pObj = *ppv; // THAT is the critical part

This is a really bad idea for a number of reasons. You might get away
with it under tightly controlled circumstances, but it is inherently
fragile.

SomeOtherCOMMethod is declared to take InterfaceOfSomeObject* interface
pointer. What makes you think this interface is implemented by
SomeObject? Anybody can create an object that implements
InterfaceOfSomeObject, then call your method passing this interface
pointer. Your method will then crash spectacularly.

One special case of this situation is marshalling. COM marshalling
support involves a proxy object that implements all the same interfaces
as the real object, by simply forwarding all calls to it. But of course
the proxy does not know anything about non-COM methods SomeObject might
expose. Casting a proxy-implemented interface poitner to SomeObject*
would have undesirable results, to put it mildly.

The fundamental problem with your SomeOtherCOMMethod is that it is lying
to the client about the contract it imposes. It claims to accept an
interface pointer, and promises to do its work entirely in terms of this
interface. But in reality it places restrictions on this pointer above
and beyond those implied by the interface - it requires that the pointer
be SomeObject*. Why does it not just say so and declare SomeObject* as a
parameter?
--
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


.



Relevant Pages

  • Re: C# DLL mittels COM-Interop aus C aufrufen
    ... Have u tried the IDispatch interface, which is used for those language ... which doesnot have capability of maintaining VTables. ... The __cplusplus symbol is defined automatically when you're compiling C ... appropriate function pointer type. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Pointers in derived types, help needed
    ... subroutine/function must have an explicit interface. ... C is not a pointer. ... then probably the best thing to do is use allocatables. ...
    (comp.lang.fortran)
  • Re: Why ABCs make bad Interfaces
    ... > equivalent to an Abstract Base Class (ABC). ... > because it is common practice to implement an interface using ABC's. ... To convert an object to its interface, you return a fat pointer ... The NaiveInt constructor has to set up the vtables, ...
    (comp.object)
  • Re: Stupid tcl/tcom newbie question
    ... Pointer to variant in tcom ... Excel's COM interface does not appear to have any methods ... So I can't test my code on Excel. ... Sub Load DLLComp() ...
    (comp.lang.tcl)
  • Re: reusing an object
    ... I would create a function SetDefaultin SomeObject that sets all the ... since new SomeObjectcreates a new object in memory ... and returns a pointer to it, and so1 is not a pointer to a SomeObject. ... delete pso1; // If this is omitted, you would have garbage = memory not ...
    (comp.lang.cpp)