I am using C++ in an embedded environment (ESP32) and have been playing around with different ways of structuring my program. The program isn’t super complex but not so simple that it could all be contained in a single main file.

For the purposes of readability I have split the program up into different ‘managers’, each manager controls one aspect of the program (e.g, serial_manager, ui_manager). Each manager doesn’t know about any of the other managers and all communication between them is done through main.

The question I have is how best to implement these managers, and there is one question that I have searched for but haven’t found a satisfying answer for. From what I understand best practice in C++ often takes an object-oriented approach which might look something like this:

Object oriented approach

manager.h

#ifndef _MANAGER_H_
#define _MANAGER_H_

#include <stdint.h>

class foo_manager : public manager
{
  private:
    static const int CONNECT_PIN = 14;
    bool _is_connected = false;
    void on_connect();

  public:
    foo_manager();
    void setup();
    void update();
    bool is_connected();
}

#endif

manager.cpp

#include "hardware_manager.h"

foo_manager::foo_manager()
{
    // some construction
}

void foo_manager::on_connect()
{
 // Do something related to connecting
}

bool foo_manager::is_connected()
{
  return _is_connected;
}

void foo_manager::setup()
{
  gpio_set_mode(CONNECT_PIN, OUTPUT);
  gpio_set_low(CONNECT_PIN);
}

void foo_manager::update()
{
  _is_connected = gpio_read(CONNECT_PIN);
  if (_is_connected)
  {

 }}
}

}

main.cpp

#include "manager.h"


void main()
{
    foo_manager manager;
    manager.setup();
    while (1)
    {
        maanger.update();
        sleep(10);
    }
}

Coming from C I tend to use a ‘C+’ approach, i.e using the C++ features that improve readability/maintainability but have little to no impact on the program execution, and I don’t tend to use classes unless I actually want multiple instances of something or inheritance. Based on this I have used a ‘namespaced free functions’ approach.

Eg.

Namespaced free functions approach

manager.h

#ifndef _MANAGER_H_
#define _MANAGER_H_

#include <stdint.h>

namespace foo_manager
{

typedef struct {        // Data types defined here
  int a;
  int b;
} example_type_t;


void setup();          // Initialises anything that the manager uses
void update();         // Called regularly to allow the manager to operate

bool is_connected();   // Functions are only exposed if needed by other parts of the program

}

#endif

manager.cpp

#include "manager.h"

namespace foo_manager
{

static const int CONNECT_PIN = 14;

static bool _is_connected = false;      // State defined as static global. Stealing the _prefix from C++ members

void on_connect()
{
 // Do something related to connecting
}

bool is_connected()
{
  return _is_connected;
}

void setup()
{
  gpio_set_mode(CONNECT_PIN, OUTPUT);
  gpio_set_low(CONNECT_PIN);
}

void update()
{
  _is_connected = gpio_read(CONNECT_PIN);
  if (_is_connected)
  {
    on_connect();
  }
}

}

main.cpp

#include "manager.h"


void main()
{
    foo_manager::setup();
    while (1)
    {
        foo_manager::update();
        sleep(10);
    }
}

This could be described as a a sort of singleton class without any of the overhead of the singleton.

Benefits of free functions approach:

• Not possible to create a different instance of particular manager

• Still has concepts of public (in the header file) and private (in the cpp file)

• No need to add overhead by passing instances around

• Access to C style function pointer callbacks (for use with gpio or timer interrupts)

  • This is a key point for me, some of the libraries I am using don’t allow an option argument which prevents me from passing a this pointer meaning that I can’t have an event driven paradigm (since you can’t pass member functions to a C style callback)

Benefits of object oriented approach:

• Better practice (?)

• No globals

• More common so may be more understandable to a new person reading it (my colleagues come from a python background so tend to have an OO approach to things)

I have generally designed in the namespaced free functions approach and haven’t ever had any issues with it. I have just moved to a new organisation and have a colleague reviewing my work and he is unsure that the approach I am taking is in line with best practice (although he has a Python background)