[omniORB] T_var in an STL Container

[Ken Feuerman]

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.

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.

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.

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.

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"?

Thanks!

--Ken Feuerman.
Adobe Systems, Inc.