Chapter 4. C++

Table of Contents

Deriving from tweek::SubjectImpl
Using the CORBA Manager
Using the Subject Manager
Subject Manager Initialization
tweek::SubjectManagerImpl API

Writing C++ code that makes use of Tweek is not difficult, though it often requires some good planning. With the current code base, the C++ side of things maintains the state information through an implementation of the Tweek Subject interface. Instances of such an implementation may need to communicate with other parts of a given application, and it is important to define these relationships well. In other words, as a maintainer of application state information, the subject implementation should have easy access to that state information.

Furthermore, developers must keep in mind that there may be asynchronous execution of application code as a result of using Tweek. The local ORB runs in its own thread, and as such, it executes methods of servants from that thread. Whatever the servant does, it should be thread-safe with respect to the rest of the application.

In this chapter, we cover each aspect of writing C++ code that uses the Tweek API. We begin by explaining how to make a custom subject implementation. Then, we discuss the use of the CORBA Manager from user-level code. We conclude the chapter with an overview of using the Subject Manager.

Deriving from tweek::SubjectImpl

To create a custom subject implementation, you must derive from two classes: the abstract class that defines the custom interface and tweek::SubjectImpl. Referring back to the interface shown in Example 3.2, “CustomSubject.idl”, the basic C++ class declaration would appear as follows:

Example 4.1. CustomSubjectImpl.h

  1 #ifndef _CUSTOM_SUBJECT_IMPL_H_
    #define _CUSTOM_SUBJECT_IMPL_H_
    
    #include <tweek/CORBA/SubjectImpl.h>
  5 #include <CustomSubject.h>
    
    namespace mymod
    {
    
 10 class CustomSubjectImpl : public POA_mymod::CustomSubject,      1
                              public tweek::SubjectImpl             2
    public:
       CustomSubjectImpl() : mValue(0.0f)
       {
 15       ;
       }
    
       virtual ~CustomSubjectImpl()
       {
 20       ;
       }
    
       virtual float getValue();                                    3
    
 25    virtual void setValue(float v);                              4
    
       mymod::CustomSubject_ptr _this()                             5
       {
          return POA_mymod::CustomSubject::_this();
 30    }
    
    private:
       float mValue;
    };
 35 
    }
    
    #endif
1 2

Here we declare our parent classes, POA_mymod::CustomSubject and tweek::SubjectImpl. The first is code generated by the IDL compiler, and the second is included as part of the Tweek C++ API. Both are necessary for this custom interface to work correctly as a Tweek subject.

3 4

These two declarations correspond to the CustomSubject interface defined in Example 3.2, “CustomSubject.idl”. The implementations of these methods are not shown here, but they are required for the code to compile. That is, the declarations in POA_mymod::CustomSubject are pure virtual methods, and an instance of mymod::CustomSubjectImpl cannot be created unless these methods are implemented.

5

Overriding the method named _this() is required due to the diamond inheritance tree created by deriving from POA_mymod::CustomSubject and tweek::SubjectImpl. Both of these classes derive from tweek::Subject. The _this() method plays a critical role in the CORBA communication, and it is imperative that it return the correct type to the caller when invoked on a servant instance. Without this override, the returned type will be tweek::Subject_ptr, and attempts to narrow to mymod::CustomSubject_ptr will fail.

Note the namespaces used on this method. The return type is mymod::CustomSubject_ptr, which corresponds to the namespace in which the classes CustomSubjectImpl and CustomSubject are defined. To get the actual value to return, POA_mymod::CustomSubject (one of the two parent classes) is used.

The implementations of getValue() and setValue() are fairly obvious, though they are presented here for the sake of completeness. Note, however, that setValue() changes the state of the subject, and thus any observers must be notified of the change. The implementations are shown in the following example.

Example 4.2. CustomSubjectImpl.cpp

#include <CustomSubjectImpl.h>

namespace mymod
{

float CustomSubjectImpl::getValue()
{
   return mValue;
}

void CustomSubjectImpl::setValue(float v)
{
   mValue = v;
   tweek::SubjectImpl::notify();
}

}

The key point to note is the call to tweek::SubjectImpl::notify() in the setValue() implementation. In general, anything that modifies the state of the subject requires that this method be invoked. Note also that the method is fully qualified so that we are sure to call the correct implementation.