[menu] Add optional allocator for ui menu classes #5
Conversation
| @@ -30,12 +30,17 @@ namespace modm{ | |||
| * \author Thorsten Lajewski | |||
| * \ingroup modm_ui_menu | |||
| */ | |||
| class AbstractMenu: public AbstractView | |||
| template<typename Allocator = allocator::Dynamic<IAbstractView> > | |||
There was a problem hiding this comment.
I might be misunderstanding this but why do you need a template here? Is this sort of like using Allocator as an alias for allocator::Dynamic<IAbstractView>?
There was a problem hiding this comment.
This is a templated class. So it allows us to specify the type of Allocator we want the class to use at compile time. The part Allocator = allocator::Dynamic<IAbstractView> is a default template parameter. If no template parameter is supplied the object will use allocator::Dynamic<IAbstractView> for the allocator.
| @@ -112,4 +114,6 @@ namespace modm{ | |||
| }; | |||
| } | |||
|
|
|||
| #include "choice_menu_impl.hpp" | |||
There was a problem hiding this comment.
Why is this being included at the end of the file?
There was a problem hiding this comment.
Doing this is a way of creating a template class with separate files for declaration/definition. Since you can't put template stuff in a .cpp file you put it in a _impl.hpp file and then include it at the bottom of the normal .hpp file. Then you can add a preprocessor statement at the top of the _impl.hpp file that makes it so your code won't compile if you try and include the _impl.hpp file in your own code (since you should be including the .hpp file instead).
| { | ||
| modm::GraphicDisplay* display = &getViewStack()->getDisplay(); | ||
| typename modm::GraphicDisplay* display = &this->getViewStack()->getDisplay(); |
There was a problem hiding this comment.
I'm confused what typename is used here for.
There was a problem hiding this comment.
The gist is that since getViewStack returns a template object, we need to add typename before the type so the compiler knows this is actually a modm::GraphicDisplay.
Read a complete answer here: https://stackoverflow.com/questions/610245/where-and-why-do-i-have-to-put-the-template-and-typename-keywords
MatthewMArnold
force-pushed
the
viewstack-custom-allocator
branch
2 times, most recently
from
074aacc
to
0056490
Compare
MatthewMArnold
force-pushed
the
viewstack-custom-allocator
branch
from
0056490
to
05badc4
Compare
This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
MatthewMArnold
force-pushed
the
viewstack-custom-allocator
branch
from
76e5a09
to
89640a1
Compare
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
* [menu] Add optional allocator for ui menu classes, used for destroying AbstractViews * [menu] remove coupling between modm gui and modm menu view and menu This is because the gui stuff requires colored menus but the menu code should not have to have colored menus. This wouldn't be an issue if we could dynamic cast but on certain devices you can't do this.
This allows us to in-place allocate menus (whereas previously we were forced to use
new). The main change I had to make was add anIAbstractViewthat isn't templated that is a parent of theAbstractViewclass to avoid circular template parameter dependencies. I'm not sure if there is a better way to do this.