Event framework - stl vs. custom code

Hi folks,
I’m working on an event framework to facilitate programming in response to timers and I/O. A decision I need to make fairly early is whether to use stl collections or custom code my own collections. I have a start on timer handling and have implemented it both ways. I thought it might be useful to share that with the community for feedback on this. I’m looking at both code size and RAM footprint. Initially a small test shows that choosing stl uses more. (974 bytes code as reported at compile and 58 bytes more RAM reported using the MemoryFree library.)

stl pros and cons - bigger code and RAM footprint, requirement to install an additional library, easier and more flexible programming.
custom container - smaller code and RAM footprint, more programming effort.

Sketch programming requirements should be similar for either choice. My intent is to make this into a library to share with others so ease of use is important.

The code itself is too big to include inline so I have included as attachments.

In addition to the specific question regarding memory footprint, I appreciate other comments on the idea and sketches. If I go with custom code I plan to make other significant changes because I don’t really like the first cut. Namely I would probably templateize the various types of event classes, but I am open to other patterns that might be applicable.

ef_memcheck.ino (6.32 KB)

STL_ev_memcheck.ino (5.38 KB)

Both approaches look horribly complicated compared to how I would manage several things - as in the demo sketch in this Thread.

I am not a fan of libraries to manage events on something small like the Arduino because when they go wrong they are more troublesome for the user than if s/he wrote her/his own code.


Hi Robin, Thanks for the reply. I looked over your post and like it. I would have no hesitation recommending that strategy for anyone who wants to move past delay() for timing. I suspect you share my dislike for seeing that in any but the simplest of examples.

It is my desire that the library reduce the complexity that the coder is exposed to by extracting the commonality and putting that where the user need not be bothered. For example, the code needed to print out free RAM stats every two seconds is:

class MemTimer : public Timer {
    MemTimer(int t=1000, int r=0):Timer(t,r){};
    MemTimer(const MemTimer& e){coln("MyTimer copied");};
    void callBack(int late) {        // callback when Timer fires

void setup() {

That's still a tall order for someone unfamiliar with C++ and part of the reason I'm soliciting comments here. Perhaps someone has a suggestion to improve that.

As far as "go wrong" I hope to avoid that too. I can test the library extensively to verify correct operation. By sharing it, I also get the eyeballs of folks more experienced than myself with Arduino coding that can point out errors in the code. And once the code in the library is fixed, it should remain so. If you need to start from scratch each time you start a project, you are susceptible to introducing bugs each time, such as the suggestion to use switch() rather than if/then/else to manage states (and forgot to break at the end of each state handler.) One of the issues I need to deal with is what happens when the return value from millis() rolls over. When I do solve that, I will have on location in the code to handle the situation rather than having to fix each procedure that checks for a time delay.

best, hank

I think my approach would be to spend the time writing a tutorial to help newbies write their own code rather than on writing code that does the work for them.

HankB: As far as "go wrong" I hope to avoid that too.

You may like to read this.