< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index |
One of the properties of the processor chain is that it can perform filtering etc asynchronously; the chain needs to be able to resume at the same point later by using a ProcessorMessage. In addition, you can have chains within chains, so the addressing scheme needs to be recursive. Those vector<short> are basically recording something like "chain x, subchain y, subsubchain z, processor a". I could be wrong, since I wrote that stuff a long time ago when I was a n00b, but the reason this was not handled as a simple linked list, with the address simply being a Processor*, was to allow processors to be removed without leaving dangling pointers around. I bet this code could (should?) be made simpler...
Best regards,
Byron Campen
Hi,I am working on repro example,these two lines in the function addProcessor of class ProcessorChain confused me (in file ProcessorChain.cxx,line 55):void
repro::ProcessorChain::addProcessor(auto_ptr<Processor> rp)
{
DebugLog(<< "Adding new " << mName << " to chain: " << *(rp.get()));
rp->pushAddress((short)mChain.size());
rp->pushAddress(mAddress);
rp->setChainType(mType);
mChain.push_back(rp.release());
}So why rp(class Processor) put a vector size (mChai.size) and a vector (mAddress) in it's vector (mAddress),mAddress is defined in class Processor (in file Processor.hxx,line 49):
protected:
std::vector<short> mAddress;and the two functions pushAddress are (in file Processor.cxx,line 23):
void
Processor::pushAddress(const std::vector<short>& address)
{
for(std::vector<short>::const_iterator i=address.begin();i!=address.end();++i)
{
mAddress.push_back(*i);
}
}
void
Processor::pushAddress(const short address)
{
mAddress.push_back(address);
}Thanks.
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/