13.1.14 Mapping Rules

Serverless objects are mapped in the same way as normal interfaces, except for the differences outlined in this section.

Classes representing serverless object types are not subclasses of CORBA::Object, and are not necessarily subclasses of any other C++ class. Thus, they do not necessarily support, for example, the Object::create_request operation.

For each class representing a serverless object type T, overloaded versions of the following functions are provided in the CORBA namespace:

// C++
void release(T_ptr);
Boolean is_nil(T_ptr p);

The mapped C++ classes are not guaranteed to be usefully subclassable by users, although subclasses can be provided by implementations. Implementations are allowed to make assumptions about internal representations and transport formats that may not apply to subclasses.

The member functions of classes representing serverless object types do not necessarily obey the normal memory management rules. This is because some serverless objects, such as CORBA::NVList, are essentially just containers for several levels of other serverless objects. Requiring callers to explicitly free the values returned from accessor functions for the contained serverless objects would be counter to their intended usage.

In particular, exception used as a data type and a function name. All other elements of the mapping are the same.

• The types of references to serverless objects, T_ptr, may or may not simply be a typedef of T*.

• Each mapped class supports the following static member functions:

  // C++
  static T_ptr _duplicate(T_ptr p);
  static T_ptr _nil();

• Legal implementations of _duplicate include simply returning the argument or constructing references to a new instance. Individual implementations may provide stronger guarantees about behavior.
• The corresponding C++ classes may or may not be directly instantiable or have other instantiation constraints. For portability, users must invoke the appropriate constructive operations.
• As with normal interfaces, assignment operators are not supported.
• Although they can transparently employ “copy-style” rather than “reference-style” mechanics, parameter passing signatures and rules as well as memory management rules are identical to those for normal objects, unless otherwise noted.