Introduction: Is Arduino Really C++?

A common misconception among beginners is that Arduino uses a proprietary language. In reality, the Arduino IDE compiles sketches using standard C++ compilers. However, using C++ on Arduino is not the same as writing desktop C++ applications. The embedded environment imposes strict memory constraints, lacks an underlying operating system, and relies on a customized standard library. This compatibility guide breaks down exactly what works, what fails, and how to adapt modern C++ code for microcontrollers in 2026.

The Compiler Toolchain: AVR vs. ARM vs. Xtensa

When you write C++ on Arduino, the underlying compiler dictates your language feature support. The Arduino ecosystem currently spans three primary architectures, each with distinct C++ dialects and standard library implementations.

Board Family Example Model Architecture Compiler Default C++ Standard SRAM / Flash
Classic AVR Uno R3 (ATmega328P) 8-bit avr-gcc C++14 (via Arduino Core) 2 KB / 32 KB
Renesas ARM Uno R4 Minima 32-bit Cortex-M4 arm-none-eabi-gcc C++17 32 KB / 256 KB
Espressif Nano ESP32 32-bit Xtensa/RISC-V xtensa-esp32-elf-gcc C++20 (Partial) 512 KB / 8 MB

While 32-bit boards like the Uno R4 and Nano ESP32 support modern C++17 and C++20 features out of the box, the classic 8-bit AVR boards rely on an older branch of AVR-GCC. This means template metaprogramming and complex constexpr evaluations may hit compiler memory limits on older 8-bit hardware.

The STL Dilemma: Vectors, Strings, and Maps

The most significant hurdle when porting desktop C++ to Arduino is the Standard Template Library (STL). On a standard PC, you freely use std::vector, std::string, and std::map. On an 8-bit AVR microcontroller with 2KB of SRAM, these containers are dangerous.

Why STL Containers Fail on 8-Bit AVR

  • Heap Fragmentation: std::vector dynamically reallocates memory as it grows. On an ATmega328P, this quickly fragments the tiny 2KB heap, leading to silent memory corruption and random reboots.
  • Flash Overhead: Including <map> or <unordered_map> pulls in thousands of bytes of template instantiation code, easily exhausting the 32KB flash limit before your main logic is even compiled.
  • Missing Implementations: The default avr-libc does not include the C++ STL. Attempting to #include <vector> on a classic Uno R3 will result in a fatal "file not found" compilation error.

The 2026 Solution: Embedded Template Library (ETL)

For modern Arduino development, the industry standard workaround is the Embedded Template Library (ETL). ETL provides deterministic, fixed-capacity alternatives to STL containers that do not allocate dynamic memory.

Pro Tip: Replace std::vector<int> with etl::vector<int, 50>. This allocates exactly 200 bytes (50 ints × 4 bytes) at compile time, completely eliminating heap fragmentation risks while retaining standard C++ iterator syntax.

Exceptions and RTTI: The Hidden Memory Hogs

By default, the Arduino build system disables C++ Exceptions and Run-Time Type Information (RTTI). This is controlled by the -fno-exceptions and -fno-rtti flags in the board's platform.txt file.

The Cost of Enabling Exceptions

If you are porting a C++ library that relies on try/catch blocks, you might be tempted to enable exceptions. However, enabling stack unwinding on an AVR requires the compiler to generate extensive lookup tables. Enabling exceptions typically consumes an additional 12KB to 18KB of flash memory—more than half the available space on an Uno R3.

How to enable them (ARM/ESP32 only):
On 32-bit boards where flash is abundant, you can enable exceptions by modifying your platform.txt or adding a custom build_flags entry in a PlatformIO platformio.ini file:

build_flags = 
    -fexceptions
    -fno-rtti

Note: RTTI (required for dynamic_cast) is rarely needed in embedded systems and should remain disabled to save RAM.

Modern C++ Features That Work Perfectly

Not all modern C++ features are memory hogs. Many C++14, C++17, and C++20 features are purely syntactic sugar or compile-time optimizations that cost zero bytes of runtime SRAM or Flash. According to the C++ Core Guidelines, leveraging these features improves code safety without impacting embedded performance.

  1. constexpr and consteval: Force the compiler to calculate values at compile time. Ideal for generating lookup tables (e.g., sine waves or CRC polynomials) without storing them in flash arrays.
  2. Lambdas: Inline anonymous functions are heavily optimized by GCC. They are perfect for callback functions in interrupt service routines (ISRs) or asynchronous task schedulers.
  3. static_assert: Validate hardware pin configurations and array sizes at compile time, preventing catastrophic runtime memory overwrites.
  4. Structured Bindings (C++17): Unpack structs and pairs cleanly, making sensor data parsing highly readable without adding runtime overhead.

Standard Streams vs. Arduino Serial

Desktop C++ relies heavily on <iostream> and std::cout. The Arduino environment completely lacks standard file descriptors (stdin, stdout, stderr) because there is no operating system to manage them.

Attempting to use std::cout will fail. Instead, you must map standard output to the hardware UART using the Arduino Serial API. If you are porting a large C++ codebase that uses standard logging macros, create a wrapper class:

class ArduinoLogger {
public:
    template<typename T>
    ArduinoLogger& operator<<(const T& msg) {
        Serial.print(msg);
        return *this;
    }
    // Handle std::endl equivalent
    ArduinoLogger& operator<<(std::ostream& (*f)(std::ostream&)) {
        Serial.println();
        return *this;
    }
};
ArduinoLogger cout;

Summary: Best Practices for C++ on Arduino

Writing robust C++ on Arduino requires a shift in mindset from desktop development. Avoid dynamic allocation on 8-bit boards, embrace fixed-capacity containers like ETL, leverage constexpr for compile-time math, and always monitor your SRAM watermarks using the FreeMemory() utility. By understanding the boundaries of the AVR and ARM toolchains, you can write highly optimized, modern C++ code that pushes microcontrollers to their absolute limits.