[OpenWalnut-Dev] WItemSelection & friends improvement

Sebastian Eichelbaum eichelbaum at informatik.uni-leipzig.de
Wed May 23 12:00:35 CEST 2012


Note for everyone: The patch is included in the code. I have also added some example code to our über-module (template).

Thank you once again for this patch!

Bye
Sebastian

On Wed, 16 May 2012, Sebastian Eichelbaum wrote:

> Hi
> 
> I have commited your patch! I made some minor improvements and added some example code to the template module. Thank you very much for this work!
> 
> Bye
> Sebastian
> 
> On Tue, 15 May 2012, Christof Pieloth wrote:
> 
> > ;) There would be a way (if I don't forget sth.) if you could define
> > a base class of the class template type T, like in generics of Java:
> > public class WAbstractItem* <T extends WAbstractItem*> ...
> > In this case you could write a new templatized base class of WItem*
> > (WAbstractItem*) with the templatized code of the current WItem* and
> > the current WItem* would be an implementation with a fixed type
> > (WItem* <WItem*>) or just a typedef. So we do not have to write code
> > twice, but could implement new WItem* without breaking old modules.
> > Anyway, with this limitation we can not change this with less effort.
> > 
> > see ya!
> > 
> > Am 15.05.2012 16:09, schrieb Sebastian Eichelbaum:
> > >Btw. backward compatibility is not the reason. Its a technical issue which arises from the fact that every instantiated template is its own type without any polymorphic relations. You always need a base class for classes which share some basic functionality as the WItem classes do. The current WItem* classes are these base classes. Replacing them with templatized classes will not resolve the issue.
> > >
> > >Bye
> > >Sebastian
> > >
> > >On Tue, 15 May 2012, Christof Pieloth wrote:
> > >
> > >>Hello,
> > >>
> > >>I have created a ticket with the *.diff:
> > >>http://www.openwalnut.org/issues/174
> > >>I decided to extend WItemSelectionItem as a container. This solution
> > >>allows us to use any types even those without a default constructor.
> > >>Sadly we now have a dynamic cast, but due to "downward
> > >>compatibility" we have to take this.
> > >>
> > >>Bye
> > >>Christof
> > >>
> > >>
> > >>Am 14.05.2012 18:28, schrieb Christof Pieloth:
> > >>>Tomorrow I will have a try and can hopefully send you a patch in a
> > >>>few days.
> > >>>
> > >>>Am 14.05.2012 15:56, schrieb Sebastian Eichelbaum:
> > >>>>Hi
> > >>>>
> > >>>>This is a nice idea. But technically, there are several things
> > >>>>to do to achieve this:
> > >>>>
> > >>>>You will need to derive a new templatized class from
> > >>>>WItemSelectionItem AND simultanously derive from the template
> > >>>>type T. With this, you can use a queried WItemSelectorItem as
> > >>>>your own type directly:
> > >>>>
> > >>>>template<   typename T>
> > >>>>class WIteSelectionItemTyped: public WItemSelectionItem,
> > >>>>                               public T
> > >>>>
> > >>>>Luckily, these items are handled using pointers. If they would
> > >>>>be handles as copies throughout the WItemSelection, your
> > >>>>explicitly derived typing would be lost. Now, you can provide a
> > >>>>method to WItemSelectionItem:
> > >>>>
> > >>>>const T&   getValue() const;
> > >>>>and
> > >>>>T&   getValue()
> > >>>>{
> > >>>>   return *dynamic_cast<   T*>( this );
> > >>>>}
> > >>>>
> > >>>>.. Then you would be able to use the item you query with
> > >>>>WItemSelector::at
> > >>>>
> > >>>>mySelector->at( someIndex )->getValue<   MyType>().MyFunction();
> > >>>>
> > >>>>Even nicer would be to also provide WItemSelector::at and atAll
> > >>>>with some template type to directly return a pointer to the
> > >>>>WItemSelectionItemTyped instance ... awesome :-)
> > >>>>
> > >>>>If you implement something like this, we would be very happy to
> > >>>>get a patch from you. You can create such a patch via hg export:
> > >>>>
> > >>>>$ hg pull -u
> > >>>>$ edit files
> > >>>>$ hg commit -m "[ADD] our nice feature"
> > >>>>$ hg export
> > >>>>
> > >>>>
> > >>>>The exported patch can be added by us to the upstream code and
> > >>>>next time you do a hg pull, you can merge the stuff in.
> > >>>>
> > >>>>Thank you for your idea!
> > >>>>If you have any problems when doing this, just drop a mail to the list!
> > >>>>Sebastian
> > >>>>
> > >>>>
> > >>>>On Mon, 14 May 2012, Christof Pieloth wrote:
> > >>>>
> > >>>>>Hello everybody,
> > >>>>>
> > >>>>>we are using a "WItemSelection"&   friends very often in our project
> > >>>>>and missing a feature.
> > >>>>>In most of our cases we fill a "WItemSelection" with an enum and
> > >>>>>have to code our own mapper to get the corresponding enum value for
> > >>>>>the selected "WItemSelectionItem", which we get from
> > >>>>>"WItemSelector.at()". We may can extend "WItemSelectionItem" to a
> > >>>>>template to hold a value of a generic type and a method like "T
> > >>>>>WItemSelectionItem.getValue()". So you can use a switch-case
> > >>>>>straight away.
> > >>>>>What are you thinking of this idea?
> > >>>>>
> > >>>>>Best regards
> > >>>>>Christof
> > >>>>>
> > >>>>>-- 
> > >>>>>HTWK Leipzig, University of Applied Sciences
> > >>>>>Faculty of Electrical Engineering and Information Technology
> > >>>>>Laboratory for Biosignal Processing (LaBP)
> > >>>>>
> > >>>>>fon:  +49 (0) 341 3076 3133
> > >>>>>fax:  +49 (0) 341 3076 853133
> > >>>>>mail: pieloth 'at' labp.htwk-leipzig.de
> > >>>>>
> > >>>>>
> > >>>>>_______________________________________________
> > >>>>>OpenWalnut-Dev mailing list
> > >>>>>OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> > >>>>>http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> > >>>>>
> > >>>>>Archive:
> > >>>>>http://lists.informatik.uni-leipzig.de/pipermail/openwalnut-dev/
> > >>>>>
> > >>-- 
> > >>HTWK Leipzig, University of Applied Sciences
> > >>Faculty of Electrical Engineering and Information Technology
> > >>Laboratory for Biosignal Processing (LaBP)
> > >>
> > >>fon:  +49 (0) 341 3076 3133
> > >>fax:  +49 (0) 341 3076 853133
> > >>mail: pieloth 'at' labp.htwk-leipzig.de
> > >>
> > >>
> > >>_______________________________________________
> > >>OpenWalnut-Dev mailing list
> > >>OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> > >>http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> > >>
> > >>Archive: http://lists.informatik.uni-leipzig.de/pipermail/openwalnut-dev/
> > >>
> > 
> > -- 
> > HTWK Leipzig, University of Applied Sciences
> > Faculty of Electrical Engineering and Information Technology
> > Laboratory for Biosignal Processing (LaBP)
> > 
> > fon:  +49 (0) 341 3076 3133
> > fax:  +49 (0) 341 3076 853133
> > mail: pieloth 'at' labp.htwk-leipzig.de
> > 
> > 
> > _______________________________________________
> > OpenWalnut-Dev mailing list
> > OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> > http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> > 
> > Archive: http://lists.informatik.uni-leipzig.de/pipermail/openwalnut-dev/
> > 
> 
> -- 
> Dipl.-Inf. Sebastian Eichelbaum
> Universität Leipzig
> Institut für Informatik
> Abteilung Bild- und Signalverarbeitung
> PF 100920
> D-04009 Leipzig
> _______________________________________________
> OpenWalnut-Dev mailing list
> OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> 
> Archive: http://lists.informatik.uni-leipzig.de/pipermail/openwalnut-dev/
> 

-- 
Dipl.-Inf. Sebastian Eichelbaum
Universität Leipzig
Institut für Informatik
Abteilung Bild- und Signalverarbeitung
PF 100920
D-04009 Leipzig


More information about the OpenWalnut-Dev mailing list