Whenever you are passing opaque types to an IDL operation, you have to make sure that you understand and follow the memory management rules used by Orbix. The memory management rules describe who-you or the ORB-is responsible for allocating and freeing memory, and when it is supposed to happen.
On the client side, an in parameter is passed as a const OpaqueType*, where OpaqueType is the user-defined type specified as opaque in the IDL file. You are responsible for allocating and initializing the opaque type before it is passed, and ultimately for cleaning up the allocated memory.
On the server side, the orb library allocates memory for the incoming object, and Orbix frees the memory associated with the incoming object. You are not responsible for deleting the pointer. Orbix deletes that pointer, so be sure that you don't, as doing so would cause problems.
An out parameter is passed as an OpaqueType*&.
On the client side, the orb library allocates space for the returning OpaqueType* parameter; the client developer is responsible for deleting it.
On the server side, the space pointed to by OpaqueType* is allocated by the server developer; Orbix deletes the pointer after streaming its contents. Note that if you want to return a copy of a server object, you must understand the copy and destruction semantics of that class. A reference-counted class works very nicely to keep an object from being destroyed until it is no longer in use.
Memory management rules for return values are the same as for out parameters.
An inout parameter is passed as an OpaqueType*&.
On the client side, you are responsible for allocating the pointer before the function call.
We have been told that a future release of Orbix will delete this pointer, but for now you are responsible for deleting it. Since Orbix doesn't delete the pointer now, using it carelessly may lead to a memory leak. Until it is fixed, a work-around is to save a copy of the outgoing object pointer on the client side of an application before the object is passed as an inout parameter of a function invocation, and delete the saved pointer at a later time upon the completion of the function invocation. Another option is to change the code generated by the IDL compiler to delete inout parameters after the extraction is called on them.
When the function returns to the client side, the orb library allocates a new pointer, which the client developer is responsible for freeing.
On the server side, the orb library allocates the space for the incoming object, and Orbix deletes the pointer on the return. Thus, the server developer doesn't have to worry about the memory management of the inout object, unless he or she wants to replace it with an entirely different object. In that case, the developer would be responsible for freeing the incoming object and allocating the outgoing object.
The following orb library memory management rules are used for Orbix 2.1 and later with CORBA2-compliant mapping.
| Client-side | Operator applied | Orbix responsibility | orb library responsibility | User responsibility |
|
in |
<< - insertion (const) |
allocate/free | ||
|
out/return |
>> - extraction |
allocate (incoming) |
free (incoming) | |
|
inout |
<< - insertion >> - extraction |
May change; see Section 27.5.1. |
allocate (incoming) |
allocate (outgoing) free (incoming) |
| Server-side | Operator applied | Orbix responsibility | orb library responsibility | User responsibility |
|
in |
>> - extraction |
free (incoming) |
allocate (incoming) | |
|
out/return |
<< - insertion |
free (outgoing) |
allocate (outgoing) | |
|
inout |
>> - extraction << - insertion |
free (outgoing) |
allocate (incoming) |
©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.