[omniORB] T_var in an STL Container

Stefan Seefeld seefelds@MAGELLAN.UMontreal.CA
Thu, 09 Mar 2000 13:31:31 -0500


Ken Feuerman wrote:
> 
> More of a general CORBA question than omniORB specific:  Does anyone know
> of any problems associated with storing T_var types in an STL container?
> Here's roughly what I want to do:  Suppose T is some interface defined in
> an IDL file.  I want to keep a table of T objects, keyed by strings:
> 
> {
>     typedef std::map<std::string, T_var> Table;
>     std::string strVal = /* -- some string -- */;
>     Table table;
> 
>     {
>         T_var tObject = /* -- some method returning a T_ptr -- */;
> 
>         table[strVal] = tObject; /* (1) */
>     }  /* (2) */
> 
>     /* intervening code, strVal does not change value */
> 
>     T_var newTObject = /* -- some method returning a T_ptr -- */;
>     table[strVal] = newTObject; /* (3) */
> } /* (4) */
> 
> My assumptions (hopes) are:
> 
> o At (1), a reference count get incremented by the assignment operator, so
> that at (2), when tObject goes out of scope, the reference count is
> decremented, but the T proxy object stays around because now table[strVal]
> hangs onto it.

right

> o At (3), a new T proxy object is assigned into table[strVal], so the
> original T proxy object decrements its reference count to zero, and is
> released.

right

> o At (4), newTObject goes out of scope, so the new T proxy object's count
> decrements to 1.  Also at (4), table goes out of scope, so table[strVal]
> releases on the new T proxy object, and it gets reclaimed.

youp

> o If table ever has to grow, causing a reallocation, the copy constructors
> on T_var take care of managing reference counts and memory for me.

yes

> Are my assumptions correct?  I wanted to be careful about this because I
> seem to remember there are some pitfalls with storing auto_ptr's in STL
> containers.  The issue there, if I recall, is that the copy constructor on
> auto_ptr's don't follow true "copy semantics"; that is, they transfer
> ownership of the pointed to memory.  In this context, I guess the real
> question is:  Do the _var mappings follow "copy semantics"?

yes, _var to _var works fine. All you need to care about is to call
_duplicate() when initializing the first _var from a _ptr.

Regards,	Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...