[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