Refactor all container pointer references to template types #368

New Issue

muellerr · 2021-02-06T14:07:48+01:00

muellerr commented

2021-02-06 14:07:48 +01:00

Right now, there are some implementation of classes to allow different types of containers for say, a data structure like a queue or an array of pool variables.

This is done by storing a address of the container structure start and the size (so, basically C style)

Examples:

PoolDataSetBase

	/**
	 * @brief	This array represents all pool variables registered in this set.
	 * Child classes can use a static or dynamic container to create
	 * an array of registered variables and assign the first entry here.
	 */
	PoolVariableIF** registeredVariables = nullptr;

FIFOBase

    T* values;

However, considering the options available with modern C++, this is not really an ideal solution. One has to write custom copy ctors and assignment ctors, because simply copying the pointer is wrong (rule of 3/5).

However, considering we have working code right now, I might wait with the refactoring steps. This should not change the external API however, because the public interface to be used will still be containers like the StaticLocalDataSet , which simply have the base class with the correct template arguments (e.g. std::array for the StaticLocalDataSet and std::vector for the regular LocalDataSet)

Right now, there are some implementation of classes to allow different types of containers for say, a data structure like a queue or an array of pool variables. This is done by storing a address of the container structure start and the size (so, basically C style) Examples: ### PoolDataSetBase ```cpp /** * @brief This array represents all pool variables registered in this set. * Child classes can use a static or dynamic container to create * an array of registered variables and assign the first entry here. */ PoolVariableIF** registeredVariables = nullptr; ``` ### FIFOBase ```cpp T* values; ``` However, considering the options available with modern C++, this is not really an ideal solution. One has to write custom copy ctors and assignment ctors, because simply copying the pointer is wrong (rule of 3/5). However, considering we have working code right now, I might wait with the refactoring steps. This should not change the external API however, because the public interface to be used will still be containers like the `StaticLocalDataSet` , which simply have the base class with the correct template arguments (e.g. `std::array` for the StaticLocalDataSet and `std::vector` for the regular LocalDataSet)

muellerr added the

feature

label 2021-02-06 14:07:57 +01:00

muellerr changed title from ~~Refactor all container references as double ** to template types~~ to Refactor all container pointer references to template types

2021-02-06 14:08:06 +01:00

muellerr commented

2021-02-06 15:33:39 +01:00

Some more research:

https://stackoverflow.com/questions/7728478/c-template-class-function-with-arbitrary-container-type-how-to-define-it

That way, I might be able to get rid of the pointers. This should work with std::array and std::vector.

Some prototyping: https://stackoverflow.com/questions/66082447/c-using-container-as-a-template-type/66087589#66087589

Not sure if it's worth the effort though. Would require a new interface because now the object base would be a template. But also interesting, this now feels a little bit like duck typing.

Some more research: https://stackoverflow.com/questions/7728478/c-template-class-function-with-arbitrary-container-type-how-to-define-it That way, I might be able to get rid of the pointers. This should work with `std::array` and `std::vector`. Some prototyping: https://stackoverflow.com/questions/66082447/c-using-container-as-a-template-type/66087589#66087589 Not sure if it's worth the effort though. Would require a new interface because now the object base would be a template. But also interesting, this now feels a little bit like duck typing.

gaisser commented

2021-03-04 21:19:22 +01:00

I think the downside is the testing effort. This kind of Templates are difficult to test, especially if the underlying container is totally different. Even if its only two kind of possible template arguments. This makes it rather uninteressting for small and reliable embedded software that doesn't change much. Interesstingly, forbidding copying has a nice side effect. Because copying a container that has a std::vector as an member will allocate memory at runtime and that will be a difficult issue to track down.