[Ktechlab-devel] clarification about GenericElementFactory

Zoltan Padrah zoltan.padrah at gmail.com
Tue Jul 27 13:29:37 UTC 2010


 Hello,

In the current implementation, the template shouldn't be instantiated
directly. For an example, see the basic_ec plugin:

< http://ktechlab.git.sourceforge.net/git/gitweb.cgi?p=ktechlab/ktl-zoltan_p;a=commitdiff;h=f4e1cb13333cbcd0f802183fe44a52df970c9a75
>

The DECLARE_ELEMENT_FACTORY_MEMBER macro can be used to declare a
variable of the template type, usually in a class.

REGISTER_ELEMENT_FACTORY creates an instance of the above declared
member and registers it in the simulation manager.

UNREGISTER_ELEMENT_FACTORY unregisters the instance.

All 3 macros take as parameter only the type of the new element.

The template class has the parameter <class ElementType> the new
element type, and its constructor takes as argument the ID of the
element type. It's not necessary to instantiate the template manually.

In the current form, support for a new element can be added as follows:

In the plugin body:

DECLARE_ELEMENT_FACTORY_MEMBER( NewElement );

In the plugin constructor / on load:

REGISTER_ELEMENT_FACTORY( NewElement )

at unload:

UNREGISTER_ELEMENT_FACTORY( NewElement );

where NewElement is the class of the new element type.

For any new elements, all 3 macros have to be called again.

This implementation could be used from any plugin, so it should be
moved somewhere else, I guess in the interfaces folder.


Other implementation, that would scale even better, could be used as following:

outside of any class:

DECLARE_ELEMENT_FACTORY(
  FactoryName,
  SUPPORT_ELEMENT( Element1 )
  SUPPORT_ELEMENT( Element2 )
  // and so on...
);

And the plugin can look like:

class MyPlugin : public IPlugin {
  FactoryName *m_factory;

 MyPlugin() {
  m_factory = new FactoryName();
  ISimulationManager::self()->registerElementFactory(m_factory);
 }
 void unload(){
  ISimulationManager::self()->unregisterElementFactory(m_factory);
 }
};

This way, adding 1 new component takes 2 new lines in the source: one
for including its header, and the other to call a macro.

The implementation of the macros could be done by using many if-s
internally, but that shouldn't be visible to the programmer.

Opinions about this?

  Zoltan


2010/7/27, Julian Bäume <julian at svg4all.de>:
> moin Zoltan,
> could you provide some more information for the use of
> GenericElementFactory? Are the macros you defined supposed to be used from
> other plugins as well? Then this code shouldn't be inside a plugin. At least
> to me, this looks quite generic. Then the plugins would only be used to
> define specific instances of components. This could look like:
>
> // my cool
> resistor
> implementation
> DECLARE_ELEMENT_FACTORY(KTechLab::Element::Resistor);
>
> REGIST
> ER_ELEMENT_FACTORY(ElementFactory<KTechLab::Element::Resistor>);
>
> class
> KTechLab::Element::Resistor: public IElement {
> 	//implementation
> };
>
> It
> would be cool to be able to just provide support for new components like
> this. (Okay, one still needs to create visual representation, but this is
> easy, too.)
>
> bye then
> julian
>




More information about the Ktechlab-devel mailing list