5

I don't yet own an Arduino board to run code on, and as the title says, I'm curious if the C++ STL is fully supported on Arduino and already part of the Arduino IDE. The STL is probably the most efficient, fully tested, and resource-minimal (which is a slightly redundant phrase, as I already mentioned efficiency) publicly available C++ code out there, and would make life much easier to code for Arduino.

If the STL is not a part of Arduino IDE, then how to include specific libraries such as <algorithm> and <utility>? (I'm very tempted to ask "why isn't it included?" but that seems too broad.)

  • 1
    The problem with "efficient" is that it doesn't specify just how efficient it is; will it run well on a 16MHz device with only 2kiB of RAM? – Ignacio Vazquez-Abrams Jun 1 '16 at 17:30
  • 1
    and already part of the Arduino IDE - last time I looked it wasn't. Personally I like the STL, and think it should be included. Whether or not you can tolerate the overhead is surely a decision for the end-user? I installed the Maniacbug library fairly recently, and it seemed to work OK. – Nick Gammon Jun 3 '16 at 7:43
9

The STL is not a part of Arduino IDE.

Although efficient by desktop standards, the consensus is it doesn't fit comfortably in an Arduino's limited space. That said, here's someone who seems to have done it:

https://github.com/maniacbug/StandardCplusplus

Check out the forks, they seem more up to date

  • 2
    I'm against this consensus :p so it's not really a consensus anymore? ;p it should be used wisely, but can be very powerfull/usefull. Not everything of it may work as well. But we used std::queue to create a message-queue which the Arduino would clear. In theory it could get overrun, but it's usually more space efficient as setting an fixed buffer. Because one needs to set the buffer big enough, but will end up always "using" the full memory of the buffer. – Paul Jun 1 '16 at 17:41
  • @Paul Could you please explain why you have a different perspective? I'm sure it's interesting/educational. – NonCreature0714 Jun 1 '16 at 17:43
  • @Paul do you use the maniacbug version or a different flavor? Please share. STL looks interesting to me but its slight lean towards dynamic allocation and rtti shied many (including myself) from using it for AVR scenarios – Malachi Jun 1 '16 at 17:48
  • 2
    It was actually in my seconden year, we used the GNU-GCC toolchain with, I believe AVR-GCC, avrdude and eclipse. But I don't know how we got stl, it seemed easy at that time – Paul Jun 1 '16 at 17:50
  • 1
    But, I think it's worth trying, especially with the newer microcontrollers, with more ram. If you try it, it may actually work very well. – Paul Jun 1 '16 at 18:23
2

The STL is not part of Arduino and no support for libstc++ from AVR.

My "answer" differences from Malachi at one point though, as explained in the comments.

I don't think you shouldn't, just because "most people say" that you shouldn't. There are a lot of people that even think you shouldn't use C++ at all. The problem is that C++ (and C++ standard library) are very powerful and may be ported in a non-efficient way.


Why use libstdc++?

I think, however, that if you use it with care, it can be very usefull.

Let's say we've got two buffers, a send buffer and a receive buffer. With C, you would store them in a fixed char array. In C++ you can use dynamic containers.

So in C, you'll use 2x 256 bytes of memory to save your messages. Any longer message won't fit.

In C++ you'll use only whatever bytes are needed at one point (plus some extra probably). And if you get a longer message, it will simply scale up.

If the C++ thing works for you, and just test it very very well, why not use it? On average, it will use less memory, since you don't assign all of it when it's not used. You will have a problem when your messages get too big, since your memory will overflow, often causing the microcontroller to reset. But if more buffers in your program are dynamic, one may leave some space for the other, etc. Effectively using the memory more efficient!

But, without dynamic allocation, it might be a little safer, since you've already claimed those pieces of memory, there is no way you can't use those pieces. Any message that is bigger, simply won't fit, but you can easily check on that. Another thing is that the C++ stl's you find, might not be as well optimalised for your architecture/microcontroller.

Also, creating your very own dynamic storage in C may cause even more problems than the C++ stl ;). And it's not like you have to use dynamic storage for everything, simply being able to do so is nice.


Current microcontrollers are also getting much more serious as the 8-bit Arduino's (328P). 20$ can get you a Teensy 3.2 which has 256K Flash Memory, 64K RAM so, in this case, dynamic memory can be very useful (if you are certain you always have enough memory left). Also: All STM32F41xxx products embed: Up to 192 Kbytes of system SRAM including 64 Kbytes of CCM (core coupled memory) data RAM

By that, it can also be a very nice way to learn C++ and program in the same language as you do on the PC. But keep in mind that on an 8-bit micro, you should check if your stl-functions don't give too much overhead.


How use C++ standard template library for AVR?

I've followed the blog from Andy Brown and now have iterators/string/vectors working in AtmelStudio.

Though I did get some errors, the first batch of errors included:

Error        '_M_deallocate' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]      D:\avr-stl\include\string    173
Message        declarations in dependent base 'std::_String_alloc_base<char, std::allocator<char>, true>' are not found by unqualified lookup        D:\avr-stl\include\string    173
Message        use 'this->_M_deallocate' instead     D:\avr-stl\include\string    173

This error actually explains itself; you should use this->_M_deallocate.

After that I got undefined reference to "operator new(unsigned int, void*). But I fixed it by including "pnew.cpp" right under #include <new> in stl_construct.h which is weird, but it works.

(Piece of stl_construct.h)

#ifndef __SGI_STL_INTERNAL_CONSTRUCT_H
#define __SGI_STL_INTERNAL_CONSTRUCT_H

#include <new>
#include <pnew.cpp>

__STL_BEGIN_NAMESPACE
  • After checking some stuff on the internet, it indeed appears that static allocation is most often better than dynamic allocation. Since the problems (possible overflows, less control and heap fragmentation) are unlikely to weigh up against the benefits. BUT, that doesn't mean everyone should stop experimenting with it ;) and nor that it can't be usefull in some niche applications (thus it's not a bad thing to have it "installed"). – Paul Jun 2 '16 at 16:55
  • 1
    Tough crowd, I don't think you deserve a negative for your answer! Heap fragmentation is one of the main things that steer me away from dynamic memory on AVR. However, on bigger chips I'm a fan - when used carefully. – Malachi Jun 2 '16 at 18:11
2

STL is efficient on the platform it was designed for, which is personal computers and similar-scale devices, where allocating a single byte in the heap consumes a 4k memory page (that's several times as much as ALL Arduino RAM), and where array indexes can be efficiently replaced by pointers (8-bit microcontrollers need at least two commands to deal with a pointer). So no, it's not efficient with Arduino.

Think of quicksort algorithm - it performs very well on large lists, but is easily beaten by a simple sort if you need to sort an array of 5 elements. Being asymptotically efficient doesn't mean being efficient in every case.

  • Unless the library is re-written for AVR. In theory it will be better/more efficient as me trying to program a queue or priority queue in C. If you really need the behavior, you should atleast consider or try it. – Paul Jun 2 '16 at 15:17
  • I would personally use an AVR port of C++ STL which is on GitHub, and bother the people on GitHub if you've got a better implementation, this way we can make it work, instead of everyone choosing to create his own implementation ;) And since it's on GitHub (and may even have multiple contributors) and is aimed on AVR. It should perform reasonable and be reviewed by multiple. Which is probably better/faster as some self written code. But I agree on the part: "use with care". But not "don't use because the PC version will be no good.". – Paul Jun 2 '16 at 15:23
  • @Paul If STL were to be rewritten for AVR, it would automatically lose it's "fully tested / mature" status, wouldn't it? – Dmitry Grigoryev Jun 2 '16 at 15:24
  • Well, if you were to implement it yourself, it would automatically lose it's fully tested status aswell :p and if you collaborate on github, it's more fully tested as when you're doing it alone? (: – Paul Jun 2 '16 at 16:15
  • Plus, on stl being fully tested; yes it is, for PC. (: – Paul Jun 2 '16 at 16:18
1

The STL is not a part of Arduino IDE.

Another answer is mentioning https://github.com/maniacbug/StandardCplusplus although this library doesn't seem to be maintained anymore.

Maybe a better idea could be to try https://github.com/mike-matera/ArduinoSTL

It's a port of uClibc++ packaged as an Arduino library.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.