Refactor tasks architecture #146
Conversation
|
While the migration is not yet complete, the tests that have already been migrated pass successfully. The non-template part was separated from Task to speed up compilation. |
| template <typename InType, typename OutType> | ||
| struct GenericTaskData { | ||
| const std::span<InType> input; | ||
| std::span<OutType> output; | ||
|
|
||
| GenericTaskData(const std::span<InType>& input_, std::span<OutType> output_) | ||
| : input(input_), output(std::move(output_)) {} | ||
| GenericTaskData(const InType& input_, OutType& output_) | ||
| : input(std::addressof(input_), 1), output(std::addressof(output_), 1) {} | ||
| GenericTaskData(const std::span<InType>& input_, OutType& output_) | ||
| : input(input_), output(std::addressof(output_), 1) {} | ||
| GenericTaskData(const InType& input_, std::span<OutType> output_) | ||
| : input(std::addressof(input_), 1), output(std::move(output_)) {} | ||
| }; |
There was a problem hiding this comment.
please write code snippet, how yours GenericTaskData describe input - vector(uint8), vector(float), and output vector(uint8) and 1 element float?
There was a problem hiding this comment.
I'd say it depends on the task: it's possible to use std::pair<std::vector<uint8_t>, std::vector<float>> or std::tuple. If it's a more complex structure, I'd create a tiny struct descriptor for it (e.g. for matrix).
I.e. GenericTaskData<std::pair<std::vector<uint8_t>, std::vector<float>>, OutType> (or GenericTaskData<std::pair<Matrix, Matrix>, Matrix> for my 2nd task), but that's being specified in the class derived from Task actually.
Type safety. Using
std::spanin TaskData instead of raw pointers with separate supplement of their memory blocks sizes prevents heap overflow errors and simplifies the code overall. No morereinterpret_casts.Less boilerplate. The current way of initializing TaskData results in a huge amount of boilerplate code that very few people actually understand due to their poor understanding of pointer arithmetic - the need to copy it from test to test increases the likelihood of introducing a hard-to-debug bug unrelated to the task.
No shared_ptr usage. If you look closely, it is impossible to imagine a situation where using shared_ptr is justified now - they are used even where they are definitely not needed - for example, in perf tests when creating PerfAnalyzer. If you can give arguments in favor of using shared_ptr, or an example of a situation that cannot be normally implemented without using it, let's discuss it.