On Tue, May 15, 2012 at 9:07 PM, Christian Henning
<chhenning@gmail.com> wrote:
Hi Will, thanks for your quick answer.
> This object, my_path, has not yet gone out of scope. Why would you expect
> its memory to have been reclaimed in the line that follows?
True. Here is the updated code:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#define BOOST_FILESYSTEM_VERSION 3
#include <boost/filesystem/convenience.hpp>
namespace fs = boost::filesystem;
int main(int argc, char* argv[])
{
{
fs::path my_path( "C:/bla.dat" );
}
_CrtDumpMemoryLeaks();
return 0;
}
-- output:
'test.exe': Loaded
'C:\gil_contributions\solutions\vc10\test\x64\Debug\test.exe', Symbols
loaded.
'test.exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or
open the PDB file
'test.exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or
open the PDB file
'test.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find
or open the PDB file
'test.exe': Loaded 'C:\Windows\System32\msvcr100d.dll', Symbols loaded.
'test.exe': Loaded 'C:\Windows\System32\msvcp100d.dll', Symbols loaded.
Detected memory leaks!
Dumping objects ->
{145} normal block at 0x00000000003F7EE0, 24 bytes long.
Data: < ? > 88 09 F6 3F 01 00 00 00 01 00 00 00 00 00 00 00
{142} normal block at 0x00000000003F7D60, 16 bytes long.
Data: <@ ? > 40 8B F6 3F 01 00 00 00 00 00 00 00 00 00 00 00
{141} normal block at 0x00000000003F7CE0, 16 bytes long.
Data: < ? > 10 8B F6 3F 01 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
The program '[3628] test.exe: Native' has exited with code 0 (0x0).
It's getting late here. Maybe I don't see the forest because there are tree? ;-)
I don't know about forests and trees, but I do know that your test could easily be hiding instances of one-time allocation, which you don't see because you are also only allocating one boost::filesystem::path. I would recommend allocating and deleting 50 or 100 ro 100,000 path objects and seeing if the "leaks" are actually growing.
From my own experience, we use boost::filesystem *extensively* in a large cross-platform project, and we perform rather exhaustive memory and static checking of our binaries on multiple platforms. We have seen no leaks from boost::filesystem.
Cheers,
Will