std::function or a function pointer in C++

[ali80]

Since using std::function has many benefits such as being able to pass multiple arguments (using capture clause) and simpler syntax, I'm curious to know is there a reason you chose function pointers over this?
here is a reference for comparison
std::function or a function pointer in C++?
are you open to adding another function overload using std::function without breaking backward compatibility?

[ghost]

arduino does support std::function ? i guess not, but esp32 can for example.

[philj404]

See also #59. There is a workaround described in #11. Std::function is part of C++11 (2011)... but Arduino has been around since ~2005.

It can be difficult to confirm that std::function is actually supported on all compilers for all Arduino platforms -- especially as people are still adding new boards. Hopefully new boards support the latest compilers.

[ali80]

arduino does support std::function ? i guess not, but esp32 can for example.

well, that makes sense, I've never used atmega chips with arduino platform, only esp8266/esp32 which both support this.

@philj404 while the workaround does the job, the direct path would have been much much shorter with zero hassle for the supported platforms.
Cant the overload only be defined for supported platforms,
If someone would try to create an overload for this, what would be your proposed syntax? is this OK?

Task in(std::function<bool(void)> callback, unsinged long delay)

or another way would be just #if defineing as std::function for supported platforms? 🤔

# if !defined(ESP32) && !defined(ESP8266)
  typedef bool (*handler_t)(T opaque); /* task handler func signature */
#else
  typedef handler_t std::function<bool(T opaque)> callback
#endif

[philj404]

I looked at your link... It seems the change is just in the header file:

  ...
  typedef bool (*handler_t)(T opaque);
  ...

changing to:

  ...
  #include <functional>
  ...
  typedef handler_t std::function<bool(T opaque)> callback
  ...

For the (existing) example code and how I use timers I do not see what benefit the change provides. Does it require extra storage overhead?

Do you have an example which shows what I could do "better" after this change?

I have not used std::function. But I'm willing to learn to write better code...

[ali80]

well, for me the most important improvement would be that you can easily pass 1 or multiple arguments to lambdas, as GOD intended :) like all other modern languages, (including C++ 11 and afterwards)
according to docs, the storage overhead exists but is minimal even for embedded systems.
here is an example of my use case

char* url = new char[64];
sprintf(
  url, "http://%s/api/v2?cmd=%s", baseIp, cmd);
timer.in(
    1,
    [](void* arg) -> bool {
        auto url = (const char*)arg;
        auto http = Locator::getHttpService();
        http->get(url);
        delete[] url;
        return false;
    },
    (void*)url);

would become

char* url = new char[64];
sprintf(
  url, "http://%s/api/v2?cmd=%s", baseIp, cmd);
timer.in(
    1,
    [&](void* arg) -> bool {
        auto http = Locator::getHttpService();
        http->get(url);
        delete[] url;
        return false;
    });

also this way it would be possible to pass multiple arguments to the lambda without needing any additional work such as defining new types...
like in above example if cmd and baseIp are globally stored, you can skip dynamic memory allocation and pass them directly to the callback

timer.in(
    1,
    [&](void* arg) -> bool {
      char url[64];
      sprintf(
        url, "http://%s/api/v2?cmd=%s", baseIp, cmd);
        auto http = Locator::getHttpService();
        http->get(url);
        return false;
    });
}

[philj404]

Thank you for the example. That stretches my brain!

I can see where safely capturing context for the task's function arguments could be MUCH simpler (as GOD intended). Unfortunately the ATmega328 design review couldn't wait long enough for feedback from GOD. I am sure they asked though 😃.

I was able to modify .../extras/tests/unitTest.ino and arduino-timer.h to use std::function. The actual changes that worked for me were "minor":

#include <functional>
...
    //typedef bool (*handler_t)(T opaque); /* task handler func signature */
    typedef std::function<bool(T opaque)> handler_t;  // NEW std::function<> signature
...

• This compiled for ESP32. (I also had to clean up some type conversion warnings for test comparisons.)
• Unfortunately I couldn't run the ESP32 tests as I don't have the hardware.
• The code does NOT build for Arduino UNO (ATmega328), as the build tools do not have the header.

So in principle it is possible to use std::function<>, but only for some processor families.

[philj404]

... So I guess an overload or something could work.

@ali80 you suggest an overload for Timer<>. That might be the best way to do it, but I'm not sure how to do it. I'm more of a consumer of template classes; I have not created a template class.

But as we would need to support BOTH interfaces, there are downsides:

• Documentation: With two ways of implementing handler_t, it will be more difficult to understand how to get something to work. Some examples only work for some architectures. How do we make it obvious which examples are the useful ones?
• Maintenance: It's important to confirm working code does not break with a code change. How do we do this for two different styles of timer, and only one test platform (UnixHostDuino)?

Another alternative would be to formally drop support for ATmega family processors... but that kind of takes the "Arduino" out of arduino-timer ☹️ .

[ali80]

I can see where safely capturing context for the task's function arguments could be MUCH simpler (as GOD intended). Unfortunately the ATmega328 design review couldn't wait long enough for feedback from GOD. I am sure they asked though 😃.

well, passing context variables to lambda, is basic feature I really miss here (I suspect GOD is also not happy with this 😃). good design decisions on lower levels opens up new and powerful options on user level.

I was able to modify .../extras/tests/unitTest.ino and arduino-timer.h to use std::function. The actual changes that worked for me were "minor"

this is great news, after discussion I'm more much leaning toward this solution. which is

# if !defined(ESP32) && !defined(ESP8266)
  typedef bool (*handler_t)(T opaque); /* task handler func signature */
#else
  typedef handler_t std::function<bool(T opaque)> callback
#endif

nothing changes for arduino and other legacy platforms, but on supported platforms users can enjoy the benefits of std::function.
also since std::function is kinda backward compatible with function pointers, not much user code should break in principle!

the overload method is also possible if we really dont want to change previous function syntax, but you are right, it can get confusing for the users

[contrem]

A work around could be to use the parametrized handler argument with a dispatcher function:

(untested)

#include <functional>
#include <arduino-timer.h>

template <typename T>
bool dispatcher(T action) {
  return action();
}

Timer<16, millis, std::function<bool(void)> > timer;

void setup() {
  int closure = 1;

  timer.in(10, dispatcher, [&]() -> bool {
    if (closure) return true;
    else return false;
  });
}

void loop() {
  timer.tick();
}

[ali80]

very interesting workaround. it fixes my issue for now, thanks,
but if I may ask, what do you think about the direct route?

# if !defined(ESP32) && !defined(ESP8266)
  typedef bool (*handler_t)(T opaque); /* task handler func signature */
#else
  typedef std::function<bool(T opaque)> handler_t;
#endif