1,079
edits
Difference between revisions of "TODO"
Jump to navigation
Jump to search
→Common code, infrastructure
m (Change the TODO list to use the TODO List InfoBox not Open Tasks.) |
|||
| Line 92: | Line 92: | ||
==== Iterator handling ==== | ==== Iterator handling ==== | ||
* Implement proper reverse_iterators for Common::List. Our current implementation is the same as forward iterators, just that rbegin will return the last element instead of the first and there is no rend. Check [http://www.sgi.com/tech/stl/ReverseIterator.html SGI Documentation] for proper description of revese_iterator in the STL. | * Implement proper reverse_iterators for Common::List. Our current implementation is the same as forward iterators, just that rbegin will return the last element instead of the first and there is no rend. Check [http://www.sgi.com/tech/stl/ReverseIterator.html SGI Documentation] for proper description of revese_iterator in the STL. | ||
=== Events === | |||
==== Event struct ==== | |||
The following is a (revision of) a former comment in <code>common/events.h</code>: | |||
Rework/document this structure. It should be made 100% clear which field | |||
is valid for which event type. Implementation wise, we might want to use | |||
the classic union-of-structs trick. It goes roughly like this: | |||
<syntax type="C++"> | |||
struct BasicEvent { | |||
EventType type; | |||
}; | |||
struct MouseMovedEvent : BasicEvent { | |||
Common::Point pos; | |||
}; | |||
struct MouseButtonEvent : MouseMovedEvent { | |||
int button; | |||
}; | |||
struct KeyEvent : BasicEvent { | |||
... | |||
}; | |||
... | |||
union Event { | |||
EventType type; | |||
MouseMovedEvent mouse; | |||
MouseButtonEvent button; | |||
KeyEvent key; | |||
... | |||
}; | |||
</syntax> | |||
However, this approach is contrary to classic OO paradigms. Indeed, its | |||
major drawback is that all event types now must be POD data types, so | |||
e.g. they can't contain a Common::Point as member. Bad. | |||
An alternative approach would be a more OO like switch to multiple Event | |||
subclasses. This would, however, then require us to pass events around | |||
as pointers to object instances, and also would require introducing type | |||
casting in code using events. The passing around of pointers could be | |||
mitigated by using | |||
<syntax type="C++"> | |||
typedef Common::SharedPtr<BasicEvent> Event | |||
</syntax> | |||
or something like that. Yet this would mean increased overhead in all | |||
our code, yet the gain is unclear. In conclusion, we probably are best | |||
off by staying with the existing monolithic struct Event, we should just | |||
enhance its documentation. | |||
==== Event recorder ==== | ==== Event recorder ==== | ||