Gennadiy, thanks for the quick reply.
I've followed your advice but with little luck :( I have a very simple test project which is not still giving me the same old output
my std_afx.h (precompiled headers are turned off)
// -----------------------------------------------------------------------------------------------------------
#pragma once
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
// #ifdef _DEBUG
// #include <new>
// #define BOOST_TEST_DEBUG_NEW new( _CLIENT_BLOCK, __FILE__, __LINE__)
// #define new BOOST_TEST_DEBUG_NEW
// #else
// #define BOOST_TEST_DEBUG_NEW
// #endif
#define BOOST_TEST_MAIN
#include <boost/test/unit_test.hpp>
#include <boost/test/floating_point_comparison.hpp>
#include <boost/filesystem.hpp>
// Windows Header Files:
#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers
#include <windows.h>
// -----------------------------------------------------------------------------------------------------------
my test cpp file
// -----------------------------------------------------------------------------------------------------------
#include "std_afx.h"
#include <iostream>
BOOST_AUTO_TEST_CASE( SimpleTestCase )
{
int i = 9;
i++;
int * j = new int[101];
}
// -----------------------------------------------------------------------------------------------------------
and this generates the following output when i run the executable...
================================================
Running 1 test case...
*** No errors detected
Detected memory leaks!
Dumping objects ->
{203} normal block at 0x00368D40, 404 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{164} normal block at 0x00368158, 1280 bytes long.
Data: <x 6 lationStatis> 78 83 36 00 6C 61 74 69 6F 6E 53 74 61 74 69 73
Object dump complete.
================================================
As you can see the test case introduces an easy to spot memory leak of 101 integers (at 4 bytes a pop = 404 bytes). I've done this with your debug block uncommented and the output is exactly the same... One thing I did have to do to get that block to compile was add the #include <new>, if that wasn't there I got an error from stlport stating that
c:\program files\stlport-5.1.4\stlport\stl\_new.h(47) : fatal error C1189: #error : Cannot include native new header as new is a macro.--
I think the problem is that even though I've compiled stlport with settings telling it to use regular old new/delete and not it's own super-duper new/delete, that it is still using it's own internal versions of 'regular' new and delete... I'll try fiddling with some options in stlport unless you can think of any other reason it would continue to have this behaviour?
Jamie Cook
Research Engineer
………………………………………..…………………
Veitch Lister Consulting Pty Ltd.
Ground Floor, 80 Jephson St,
PO Box 1054,
Toowong, QLD 4066
AUSTRALIA
Ph: +61 7 3870 4888
Fax: +61 7 3870 4446
Email: jamie.cook@veitchlister.com.au
Web: www.veitchlister.com.au
………………………………………..…………………