title: Why does iostream take so much flash space on an MCU?
body: <p>I use GCC 5.2.0 to compile code for an EFM32 MCU (based on a Cortex-M core). I notice an awful increase in code size when I want to <code>#include &lt;iostream&gt;</code>.</p>
  
  <p>For example, let's compile the following code for an EFM32WG "Wonder Gecko" chip:</p>
  
  <pre><code>#include "em_device.h"
  #include "em_chip.h"
  #include &lt;iostream&gt;
  
  int main(void)
  {
    CHIP_Init();
  
    while (1) {
    }
  }
  </code></pre>
  
  <p>This code will result in 172048 bytes of code, whereas without <code>#include &lt;iostream&gt;</code> it is only 1440 bytes.</p>
  
  <p>I usually just use <code>cout</code> for debug output (by implementing the <code>_write</code> function for newlib and routing the output to the SWO pin), but it looks like this approach is very wasteful, considering the MCU only has 256k of flash, and just including this header will make the code use up most of it.</p>
  
  <p>So, my question is: <strong>why</strong> is including the iostream header make the compiled code take such an insane amount of flash space? And also, is there a way to fix it?</p>
  
  <p><strong>EDIT:</strong></p>
  
  <p>Both the compiler and linker is <code>arm-none-eabi-g++</code> (version 5.2.0), the C library is the nano C library (I think).</p>
  
  <p>Here are my C++ compiler flags (excluding the include paths):</p>
  
  <pre><code>-g -gdwarf-2 -mcpu=cortex-m4 -mthumb '-DEFM32WG940F256=1' -O0 -Wall -c -fmessage-length=0 -mno-sched-prolog -fno-builtin -ffunction-sections -fdata-sections -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
  </code></pre>
  
  <p>Here are my linker flags:</p>
  
  <pre><code>-g -gdwarf-2 -mcpu=cortex-m4 -mthumb -T "${BuildArtifactFileBaseName}.ld" --specs=nosys.specs -Xlinker --gc-sections -Xlinker -Map="${BuildArtifactFileBaseName}.map" -mfpu=fpv4-sp-d16 -mfloat-abi=softfp --specs=nano.specs
  </code></pre>
  
  <p>I tried both with and without optimalizations, but the resulting code size remains about the same (the optimized size is maybe 1k smaller).</p>
  
  <p><strong>EDIT 2</strong></p>
  
  <p><code>-fno-rtti</code> and <code>-fno-exceptions</code> do not help with the code size either.</p>