How to exploit polymorphism on embedded systems? - c++

Question

I have been developing a C++ software driver for the adc peripheral of the MCU.
The individual analog inputs connected to the adc can be configured for operation in the unipolar or bipolar mode. To reflect this fact in my design I have decided to model the analog inputs by the AnalogInput abstract class and then define two derived classes. UnipolarAnalogInput for the unipolar analog inputs and BipolarAnalogInput for the bipolar analog inputs. These two classes differ only in the implementation of the getValue() method.
enum class Type
{
Unipolar,
Bipolar
};
class AnalogInput
{
public:
virtual float getValue() = 0;
};
class UnipolarAnalogInput : public AnalogInput
{
public:
UnipolarAnalogInput(uint8_t _id, bool _enabled, Type _type);
bool isEnabled();
bool isReady();
float getValue();
private:
uint8_t id;
Type type;
bool enabled;
bool ready;
uint16_t raw_value;
};
class BipolarAnalogInput : public AnalogInput
{
public:
BipolarAnalogInput(uint8_t _id, bool _enabled, Type _type);
bool isEnabled();
bool isReady();
float getValue();
private:
uint8_t id;
Type type;
bool enabled;
bool ready;
uint16_t raw_value;
};
My goal is to fullfill following requirements:
work with both types of the analog inputs uniformly
have a chance to create either the instance of the UnipolarAnalogInput or BipolarAnalogInput
based on users configuration of the Adc which is known at the compile time
have a chance to create the instances in for loop iteration
have the implementation which is suitable for the embedded systems
Here are my ideas
As far as the requirement 1.
The ideal state would be to have AnalogInput analog_inputs[NO_ANALOG_INPUTS]. As far as I understand
correctly this is not possible in C++. Instead of that I need to define AnalogInput *analog_inputs[NO_ANALOG_INPUTS].
As far as the requirement 2.
It seems to me that the best solution for the other systems than the embedded systems would be to use the factory method design pattern i.e. inside the AnalogInput define
static AnalogInput* getInstance(Type type) {
if(type == Unipolar) {
// create instance of the UnipolarAnalogInput
} else if(type == Bipolar) {
// create instance of the BipolarAnalogInput
}
}
Here I would probably need to define somewhere auxiliary arrays for the UnipolarAnalogInput instances and the BipolarAnalogInput instances where the instances would be allocated by the factory method and the pointers to those arrays would be returned by the getInstance(). This solution seems to me to be pretty cumbersome due to the auxiliary arrays presence.
As far as the requirement 3.
for(uint8_t input = 0; input < NO_ANALOG_INPUTS; input++) {
analog_inputs[input] = AnalogInput::getInstance(AdcConfig->getInputType(input));
}
As far as the requirement 4.
Here I would say that what I have suggested above is applicable also for the embedded systems
because the solution avoids usage of the standard new operator. Question mark is the virtual
method getValue().
My questions is whether the auxiliary arrays presence is unavoidable?

Answer 1

The "auxiliary array" as you call it is mostly needed for memory management, i.e. you need to choose the memory to store your objects in. It's also an interface - the array is how you access the ADCs.
You can store your objects either in the heap or the (global) data segment - an array of objects implements the latter (you can also create global variables, one per ADC, which is a worse solution). If the compiler has all the information it needs to allocate the memory during compilation, it's usually the preferred approach. However - as you've noticed - polymorphism becomes rather annoying to implement with statically allocated objects.
The alternative is to keep them in heap. This is often totally acceptable in an embedded system if you allocate the heap memory at startup and keep it permanently (i.e. never try to release or re-use this part of heap, which would risk fragmentation). And this is really the only humane way to do polymorphic stuff, especially object instantiation.
If you don't like the array, use some other storage method - linked list, global variables, whatever. But you need to access the objects through a pointer (or a reference, which is also a pointer) for polymorhpism to work. And arrays are a simple concept, so why not use them?