Where is ObjectPrx defined in cpp

myrosia

I am trying to put a LISP interface together that will make client call outs. As part of this I need to define proper "foreign types" for all Ice types that I will use. I need to figure out where they are being defined.

My current problem is Ice::ObjectPrx. From the syntax of the examples I assumed that it was a pointer to something, so I tried a to treat it like a generic pointer in LISP. That didn't work out, so I need to see the actual type definition and try to map it out to LISP.

I tried
grep ObjectPrx *.h
in the cpp/include/Ice directory, and this turned up a lot of mentions, but nothing that looks like a typedef.

Am I looking in the wrong place, or just missing something obvious?

benoit

Hi,

You'll find the typedef in include/Ice/ProxyHandle.h.

Cheers,
Benoit.

myrosia

Thanks. I found it, and also found the source of my confusion - the overloaded "->" operator that led me to assume that ObjectPrx was a pointer. But that involved a whole lot of grepping. I am likely to have this problem with other types as well. Is there some sort of API reference that I could consult for this, that lists types and operators defined of them, rather than having to grep around?

myrosia

And here's the more relevant follow-up question. Now that I have figured out what ObjectPrx is, and followed it down to the Handle template, I am trying to figure out how to best interface it with LISP. Bear in mind, my C++ knowledge is fairly basic - I can read and understand what's going on, but not necessarily know what the best solution is.

The way I see it, the point of ObjectPrx is that it is a safer container for a pointer, which does some kind of reference counting, among many other things. But with respect to LISP interface passing it classes leads to madness. The only real sane thing to do is to give LISP a pointer, and then eventually have that same pointer passed back.

Which leads me to a strange situation: I get a class which wraps a pointer, and now I need to pass out a pointer to this class. For this pointer to be valid, I am going to have to allocate new heap space, and then manage and remember to de-allocate it. Seems an awful lot of indirection.

My question is, is there a sane way for me to get the pointer being wrapped up by the class, return it, and then re-make the class from the pointer on next call from LISP to Ice? Is this going to work, or is this likely to cause some problems with the ways those pointers are managed in ICE?

mes

In the Python and Ruby extensions, we use pointers to the reference-counted objects. For example:

Ice::ObjectPrx proxy = ...
Ice::ObjectPrx* ptr = new Ice::ObjectPrx(proxy);

This increments the reference count of the proxy object and ensures that the object won't be destroyed. Eventually you'll need to reclaim the object:

Ice::ObjectPrx* ptr = ...
delete ptr;

Deleting the pointer decrements the reference count, which may cause the proxy to be destroyed.

Regards,
Mark

myrosia

OK, so is doing it this way is the recommended approach? I mean, allocating new pointer, and then deleting it eventually?

Another option I was thinking about was along the lines of

proxy = ...
Object* ref = proxy->get()
return ref


... in a function called some time later

ObjectPrx proxy(ref)
proxy->invoke(...)

Would the option you described (allocating space and then deleting pointers) be preferable?

Myrosia

mes

The strategy you proposed isn't safe because you haven't increased the reference count of the proxy object, therefore it's possible for the proxy to be destroyed and leave you with a pointer to an object that no longer exists. The only way to guarantee that the proxy object remains active is to increase its reference count using the technique I showed above.

Regards,
Mark

myrosia

Great, thanks a lot, I understand now. Back to the other question I asked, is there a browsable API documentation for C++ (like java's APIdoc) so that I could figure out re-loaded operators and class definitions without grepping, if possible? I can find the ICE API reference, with a very nice index, but not a C++ api reference other than the book.

mes

At present the manual is the only documentation on the C++ API.

Regards,
Mark