[Top] [Prev] [Next] [Bottom]

Mapping of Pseudo Objects to C++

17


CORBA pseudo objects may be implemented either as normal CORBA objects or as serverless objects. In the CORBA specification, the fundamental differences between these strategies are:

References to serverless objects are not necessarily valid across computational contexts; for example, address spaces. Instead, references to serverless objects that are passed as parameters may result in the construction of independent functionally-identical copies of objects used by receivers of these references. To support this, the otherwise hidden representational properties (such as data layout) of serverless objects are made known to the ORB. Specifications for achieving this are not contained in this chapter: making serverless objects known to the ORB is an implementation detail.

This chapter provides a standard mapping algorithm for all pseudo object types. This avoids the need for piecemeal mappings for each of the nine CORBA pseudo object types, and accommodates any pseudo object types that may be proposed in future revisions of CORBA. It also avoids representation dependence in the C mapping while still allowing implementations that rely on C-compatible representations.

17.1 Usage

Rather than C-PIDL, this mapping uses an augmented form of full OMG IDL to describe serverless object types. Interfaces for pseudo object types follow the exact same rules as normal OMG IDL interfaces, with the following exceptions:

As explained in Section 14.23, "Pseudo-objects," on page 14-24, the pseudo prefix means that the interface may be implemented in either a normal or serverless fashion. That is, apply either the rules described in the following sections or the normal mapping rules described in Chapter 16, "Mapping of OMG IDL to C++".

17.2 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 due to the fact that 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.

All other elements of the mapping are the same. In particular:

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

2. 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.

3. The corresponding C++ classes may or may not be directly instantiable or have other instantiation constraints. For portability, users should invoke the appropriate constructive operations. When none are listed, users cannot depend on any portable means for constructing such objects, and should consult documentation for their implementations.

4. As with normal interfaces, assignment operators are not supported.

5. 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.

17.3 Relation to the C PIDL Mapping

All serverless object interfaces and declarations that rely on them have direct analogs in the C mapping. The mapped C++ classes can, but need not be, implemented using representations compatible to those chosen for the C mapping. Differences between the pseudo object specifications for C-PIDL and C++ PIDL are as follows:

Brief descriptions and listings of each pseudo-interface and its C++ mapping are provided in the following sections. Further details, including definitions of types referenced but not defined below, may be found in the relevant sections of this document.

17.4 Environment

Environment provides a vehicle for dealing with exceptions in those cases where true exception mechanics are unavailable or undesirable (for example in the DII). They may be set and inspected using the exception attribute.

As with normal OMG IDL attributes, the exception attribute is mapped into a pair of C++ functions used to set and get the exception. The semantics of the set and get functions, however, are somewhat different than those for normal OMG IDL attributes. The set C++ function assumes ownership of the Exception pointer passed to it. The Environment will eventually call delete on this pointer, so the Exception it points to must be dynamically allocated by the caller. The get function returns a pointer to the Exception, just as an attribute for a variable-length struct would, but the pointer refers to memory owned by the Environment. Once the Environment is destroyed, the pointer is no longer valid. The caller must not call delete on the Exception pointer returned by the get function. The Environment is responsible for deallocating any Exception it holds when it is itself destroyed. If the Environment holds no exception, the get function returns a null pointer.

The clear() function causes the Environment to delete any Exception it is holding. It is not an error to call clear() on an Environment holding no exception. Passing a null pointer to the set exception function is equivalent to calling clear(). If an Environment contains exception information, the caller is responsible for calling clear() on it before passing it to an operation.

17.4.1 Environment Interface

// IDL
pseudo interface Environment
{
attribute exception exception;
void clear();
};

17.4.2 Environment C++ Class

// C++
class Environment
{
public:
void exception(Exception*);
Exception *exception() const;
void clear();
};

17.4.3 Differences from C-PIDL

The C++-PIDL specification differs from the C-PIDL specification as follows:

17.4.4 Memory Management

Environment has the following special memory management rules:

17.5 NamedValue

NamedValue is used only as an element of NVList, especially in the DII. NamedValue maintains an (optional) name, an any value, and labelling flags. Legal flag values are ARG_IN, ARG_OUT, and ARG_INOUT.

The value in a NamedValue may be manipulated via standard operations on any.

17.5.1 NamedValue Interface

// IDL
pseudo interface NamedValue
{
readonly attribute Identifier name;
readonly attribute any value;
readonly attribute Flags flags;
};

17.5.2 NamedValue C++ Class

// C++
class NamedValue
{
public:
const char *name() const;
Any *value() const;
Flags flags() const;
};

17.5.3 Differences from C-PIDL

The C++-PIDL specification differs from the C-PIDL specification as follows:

17.5.4 Memory Management

NamedValue has the following special memory management rules:

17.6 NVList

NVList is a list of NamedValues. A new NVList is constructed using the ORB::create_list operation (see Section 17.12, "ORB," on page 17-17). New NamedValues may be constructed as part of an NVList, in any of three ways:

Each of these operations returns the new item.

Elements may be accessed and deleted via zero-based indexing. The add, add_item, add_value, add_item_consume, and add_value_consume functions lengthen the NVList to hold the new element each time they are called. The item function can be used to access existing elements.

17.6.1 NVList Interface

// IDL
pseudo interface NVList
{
readonly attribute unsigned long count;
NamedValue add(in Flags flags);
NamedValue add_item(in Identifier item_name, in Flags flags);
NamedValue add_value(
in Identifier item_name,
in any val,
in Flags flags
);
NamedValue item(in unsigned long index) raises(Bounds);
Status remove(in unsigned long index) raises(Bounds);
};

17.6.2 NVList C++ Class

// C++
class NVList
{
public:
ULong count() const;
NamedValue_ptr add(Flags);
NamedValue_ptr add_item(const char*, Flags);
NamedValue_ptr add_value(
const char*,
const Any&,
Flags
);
NamedValue_ptr add_item_consume(
char*,
Flags
);
NamedValue_ptr add_value_consume(
char*,
Any *,
Flags
);
NamedValue_ptr item(ULong);
Status remove(ULong);
};

17.6.3 Differences from C-PIDL

The C++-PIDL specification differs from the C-PIDL specification as follows:

17.6.4 Memory Management

NVList has the following special memory management rules:

17.7 Request

Request provides the primary support for DII. A new request on a particular target object may be constructed using the short version of the request creation operation shown in Section 17.13, "Object," on page 17-16:

// C++
Request_ptr Object::_request(Identifier operation);

Arguments and contexts may be added after construction via the corresponding attributes in the Request interface. Results, output arguments, and exceptions are similarly obtained after invocation. The following C++ code illustrates usage:

// C++
Request_ptr req = anObj->_request("anOp");
*(req->arguments()->add(ARG_IN)->value()) <<= anArg;
// ...
req->invoke();
if (req->env()->exception() == NULL) {
*(req->result()->value()) >>= aResult;
}

While this example shows the semantics of the attribute-based accessor functions, the following example shows that it is much easier and preferable to use the equivalent argument manipulation helper functions:

// C++
Request_ptr req = anObj->_request("anOp");
req->add_in_arg() <<= anArg;
// ...
req->invoke();
if (req->env()->exception() == NULL) {
req->return_value() >>= aResult;
}

Alternatively, requests can be constructed using one of the long forms of the creation operation shown in the Object interface in Section 17.13, "Object," on page 17-16:

// C++
Status Object::_create_request(
Context_ptr ctx,
const char *operation,
NVList_ptr arg_list,
NamedValue_ptr result,
Request_ptr &request,
Flags req_flags
);
Status Object::_create_request(
Context_ptr ctx,
const char *operation,
NVList_ptr arg_list,
NamedValue_ptr result,
ExceptionList_ptr,
ContextList_ptr,
Request_ptr &request,
Flags req_flags
);

Usage is the same as for the short form except that all invocation parameters are established on construction. Note that the OUT_LIST_MEMORY and IN_COPY_VALUE flags can be set as flags in the req_flags parameter, but they are meaningless and thus ignored because argument insertion and extraction are done via the Any type.

Request also allows the application to supply all information necessary for it to be invoked without requiring the ORB to utilize the Interface Repository. In order to deliver a request and return the response, the ORB requires:

Since the Object::create_request operation allows all of these except the last two to be specified, an ORB may have to utilize the Interface Repository in order to discover them. Some applications, however, may not want the ORB performing potentially expensive Interface Repository lookups during a request invocation, so two new serverless objects have been added to allow the application to specify this information instead:

The ContextList differs from the Context in that the former supplies only the context strings whose values are to be looked up and sent with the request invocation (if applicable), while the latter is where those values are obtained.

The IDL descriptions for ExceptionList, ContextList, and Request are shown below.

17.7.1 Request Interface

// IDL
pseudo interface ExceptionList
{
readonly attribute unsigned long count;
void add(in TypeCode exc);
TypeCode item(in unsigned long index) raises(Bounds);
Status remove(in unsigned long index) raises(Bounds);
};

pseudo interface ContextList
{
readonly attribute unsigned long count;
void add(in string ctxt);
string item(in unsigned long index) raises(Bounds);
Status remove(in unsigned long index) raises(Bounds);
};

pseudo interface Request
{
readonly attribute Object target;
readonly attribute Identifier operation;
readonly attribute NVList arguments;
readonly attribute NamedValue result;
readonly attribute Environment env;
readonly attribute ExceptionList exceptions;
readonly attribute ContextList contexts;

attribute context ctx;

Status invoke();
Status send_oneway();
Status send_deferred();
Status get_response();
boolean poll_response();
};

17.7.2 Request C++ Class

// C++
class ExceptionList
{
public:
ULong count();
void add(TypeCode_ptr tc);
void add_consume(TypeCode_ptr tc);
TypeCode_ptr item(ULong index);
Status remove(ULong index);
};

class ContextList
{
public:
ULong count();
void add(const char* ctxt);
void add_consume(char* ctxt);
const char* item(ULong index);
Status remove(ULong index);
};

class Request
{
public:
Object_ptr target() const;
const char *operation() const;
NVList_ptr arguments();
NamedValue_ptr result();
Environment_ptr env();
ExceptionList_ptr exceptions();
ContextList_ptr contexts();

void ctx(Context_ptr);
Context_ptr ctx() const;

// argument manipulation helper functions
Any &add_in_arg();
Any &add_in_arg(const char* name);
Any &add_inout_arg();
Any &add_inout_arg(const char* name);
Any &add_out_arg();
Any &add_out_arg(const char* name);
void set_return_type(TypeCode_ptr tc);
Any &return_value();

Status invoke();
Status send_oneway();
Status send_deferred();
Status get_response();
Boolean poll_response();
};

17.7.3 Differences from C-PIDL

The C++-PIDL specification differs from the C-PIDL specification as follows:

17.7.4 Memory Management

Request has the following special memory management rules:

ExceptionList has the following special memory management rules:

ContextList has the following special memory management rules:

17.8 Context

A Context supplies optional context information associated with a method invocation.

17.8.1 Context Interface

// IDL
pseudo interface Context
{
readonly attribute Identifier context_name;
readonly attribute context parent;

Status create_child(in Identifier child_ctx_name, out Context child_ctx);

Status set_one_value(in Identifier propname, in any propvalue);
Status set_values(in NVList values);
Status delete_values(in Identifier propname);
Status get_values(
in Identifier start_scope,
in Flags op_flags,
in Identifier pattern,
out NVList values
);
};

17.8.2 Context C++ Class

// C++
class Context
{
public:
const char *context_name() const;
Context_ptr parent() const;

Status create_child(const char *, Context_ptr&);

Status set_one_value(const char *, const Any &);
Status set_values(NVList_ptr);
Status delete_values(const char *);
Status get_values(
const char*,
Flags,
const char*,
NVList_ptr&
);
};

17.8.3 Differences from C-PIDL

The C++-PIDL specification differs from the C-PIDL specification as follows:

17.8.4 Memory Management

Context has the following special memory management rules:

17.9 Principal

A Principal represents information about principals requesting operations. There are no defined operations.

There are no differences from the C-PIDL mapping.

17.9.1 Principal Interface

// IDL
pseudo interface Principal {};

17.9.2 Principal C++ Class

// C++
class Principal {};

17.10 TypeCode

A TypeCode represents OMG IDL type information.

No constructors for TypeCodes are defined. However, in addition to the mapped interface, for each basic and defined OMG IDL type, an implementation provides access to a TypeCode pseudo object reference (TypeCode_ptr) of the form _tc_<type> that may be used to set types in Any, as arguments for equal, and so on. In the names of these TypeCode reference constants, <type> refer to the local name of the type within its defining scope. Each C++ _tc_<type> constant must be defined at the same scoping level as its matching type.

In all C++ TypeCode pseudo object reference constants, the prefix "_tc_" should be used instead of the "TC_" prefix prescribed in Section 6.7, "TypeCodes," on page 6-33. This is to avoid name clashes for CORBA applications that simultaneously use both the C and C++ mappings.

Like all other serverless objects, the C++ mapping for TypeCode provides a _nil() operation that returns a nil object reference for a TypeCode. This operation can be used to initialize TypeCode references embedded within constructed types. However, a nil TypeCode reference may never be passed as an argument to an operation, since TypeCodes are effectively passed as values, not as object references.

17.10.1 TypeCode Interface

// IDL
pseudo interface TypeCode
{
exception Bounds {};
exception BadKind {};

// for all TypeCode kinds
boolean equal(in TypeCode tc);
TCKind kind();

// for tk_objref, tk_struct, tk_union, tk_enum, tk_alias, and tk_except
RepositoryId id() raises(BadKind);
Identifier name() raises(BadKind);

// for tk_struct, tk_union, tk_enum, and tk_except
unsigned long member_count() raises(BadKind);
Identifier member_name(in unsigned long index)
raises(BadKind, Bounds);

// for tk_struct, tk_union, and tk_except
TypeCode member_type(in unsigned long index)
raises(BadKind, Bounds);

// for tk_union
any member_label(in unsigned long index)
raises(BadKind, Bounds);
TypeCode discriminator_type() raises(BadKind);
long default_index() raises(BadKind);

// for tk_string, tk_sequence, and tk_array
unsigned long length() raises(BadKind);

// for tk_sequence, tk_array, and tk_alias
TypeCode content_type() raises(BadKind);

// deprecated interface
long param_count();
any parameter(in long index) raises(bounds);
};

17.10.2 TypeCode C++ Class

// C++
class TypeCode
{
public:
class Bounds { ... };
class BadKind { ... };

Boolean equal(TypeCode_ptr) const;
TCKind kind() const;

const char* id() const;
const char* name() const;

ULong member_count() const;
const char* member_name(ULong index) const;

TypeCode_ptr member_type(ULong index) const;

Any *member_label(ULong index) const;
TypeCode_ptr discriminator_type() const;
Long default_index() const;

ULong length() const;

TypeCode_ptr content_type() const;

Long param_count() const;
Any *parameter(Long) const;
};

17.10.3 Differences from C-PIDL

For C++, use of prefix "_tc_" instead of "TC_" for constants.

17.10.4 Memory Management

TypeCode has the following special memory management rules:

17.11 BOA

A BOA mediates between the ORB and object implementations.

17.11.1 BOA Interface

// IDL
pseudo interface BOA
{
Object create(
in ReferenceData id,
in InterfaceDef intf,
in ImplementationDef impl
);
void dispose(in Object obj);
ReferenceData get_id(in Object obj);
void change_implementation(in Object obj, in ImplementationDef impl);
Principal get_principal(in Object obj, in Environment ev);
void impl_is_ready(in ImplementationDef impl);
void deactivate_impl(in ImplementationDef impl);
void obj_is_ready(in Object obj, in ImplementationDef impl);
void deactivate_obj(in Object obj);
};

17.11.2 BOA C++ Class

// C++
class BOA
{
public:
Object_ptr create(
const ReferenceData &,
InterfaceDef_ptr,
ImplementationDef_ptr
);
void dispose(Object_ptr);
ReferenceData *get_id(Object_ptr);
void change_implementation(
Object_ptr,
ImplementationDef_ptr
);
Principal_ptr get_principal(
Object_ptr,
Environment_ptr
);
void impl_is_ready(ImplementationDef_ptr);
void deactivate_impl(ImplementationDef_ptr);
void obj_is_ready(Object_ptr, ImplementationDef_ptr);
void deactivate_obj(Object_ptr);
};

17.11.3 Differences from C-PIDL

Means to set exceptions are moved to Environment.

17.12 ORB

An ORB is the programmer interface to the Object Request Broker.

17.12.1 ORB Interface

// IDL
pseudo interface ORB
{
typedef sequence<Request> RequestSeq;
string object_to_string(in Object obj);
Object string_to_object(in string str);
Status create_list(in long count, out NVList new_list);
Status create_operation_list(in OperationDef oper, out NVList new_list);
Status create_named_value(out NamedValue nmval);
Status create_exception_list(out ExceptionList exclist);
Status create_context_list(out ContextList ctxtlist);

Status get_default_context(out Context ctx);
Status create_environment(out Environment new_env);

Status send_multiple_requests_oneway(in RequestSeq req);
Status send_multiple_requests_deferred(in RequestSeq req);
boolean poll_next_response();
Status get_next_response(out Request req);
};

17.12.2 ORB C++ Class

// C++
class ORB
{
public:
class RequestSeq {...};
char *object_to_string(Object_ptr);
Object_ptr string_to_object(const char *);
Status create_list(Long, NVList_ptr&);
Status create_operation_list(
OperationDef_ptr,
NVList_ptr&
);
Status create_named_value(NamedValue_ptr&);
Status create_exception_list(ExceptionList_ptr&);
Status create_context_list(ContextList_ptr&);

Status get_default_context(Context_ptr&);
Status create_environment(Environment_ptr&);

Status send_multiple_requests_oneway(
const RequestSeq &
);
Status send_multiple_requests_deferred(
const RequestSeq &
);
Boolean poll_next_response();
Status get_next_response(Request_ptr&);
};

17.12.3 Differences from C-PIDL

17.12.4 Mapping of ORB and OA/BOA Initialization Operations

ORB Initialization

The following PIDL specifies initialization operations for an ORB; this PIDL is part of the CORBA module (not the ORB interface) and is described in Section 7.4, "ORB Initialization," on page 7-6.

// PIDL
module CORBA {
typedef string ORBid;
typedef sequence <string> arg_list;
ORB ORB_init (inout arg_list argv, in ORBid orb_identifier);
};

The mapping of the preceding PIDL operations to C++ is as follows:

// C++
namespace CORBA {
typedef char* ORBid;
static ORB_ptr ORB_init(
int& argc,
char** argv,
const char* orb_identifier
);
};

The C++ mapping for ORB_init (and OA_init, described in the next section) deviates from the OMG IDL PIDL in its handling of the arg_list parameter. This is intended to provide a meaningful PIDL definition of the initialization interface, which has a natural C and C++ binding. To this end, the arg_list structure is replaced with argv and argc parameters.

The argv parameter is defined as an unbound array of strings (char **) and the number of strings in the array is passed in the argc (int &) parameter.

If a NULL ORBid is used then argc arguments can be used to determine which ORB should be returned. This is achieved by searching the argc parameters for one tagged ORBid, e.g. -ORBid "ORBid_example."

For C++, the order of consumption of argv parameters may be significant to an application. In order to ensure that applications are not required to handle argv parameters they do not recognize the ORB initialization function must be called before the remainder of the parameters are consumed. Therefore, after the ORB_init call the argv and argc parameters will have been modified to remove the ORB understood arguments. It is important to note that the ORB_init call can only reorder or remove references to parameters from the argv list, this restriction is made in order to avoid potential memory management problems caused by trying to free parts of the argv list or extending the argv list of parameters. This is why argv is passed as a char** and not a char**&.

OA/BOA Initialization

The following PIDL specifies the operations (in the ORB interface) that allow applications to get pseudo object references; it is described in detail in Section 7.5, "OA and BOA Initialization," on page 7-8.


// PIDL
module CORBA {
interface ORB {
typedef sequence <string> arg_list;
typedef string OAid;

// Template for OA initialization operations
// <OA> <OA>_init (inout arg_list argv,
// in OAid oa_identifier);
BOA BOA_init (inout arg_list argv,
in OAid boa_identifier);
};
};

The mapping of the OAinit (BOA_init) operation (in the ORB interface) to the C++ programming language is as follows:

// C++
namespace CORBA {
class ORB
{
public:
typedef string OAid;

// Template C++ binding for OA init op
// <OA>_ptr <OA>_init ( int * argc,
// char **argv,
// OAid oa_identifier);
BOA_ptr BOA_init(
int & argc,
char ** argv,
const char *boa_identifier
);
};
}

If a NULL OAid is used then argc arguments can be used to determine which OA should be returned. This is achieved by searching the argc parameters for one tagged OAid, e.g. -OAid "OAid_example".

For C++, the order of consumption of argv parameters may be significant to an application. In order to ensure that applications are not required to handle argv parameters they do not recognize the OA initialization function must be called before the remainder of the parameters are consumed by the application. Therefore, after the <OA>_init call the argv and argc parameters will have modified to remove the OA understood arguments. It is important to note that the OA_init call can only reorder or remove references to parameters from the argv list, this restriction is made in order to avoid potential memory management problems caused by trying to free parts of the argv list or extending the argv list of parameters. This is why argv is passed as a char** and not a char**&.

17.12.5 Mapping of Operations to Obtain Initial Object References

The following PIDL specifies the operations (in the ORB interface) that allow applications to get pseudo object references for the Interface Repository and Object Services. It is described in detail in Section 7.6, "Obtaining Initial Object References," on page 7-10.

// PIDL
module CORBA {
interface ORB {
typedef string ObjectId;
typedef sequence <ObjectId> ObjectIdList;

exception InvalidName {};

ObjectIdList list_initial_services ();

Object resolve_initial_references (in ObjectId identifier)
raises (InvalidName);
};
};
The mapping of the preceding PIDL to the C++ language is as follows:

// C++
namespace CORBA {
class ORB {
public:
typedef char* ObjectId;
class ObjectIdList {...};
class InvalidName {...};
ObjectIdList *list_initial_services();
Object_ptr resolve_initial_references(
const char *identifier
);
};
}

17.13 Object

The rules in this section apply to OMG IDL interface Object, the base of the OMG IDL interface hierarchy. Interface Object defines a normal CORBA object, not a pseudo object. However, it is included here because it references other pseudo objects.

17.13.1 Object Interface

// IDL
interface Object
{
boolean is_nil();
Object duplicate();
void release();
ImplementationDef get_implementation();
InterfaceDef get_interface();
Status create_request(
in Context ctx,
in Identifier operation,
in NVList arg_list,
in NamedValue result,
out Request request,
in Flags req_flags
);
Status create_request2(
in Context ctx,
in Identifier operation,
in NVList arg_list,
in NamedValue result,
in ExceptionList exclist,
in ContextList ctxtlist,
out Request request,
in Flags req_flags
);
};

17.13.2 Object C++ Class

In addition to other rules, all operation names in interface Object have leading underscores in the mapped C++ class. Also, the mapping for create_request is split into three forms, corresponding to the usage styles described in Section 4.2.1, "create_request," on page 4-4 and in Section 17.7, "Request," on page 17-6 of this document. The is_nil and release functions are provided in the CORBA namespace, as described in Section 16.2.3, "Object Reference Operations," on page 16-5.

// C++
class Object
{
public:
static Object_ptr _duplicate(Object_ptr obj);
static Object_ptr _nil();
ImplementationDef_ptr _get_implementation();
InterfaceDef_ptr _get_interface();
Status _create_request(
Context_ptr ctx,
const char *operation,
NVList_ptr arg_list,
NamedValue_ptr result,
Request_ptr &request,
Flags req_flags
);
Status _create_request(
Context_ptr ctx,
const char *operation,
NVList_ptr arg_list,
NamedValue_ptr result,
ExceptionList_ptr,
ContextList_ptr,
Request_ptr &request,
Flags req_flags
);
Request_ptr _request(const char* operation);
};



[Top] [Prev] [Next] [Bottom]

1 In particular, exception used as a data type and a function name.

pubs@omg.org
Copyright © 1995, Object Management Group. All rights reserved.