Still thinking.
 
You know me - sometimes months or years pass before I get an answer on an ng question. :-)
 
I had an idea yesterday actually, but haven't had time to even write it down yet.
 
Matthew
 
P.S. Any response to my be.speech idea? ;-)
 
 
"Adi Shavit" <adish@gentech.co.il> wrote in message news:evbhs3$2r39$1@digitalmars.com...
Any comments on this?
Adi

Adi Shavit wrote:
Yes, of course, you're right.
I got a bit disoriented due to the similar names and the template types, thus the "confusing" bit.
I re-read your article "enhanced comstl::interface_cast" and that sorted me out.

Anyway, I have a bigger challenge. One that I don't think has a simple solution.
ref_ptr + interface_cast give a very robust and readable interface to COM programming. That's great.
However, there are still some places where I wish a cleaner syntax was possible.

Here's a quote from my original question list:

5. Functions like co_create_instance and other initialization functions
> expect an address of a pointer as the second argument. This means that
> when used with interface_ptr, a temporary bare pointer must be used to
> be given like so:
>
>        // Create a source filter specified by filename
>        interface_ptr<IBaseFilter> pSource; // The interface_ptr<> object
>        {
>           IBaseFilter* ppSource= NULL; // temporary bare pointer
>
>           if(FAILED(pGraph->AddSourceFilter(a2w(c_str_ptr(filename)),0,&ppSource)))
>           {
>              //...
>              return 0;
>           }
>           pSource.set(ppSource, false); // setting the smart pointer.
>        }
  
[your wrote:] Agree that this is not pretty.
Indeed, it is not pretty. This type of code appears in several places in my program.
Since pSource is initially empty, it does not even have a raw ptr to pass to AddSourceFilter().

I was wondering if there might be a way to make this prettier.
It would be nice to have something like this:

        // Create a source filter specified by filename
        interface_ptr<IBaseFilter> pSource; // The interface_ptr<> object
        if(FAILED(pGraph->AddSourceFilter(a2w(c_str_ptr(filename)),0, pSource.getAssignableInterface(false))))
        {
           //...
           return 0;
        }
Where, presumably, getAssignableInterface() returns an IBaseFilter** instance or something convertable to it (the false regards the ref-count).

I don't really have a concrete idea about how this might be implemented, though maybe if a temporary
IBaseFilter** convertable object is returned, then checks/updates to the actual pSource could be done in the temp's dtor. Also, this convertable class could be made temp only, or something along these lines...

Any thoughts?

Adi



Matthew Wilson wrote:
1. is a cast from a pointer to a pointre
3. is a case from a smartptr to a smartptr
2. is an error (I presume when you say blows up you mean it fails to compile?)
 
I don't know what you mean by "confusing redundancy". I don't see any redundancy at all, since it is no more/less reasonable to want to be able to cast raw pointers as smartptrs. Is that what you mean?
 
"Adi Shavit" <adish@gentech.co.il> wrote in message news:eturnn$6cq$1@digitalmars.com...
Indeed, it does!

Can you explain what the difference is between each of the versions, and why this (confusing) redundancy exists?

Here they are for reference:
//...
stlsoft::ref_ptr<IGraphBuilder> pGraph;
stlsoft::ref_ptr<IMediaControl> pMediaControl;
//...

1. pMediaControl.set(interface_cast_addref<IMediaControl*>(pGraph.get()), false); // this is OK
2.
pMediaControl.set(interface_cast_addref<IMediaControl*>(pGraph), false);       // this blows up.
3.
pMediaControl = interface_cast<IMediaControl>(pGraph);                         // this is OK
Thanks,
Adi