Arduino Vectors yet?

I know that there are implementations of Vector for Arduino that use a storage array. And I also know that dynamic memory allocation on Arduino (especially frequent new/delete calls) is a bad idea because of heap fragmentation / the small memory sizes we're dealing with.

That said, are there any Arduino based microcontrollers that are big/advanced enough to be able to handle using vectors in today's world?

It seems such a basic and helpful tool in C++ (outside of the Arduino) to be able to create containers where you don't need to know the size upfront and ones that can change during run time.

I've had a small amount of success using a unique pointer, 'stdarg' and a call to new (only the once at startup, and the lifetime is for the duration of the program) in order to create varying sized arrays inside a class. But it would be a whole lot simpler to be able to use vectors. :laughing:

I don’t see an advantage in the context of these little programs we write.

Unless you have an unknown need for multiple different objects, any problem is going to have a maximum size that can fit your soltution, so why not just code for that?


The cores for the ARM and ESP-based Arduino boards have STL implementations, including std::vector.

Say for example a menu system, where the child items are stored in an array. Some (most) parents have a handful of children say 2 or 4, but some have 25 children. It seems a giant waste of memory to allow all 'menu' pages to hold 25 pointers to children, when 23 are set to nullptr.

Do they run into the same heap frag problems I've read about when trying to use vectors on AVR's? Or another way to phrase that would be, are they as safe and 'free' to use as they are in the computer world?

Yes. Unless you have another use for it, that’s not a problem.

Same as getting away with delay or a suboptimal calculation - if you have the time, no problem.

Maybe something handling 25 children would get sluggish instead of always being sluggish, but still work in a dynamic allocation thing.

Even if you had competition for forks and knives, you could do your own management.

But srsly my atitude may be entirely different as I am coming up to the Arduino UNO class processors after using micros with way fewer resources and power… so I’m like a kid in the candy shop and still gun-shy about anything I can’t see in the code in front of me. :expressionless:


why do you need all items to hold them, you can make a base class with 25 elements array and reuse it in derived classes

I don't mean to hijack my own thread to discuss a possibly poor example :smiley: Sure, but how far do you run with that? What if the hypothetical had each menu page having one more child than the last, would you suggest a derived class with 6 children, another with 7 children, another with 8 children etc etc. Especially when (on a PC for example) you just do that v.push_back() and problem solved!

In that particular example I mentioned, I managed to get around it this way, which seemed to work:

    std::unique_ptr<Menu*[]> children = { nullptr };

// Constructor

    Menu(char const * title, uint8_t size, ...)
      : title(title), size(size), children { new Menu*[size] }
      va_list arguments;
      va_start(arguments, size);
      for (int i = 0; i < size; i++) {
        children[i] = va_arg(arguments, Menu*);
        children[i]->parent = this;

But again... Not to hijack the thread. I was only wondering if vectors are guilt-free at our disposal yet.

Go for it, assuming ARM or ESP.

Yeah, it was messing with the ESP32 sim in Wokwi. So what makes it safe to use on ARM/ESP in comparison?

Aren’t push_back doubles the size when it needs to resize? You almost always will have more memory taken by it than you use if you just use push_back, might as well reserve for all your needs upfront

Some of the ARMs (SAMD21 in particular), are still pretty short of RAM for dynamic allocation. (32k is a lot better than 2k, but...)

what makes it safe to use on ARM/ESP in comparison?

Mostly larger RAM. That's not JUST for the dynamically allocated storage you're using, but also allows more space to be used for the data structures controlling the memory allocation. Also the extra code space and wider math allows for a more robust malloc/free implementation as well.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.