Does anybody else including <iostream> give them a memory leak?

[MutantJohn]

For some reason, valgrind is giving me a memory leak whenever I include <iostream>.

Consider this program:

#include <iostream>


int main(void)
{
  return 0;
}

Compiled with :

g++ -o leak leak.cpp

Valgrind gives me the following:

valgrind ./leak
==13689== Memcheck, a memory error detector
==13689== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==13689== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==13689== Command: ./leak
==13689== 
==13689== 
==13689== HEAP SUMMARY:
==13689==     in use at exit: 72,704 bytes in 1 blocks
==13689==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==13689== 
==13689== LEAK SUMMARY:
==13689==    definitely lost: 0 bytes in 0 blocks
==13689==    indirectly lost: 0 bytes in 0 blocks
==13689==      possibly lost: 0 bytes in 0 blocks
==13689==    still reachable: 72,704 bytes in 1 blocks
==13689==         suppressed: 0 bytes in 0 blocks
==13689== Rerun with --leak-check=full to see details of leaked memory
==13689== 
==13689== For counts of detected and suppressed errors, rerun with: -v
==13689== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Info:
OS: Ubuntu 14.04
g++: 4.8.4
valgrind: 3.10.1

Edit: I did download gcc 5.1 yesterday though and install so maybe it's actually the 5.1 version of iostream that's giving me this leak. I get it with both versions of the compiler, 4.8.4 and 5.1 and that might be because they're both referencing the same 5.1 <iostream>.

[whiteflags]

Leaks in the still reachable category are just items that were allocated, but not freed before the program terminated. You could argue that these are not true leaks, because if you wanted, you could just free. The other side of the coin is that you want to detect "still reachable" allocations that could grow indefinitely - which I guess the I/O library is not going to do. And at any rate the OS would reclaim any unused items in still reachable blocks.

[MutantJohn]

Leaks in the still reachable category are just items that were allocated, but not freed before the program terminated. You could argue that these are not true leaks, because if you wanted, you could just free. The other side of the coin is that you want to detect "still reachable" allocations that could grow indefinitely - which I guess the I/O library is not going to do. And at any rate the OS would reclaim any unused items in still reachable blocks.

Okay, great!

I was also just curious if other people had noticed the same behavior. I figured C++14 might be worth trying because you can use std::get to access elements of tuples and pairs by type and so I downloaded 5.1 and gave it a shot.