1,510
edits
Difference between revisions of "TODO"
→Event struct: -- fix code highlighting
(→Common code, infrastructure: Add error handling task) |
(→Event struct: -- fix code highlighting) |
||
| Line 99: | Line 99: | ||
is valid for which event type. Implementation wise, we might want to use | is valid for which event type. Implementation wise, we might want to use | ||
the classic union-of-structs trick. It goes roughly like this: | the classic union-of-structs trick. It goes roughly like this: | ||
< | <source lang="cpp"> | ||
struct BasicEvent { | struct BasicEvent { | ||
EventType type; | EventType type; | ||
| Line 120: | Line 120: | ||
... | ... | ||
}; | }; | ||
</ | </source> | ||
However, this approach is contrary to classic OO paradigms. Indeed, its | However, this approach is contrary to classic OO paradigms. Indeed, its | ||
| Line 131: | Line 131: | ||
casting in code using events. The passing around of pointers could be | casting in code using events. The passing around of pointers could be | ||
mitigated by using | mitigated by using | ||
< | <source lang="cpp"> | ||
typedef Common::SharedPtr<BasicEvent> Event | typedef Common::SharedPtr<BasicEvent> Event | ||
</ | </source> | ||
or something like that. Yet this would mean increased overhead in all | 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 | 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 | off by staying with the existing monolithic struct Event, we should just | ||
enhance its documentation. | enhance its documentation. | ||
=== Build System === | === Build System === | ||