user21629: 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.)

user8033: 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


user13327: 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.

user3042: 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.

user17170: 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

21629: <p>I don't yet own an Arduino board to run code on, and as the title says, I'm curious if the <a href="http://www.cplusplus.com/reference/" rel="noreferrer">C++ STL</a> is fully supported on Arduino <strong>and already part of</strong> 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. </p>

<p><em>If</em> the STL is not a part of Arduino IDE, then how to include specific libraries such as <code>&lt;algorithm&gt;</code> and <code>&lt;utility&gt;</code>? (I'm very tempted to ask "why isn't it included?" but that seems too broad.)</p>
 8033: <p>The STL is not part of Arduino and no support for <a href="http://www.atmel.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_cplusplus.html" rel="nofollow">libstc++ from AVR</a>.</p>

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

<p>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.</p>

<hr>

<p><strong>Why use libstdc++?</strong></p>

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

<p>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.</p>

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

<p>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.</p>

<p>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!</p>

<p>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.</p>

<p>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.</p>

<hr>

<p>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 <code>256K Flash Memory, 64K RAM</code> so, in this case, dynamic memory can be very useful (if you are certain you always have enough memory left). 
Also: <code>All STM32F41xxx products embed: Up to 192 Kbytes of system SRAM including 64 Kbytes of CCM (core coupled memory) data RAM</code> </p>

<p>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.</p>

<hr>

<p>How use C++ standard template library for AVR?</p>

<p>I've followed the blog from <a href="http://andybrown.me.uk/2011/01/15/the-standard-template-library-stl-for-avr-with-c-streams/" rel="nofollow">Andy Brown</a> and now have iterators/string/vectors working in AtmelStudio.</p>

<p>Though I did get some errors, the first batch of errors included:</p>

<pre><code>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&lt;char, std::allocator&lt;char&gt;, true&gt;' are not found by unqualified lookup        D:\avr-stl\include\string    173
Message        use 'this-&gt;_M_deallocate' instead     D:\avr-stl\include\string    173
</code></pre>

<p>This error actually explains itself; you should use <code>this-&gt;_M_deallocate</code>.</p>

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

<p>(Piece of stl_construct.h)</p>

<pre><code>#ifndef __SGI_STL_INTERNAL_CONSTRUCT_H
#define __SGI_STL_INTERNAL_CONSTRUCT_H

#include &lt;new&gt;
#include &lt;pnew.cpp&gt;

__STL_BEGIN_NAMESPACE
</code></pre>
 13327: <p>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.</p>

<p>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.</p>
 3042: <p>The STL is not a part of Arduino IDE.</p>

<p>Another answer is mentioning <a href="https://github.com/maniacbug/StandardCplusplus" rel="nofollow noreferrer">https://github.com/maniacbug/StandardCplusplus</a> although this library doesn't seem to be maintained anymore.</p>

<p>Maybe a better idea could be to try <a href="https://github.com/mike-matera/ArduinoSTL" rel="nofollow noreferrer">https://github.com/mike-matera/ArduinoSTL</a></p>

<p>It's a port of uClibc++ packaged as an Arduino library.</p>
 17170: <p>The STL is not a part of Arduino IDE.  </p>

<p>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:</p>

<p><a href="https://github.com/maniacbug/StandardCplusplus">https://github.com/maniacbug/StandardCplusplus</a></p>

<p>Check out the forks, they seem more up to date</p>
