[Clam-devel] connecting ports

[Xavier Amatriain]

On Tue, 2007-06-05 at 14:22 +0200, Greg Kellum wrote:
> But unfortunately, I've been having some difficulties figuring out how
> to connect these processings together.  After I retrieved and
> connected the matching input and output ports on SMSAnalysisCore and
> SMSSynthesis, the program crashed with a bus error.  

Have you tried debugging or looking at the error message? These kinds of
errors usually trigger a well-documented assertion that tells you
exactly what went wrong. I don't understand what you mean by "bus
error", can you give more details?

> There seem to be a couple of classes that have publish port methods:
> OutPortPublisher and OutPortRegistry.  What is the difference between
> these classes?  And which class should actually be used to publish the
> ports?  And is there a way to find out which class a port template was
> instantiated with? 

The OutPortRegistry is an implementation class and you shouldn't have to
deal with it directly. As for the OutPortPublisher, it is used to
publish outports of internal processing objects in a composite context.
I assume that is what you need. I agree that this is poorly documented
in Doxygen so for now the best approach is to look at already existing
examples.

> By the way from what I can tell all of the ports have been published
> with free text names written in the actual classes.  This is fairly
> poor style as it makes it difficult to retrieve these names later.  It
> would be better to replace these free text names with constants or
> macros that are defined in either a single constants file or in a
> single constants file per package. 

Saying that existing code is "farily poor style" in your first
contribution to the list is not the best of styles either ;)
Nevertheless, I agree that keyword-based registration is very
error-prone and I have experienced that myself. However constants or
macros on a single file or per package are not a very maintainable
solution, especially if the repository is more or less dynamic. I'd
prefer to keep this port registration on each processing class but add
some sort of static compile-time check. The only way I can think of
doing this is with macros though.


-- 
/*********************************
 *       Xavier Amatriain        *
 *  Associate Director - MATi    *
 *  Research Director - CREATE   *
 *    UCSB, Santa Barbara CA     *
 *      1-(805)- 893 83 52       *
 ********************************/