Dynamic memory allocation in on startup

Is is a bad idea to allocate Memory via new inside a constructor of a class in global variable section? I read a lot about dynamic memory and microcontrollers. Mostly using dynamic memory is considered a bad thing.
But what happens when the memory is allocated only once in setup() or in the globals section? In my opinion this shouldnt be a problem, because no memory leak and heap fragmentation should occur.

To clarify things consider this class structure:
The class Foo which should be used in the .ino file

class Foo{
  private:
    A* a1;
    A* a2;
    A* a3;
  public:
    Foo();
    void run();
};

Foo::Foo(){
    this->a1=new A;
    this->a2=new B;
    this->a3=new C;
}
void Foo::run(){
  a2->run();
}

Note: a1,a2,a3 are initialised dynamically in the constructor of Foo which is called in the global variable section of the .ino file.
Class A:

class A{
  private:
    uint32_t x;
  public:
  virtual void run();
};
void A::run(){
  Serial.println("Run A");
}

Inherited Classes B and C:

class B:public A{
  public:
    virtual void run() override;
};
void B::run(){
  Serial.println("Run B");
}

class C:public A{
  public:
   virtual void run() override;
};
void C::run(){
  Serial.println("Run C");
}

finally the main.ino file:

#include "test.h"

Foo test; //Constructor should be called here
void setup() {
  Serial.begin(115200);
}

void loop() {
  test.run();
}

It works as expected, but i wonder if it is a suited solution for embedded systems ?
Why do i need this: I want to use the so called "State Pattern" to implement a Finite State Machine on Arduino. I dont want the main.ino file cluttered with state declarations, so i try to hide them in a StateMachine class (here called Foo).

In my opinion the compiler should be able to determine at compile-time how many instances of A,B and C are created. No dynamic Memory allocation should be required during runtime.
What do all the experts out there think about this situation?

The problem with dynamic memory allocation on a micro controller is that with so little RAM, heap fragmentation can be a serious problem. As you observe, this isn't a problem if you're never going to free that memory.

The advantage of dynamic allocation on a PC is that you only consume as much memory as you need, acting as a considerate neighbor to the hundreds of other processes that need memory too. With most micro controllers, there are no other processes to share with, so there's no need. You may as well declare enough variables to deal with your worst case scenario and be done - saving RAM gets you nothing.

Thanks for your reply :slight_smile: What do you think about this code ? Is it bad practise to do something like that or a good method of hiding implementation details in a seperate class?

best regards,
David

Why are you using override ?

-jim lee

It is fine to declare objects and let it use a fixed part of the heap, many libraries do. Saying that, as long as you don't use the heap for other things like Strings which have a variable size, or just make sure that you object is created first. neopixel.h creates the buffer on the heap and there is no issue. I don't think the compiler actually counts the amount of variables taken up by heap declarartion though, so you will have to keep an eye on that yourself.