ExampleXorContainer

This is a rather more complex way to perform an `xor' function, using constituent gates, but it forms a nice illustration of a typical container. The class declaration looks like this:

#include "ProcessContainer.h"

class GateNot;
class GateOrN;
class GateAndN;

class ExampleXorContainer : public ProcessContainer
{
public:
   ExampleXorContainer( );
   virtual ~ExampleXorContainer( );
protected:
   virtual bool inputValid( const string& name, DataPort* in, const int idNum );
private:
// Internals (owned)
   GateNot*  m_notA;
   GateNot*  m_notB;
   GateAndN* m_andA;
   GateAndN* m_andB;
   GateOrN*  m_or;
};

There are very few methods - the constructor, destructor and the inputValid method, but these are themselves a little more complex than usual. In order to see what is going on, the implementation of the `xor' in terms of simpler gates is shown in figure 5.6. Instead of input and output ports, the class now contains five ProcessElements which represent the five gates. These of course have to be constructed and destroyed in the container constructor and destructor. The constructor also has several more jobs to do.

Firstly, the constructor must register its internal components - this is done by called registerInternal on each object:

 registerInternal( "NotA", m_notA );

A suitable name is given, and this is used by the getInternal method if a user needs to probe into a container. Then the internal connections must be made. This is very similar to the way connections are made in the steering program. Finally, the outputs have to be advertised using registerOutput. There is a subtlety here though compared to a ProcessElement. Because the container doesn't own any output ports itself, it has to get the output ports from its most downstream internal elements - in this case the final `or' gate.

For similar reasons, the inputValid method is a little different for containers. Instead of checking and setting its own input port references, it forwards connection requests onwards to the upstream elements of itself, using the connectInput method on the internals. In fact, as is the case here, it may have to forward the request to more than one internal - each input gets connected to an `and' gate and a `not' gate. However, having written the inputValid method, there is no more to be done - containers do not have a process method to override.