3

I have a class:

class Impl1 : public POA_I1
{
   private :
          Impl2_var ob;
   public :
          Impl2_ptr get();
          {
             return ob;
          }

          void set(::Impl2_ptr ob)
          {
             this->ob = ob;
          }
};

I'm a litte bit confused about _ptr and _var. I read that

MyObject_var The _var version of the object reference type acts as a handle toproxy in much the same way as a _ptr reference but also adds memory management. Like all _var types, a _var reference takes care of deallocating its underlying instance (in this case, the proxy instance) when the reference goes out of scope. Both _ptr references and _var references allow the client to access operations onproxy instance

but I dont understand when to use each one and why. I mean, in my implementation = which one should I use, _var or _ptr and why? And is it legal to have a field of type _var in class and return _ptr in setter? I just don't get it at all.

ssube
  • 47,010
  • 7
  • 103
  • 140
mazix
  • 2,540
  • 8
  • 39
  • 56
  • 1
    The _var behaves as an auto_ptr. Normally we use _var as member, pass _ptr around. You have to use _duplicate() at the correct places, which takes time to learn. Another option is the IDL to C++11 language mapping, that is much easier to use, see http://www.orbzone.org for more details on that. – Johnny Willemsen Aug 13 '12 at 20:15
  • I would recommend you to check some existing CORBA examples shipped with omniORB or for example TAO. See how people have created their tests and learn from it. For _ptr/_var usage also run with for example valgrind to make sure you don't have any memory leaks. – Johnny Willemsen Aug 14 '12 at 06:30
  • @Johnny Willemsen: Yes, I've seen orbzone.org and it's seems pretty awesome and imo it's much easier to use than the old mapping. I have just one more question. Is it legal to assign `_ptr` to other `_ptr`? I've read that it's illegal to assign `_var` to `_var` (I just need to do it with `_duplicate()`) but I didn't found anything about assigning `_ptr` to `_ptr` – mazix Aug 14 '12 at 12:08
  • Yes, I believe it's legal. But I also thought it was legal to assign `_var` to `_var` – jiveturkey Aug 14 '12 at 16:57
  • It is legal to assign a _var to _var, but the tricky part is that the reference count doesn't get incremented at that moment. It is more common CORBA programming to use a _duplicate() at that moment. It is also allowed to assign a _ptr to _ptr. – Johnny Willemsen Aug 14 '12 at 19:19
  • It is allowed to assign a _ptr to a _ptr, but you'll leak resources doing it. – Brian Neal Aug 15 '12 at 02:05

2 Answers2

3

As Johnny pointed out, it's all about memory ownership. If you assign an _ptr variable to an _var variable, when the _var variable goes out of scope the memory will be deleted and you better not use that _ptr variable.

In the case you provided, when you call set you are giving an object of type Impl1 ownership of the pointer. You can still use the one you have, you can call Impl1::get but since you gave the object ownership of that _ptr by calling set, if the object gets deleted so does the memory referenced by that pointer.

jiveturkey
  • 2,484
  • 1
  • 23
  • 41
  • ok, thanks for your answer. So, you advise to use `_duplicate()` in setter methods, which takes as an argument a `_ptr`? – mazix Aug 14 '12 at 12:28
  • 1
    It's a bit more complicated than that. `_var` types for object references implement reference counting. So when a `_var` type goes out of scope, the reference count is decremented. Only when the reference count goes to zero will `_release` be called. – Brian Neal Aug 14 '12 at 23:44
1

The current IDL to C++ mapping is pretty difficult and confusing. As always, consult the Henning & Vinowski book.

In general, do this for object references:

  1. Always pass object references as _ptr types in function arguments.
  2. But always store them (e.g. member variables, local variables) in _var types.
Brian Neal
  • 31,821
  • 7
  • 55
  • 59
  • I think your general rule #1 applies only if the variable is not already in a `_var`, right? Because if you create a `_ptr` out of a `_var` and pass the `_ptr` to something that puts in into a local `_var`, as soon as something's variables go out of scope, the original `_var` is hosed, no? – jhfrontz Aug 12 '15 at 22:56
  • @jhfrontz: You usually combine this with a `duplicate` call so this scenario won't happen. This is basically why the older C++ mapping is terrible. – Brian Neal Aug 13 '15 at 17:55
  • How does the destructor of something's `_var` know that it should not destroy the underlying object? Does the `_var` constructor somehow know that `_ptr` is referencing an object that is also referenced elsewhere by a `_var` and thus something's `_var` is in essence incrementing the reference count? – jhfrontz Aug 13 '15 at 18:52
  • Oh, now I think I see it: `_var` is basically a `_ptr` with implied/automatic reference decrementing on destruction. – jhfrontz Aug 13 '15 at 19:09