Visual Memory Leak filtrowanie

Witam, używająć visual memory leak mam problem z obiektem globalnym.
Króciutki opis.

W pliku** stdafx.h **mam na początku:

#ifdef _DEBUG
  #define _CRTDBG_MAP_ALLOC
  #define _CRTDBG_MAP_ALLOC_NEW
  #include <stdlib.h>
  #include <crtdbg.h>

   #ifndef DBG_NEW
      #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
      #define new DBG_NEW
   #endif

Tworzę nagłówek Plik_z_obiektem_globalnym.h
, który będzie zawierał parametry, do których muszą mieć dostęp wszystkie funkcje w różnych plikach cpp:

Plik_z_obiektem_globalnym.h

class Parametry
{

     public:
       int         Wyskosc;
       int         Dlugosc;
       std::string Nazwa

     Parametry(): Nazwa("kwadrat"), Wyskosc(5), Dlugosc(5){}
     ~Parametry() { Nazwa = " "; Wyskosc = 0; Dlugosc = 0;}
   

};

main.cpp

#include"Plik_z_obiektem_globalnym.h"

Parametry P_1; // To jest obiekt globalny

int _tmain(int argc, _TCHAR* argv[])

{
      
     int * P;   // tu będzie wyciek 
     _CrtDumpMemoryLeaks();

     return 0;


}

Prawidłowo daje info o memory leak dla stworzonego wycieku ale również również wywala w crtdbg.h :

//Detected memory leaks!
Dumping objects ->

**// Info 1 - OK
c:\users... \projects\test\ ...\main\main.cpp(53) : {181} client block at 0x00154CF8, subtype 0, 4 bytes long.
Data: < > 00 00 00 00 **

// Info 2 - niechciane ( przydałby sie jakiś filtr, który by blokował wyświetlanie tego typu)
c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdbg.h(1115) : {177} normal block at 0x002F77A0, 8 bytes long.
Data: < > 14 F4 D1 00 00 00 00 00
Object dump complete.

Dlaczego tak jest, wiem z:
https://msdn.microsoft.com/en-us/library/8bsz08tx%28v=vs.80%29.aspx

Pytanie - czy jest jakiś mechanizm filtrujący, który by wyeliminował zgłoszenia dla składowych typu std::string.
Próbowałem z _CrtMemCheckpoint(...) ale i tak wyrzuca info o wycieku dla typu std::string

Skoro nie ma tu żadnej alokacji dynamicznej ( oprócz std::string ) to skąd ma się pojawić wyciek?

Grochówka napisał(a):

Skoro nie ma tu żadnej alokacji dynamicznej ( oprócz std::string ) to skąd ma się pojawić wyciek?

Memory leak zgłasza dla składowej std::string błąd, bo dla STL nie powinien to być zwykły blok danych - wyjaśnia to załączony wcześniej link.
Co do alokacji dla int * P, sorry , powinno być tak:

 int  *  P = new int (0); // tu będzie wyciek 

Jednak mnie interesuje, jak to ominąć, bo w przypadku umieszczenia w klasie Parametry większej ilości składowych typu std::string , a już nie mówiąc o kontenerach, zaśmieca to wynik z visual memory leak.