[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