Pourquoi dans "std :: ostream & operator <<" J'ai des fuites de mémoire?

Question

Donc, j'ai un code simple:

main.cpp:

#include "source/core/Vector2D.h" 
int main(int argc, char **argv) 
{ 
    Vector2D vector; 
    return 0; 
} 

Vector2D.h:

#ifndef VECTOR2D_H 
#define VECTOR2D_H 

// Стандартные библиотеки C++ 
#include <cmath> 
#include <ostream> 
class Vector2D 
{ 
    public: 
     Vector2D(); 
     ~Vector2D(); 
     friend std::ostream &operator<<(std::ostream& os, const Vector2D &v); 
    protected: 
     double m_x; 
     double m_y; 
    private: 
}; 
#endif // VECTOR2D_H 

Et Vector2D.cpp

#include "Vector2D.h" 

Vector2D::Vector2D() 
{ 
    m_x = m_y = 0; 
} 

Vector2D::~Vector2D() 
{ 
    //dtor 
} 

std::ostream &operator<<(std::ostream& os, const Vector2D &v) 
{ 
    os<<'{'<<v.m_x<<';'<<v.m_y<<'}'; 
    os.flush(); 
    return os; 
} 

Si je vérifie ce code avec valgrind puis:

valgrind --leak-check=full --show-leak-kinds=all ./Game 
==9886== Memcheck, a memory error detector 
==9886== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. 
==9886== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info 
==9886== Command: ./Game 
==9886== 
==9886== 
==9886== HEAP SUMMARY: 
==9886==  in use at exit: 72,704 bytes in 1 blocks 
==9886== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated 
==9886== 
==9886== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1 
==9886== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==9886== by 0x4EC3EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21) 
==9886== by 0x40104E9: call_init.part.0 (dl-init.c:72) 
==9886== by 0x40105FA: call_init (dl-init.c:30) 
==9886== by 0x40105FA: _dl_init (dl-init.c:120) 
==9886== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so) 
==9886== 
==9886== LEAK SUMMARY: 
==9886== definitely lost: 0 bytes in 0 blocks 
==9886== indirectly lost: 0 bytes in 0 blocks 
==9886==  possibly lost: 0 bytes in 0 blocks 
==9886== still reachable: 72,704 bytes in 1 blocks 
==9886==   suppressed: 0 bytes in 0 blocks 
==9886== 
==9886== For counts of detected and suppressed errors, rerun with: -v 
==9886== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) 

72 kilo-octets de quoi? Quel est le problème avec mon code ou c'est un bug de compilateur ou de bibliothèque std? drapeaux du compilateur:

-std=c++1y -I/usr/include/SDL2 -I"/home/maxim/workspace/Game/cppadv_game" -O0 -g3 -pedantic -pedantic-errors -Wall -Werror -c -fmessage-length=0 

UPD: Il est une bibliothèque std bug:

maxim@MaximPC:echo "#include <iostream> 
> int main() {return 0;} " > prog.cpp 
maxim@MaximPC:~/workspace/hello_world/Debug$ g++ prog.cpp -o prog 
maxim@MaximPC:~/workspace/hello_world/Debug$ valgrind ./prog 
==11116== Memcheck, a memory error detector 
==11116== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. 
==11116== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info 
==11116== Command: ./prog 
==11116== 
==11116== 
==11116== HEAP SUMMARY: 
==11116==  in use at exit: 72,704 bytes in 1 blocks 
==11116== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated 
==11116== 
==11116== LEAK SUMMARY: 
==11116== definitely lost: 0 bytes in 0 blocks 
==11116== indirectly lost: 0 bytes in 0 blocks 
==11116==  possibly lost: 0 bytes in 0 blocks 
==11116== still reachable: 72,704 bytes in 1 blocks 
==11116==   suppressed: 0 bytes in 0 blocks 
==11116== Rerun with --leak-check=full to see details of leaked memory 
==11116== 
==11116== For counts of detected and suppressed errors, rerun with: -v 
==11116== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) 

Answer 1

Il n'y a pas d'erreur ici:

==11116== LEAK SUMMARY: 
==11116== definitely lost: 0 bytes in 0 blocks 
==11116== indirectly lost: 0 bytes in 0 blocks 
==11116==  possibly lost: 0 bytes in 0 blocks 
==11116== still reachable: 72,704 bytes in 1 blocks 

Son vous dire qu'il n'y a pas d'octets perdus, seulement 72K de données accessibles globalement - des choses allouées par la bibliothèque standard et toujours accessibles quand le programme se termine. La bibliothèque standard ne prend pas la peine de supprimer ce contenu, car c'est une perte de temps - la mémoire est récupérée automatiquement lorsque le processus se termine.

En regardant le résumé détaillé, cela semble être la mémoire utilisée pour charger une bibliothèque dynamique au démarrage (probablement le libstC++ bibliothèque)