Table of Contents
This chapter gives an overview of classes that are generated by the IDL preprocessor.
![]() | Note |
---|---|
To make the IDL preprocessor process a specific IDL file, you first have to add a relevant entry into the idl.list file (see Section D.2, “The idl.list File”). |
The following classes are generated into your source tree on the basis of the IDL. Let's suppose we have a managed class named simply X and that the C++ sources of the class are in x.h and x.cpp, respectively.
Class [a] | File [b] | Notes |
---|---|---|
class MetaObjectImpl<X> | x_generated.h | Metaobjects store all the meta-data about the class, such as the base class, etc. |
class ObjectFactoryImpl<X> | x_generated.h | ObjectFactories enable mainly to instantiate objects and their replicas. |
RPCStubs<X> | x_rpc.h | See below. |
Other RPC helper classes [c]. | x_rpc.h | See the Massiv Core Reference Guide. |
[a] Class name without the Massiv::Core part. [b] The name of the file that will be generated for the relevant class. It will be located in the same directory as the IDL file. [c] For example implementation of the RPC packet for each method that is described in the IDL. |
The RPC related generated classes are described right below; for information about metaobjects or object factories see the following chapter.
Because the application shouldn't use most of the generated objects explicitly (except for metaobjects), this book dosn't describe them in detail. For more information about either of them please refer to the Massiv Core Reference Guide.
This section gives a overview about what basic classes are generated by the IDL parser according to the relevant IDL description. It doesn't intend to provide a complete list of methods of the classes nor a full list of the classes, because the Core user generally doesn't need to work with most of them directly.
Each managed object has its own RPCStubs object assigned. This class declaration is generated on the IDL basis into X_rpc.h and the relevant implementation into X_generated.cpp, where X stands for the name of the idl file without the extension.
The RPCStubs object for any managed class can be obtained by dereferencing the relevant remote or weak pointer. It provides interface for calling the methods of the associated class via RPC.
The exhaustive information about handling the RPC mechanism can be found in Chapter 8, Remote Procedure Call. The following paragraphs only briefly summarize this inforamation.
The RPCStubs objects contain two categories of methods:
Helper methods
These methods returns the self reference and thus can be chained for the programmer's convenience.
param( flags, time ) enables to set the RPC parameters. flags can specify besides others an immediate or delayed RPC call mode. For setting the delay serves the second parameter.
request_replica( timeout ) requests replication of the target object (in case the pointer the programmer has used for obtaining the stub is remote) for timeout seconds at the local node.
optimize_replica( timeout ) requests replication of the target object the same way as the previous method. Moreover it allows the optimized replica SRPC. See Section 8.5.2, “Synchronous RPC Optimizations” for more information.
Methods for performing RPC calls
Two RPCStubs methods is generated for each method that can be called using the RPC (i.e. that has its description in the IDL). Let's denote X the name of this original method.
async_X( .. ) performs the asynchronous RPC. The signature of this method is the same as the original one except for that the out parameters are removed. See Section 8.3, “Asynchronous RPC” for more information.
sync_X( .. ) performs the synchronous RPC. The signature of this method is the same as the original one (the one we are calling via the RPC). See Section 8.4, “Synchronous RPC” for more information.
Note that if a class X is inherited from a class Y, the RPCStubs< X > is generated so that it inherits from RPCStubs< Y >. Therefore the programmer can use a stub object of a class even for RPC calls of methods contained in all of its antecedents.