John Maddock wrote on Tue, 2 Aug 2011 12:14:53 +0100

There are a number of issues here:

1) Your call to u_cleanup() occurs while a u32regex object is still in existence, so any ICU data being cached is actually still being used at that point.

I couldn't get u_cleanup() to work anywhere - ie BOOST_AUTO_TEST_CASE( u32_regex ) { { boost::u32regex re( boost::make_u32regex("\\d{3}")); } u_cleanup(); } Or having u_cleanup() in a fixture teardown (which is how it was in the original code) doesn't seem to make any difference

2) Boost.Regex does cache some internal data for improved performance - this is relatively small and gets cleared after main() exits. 3) Point (2) means that a call to _CrtDumpMemoryLeaks() before main exits will report leaks, where as using something like:

struct cleanup { ~cleanup() { _CrtDumpMemoryLeaks(); } };

cleanup c;

The boost unit test framework does appear to do the memory dump in a destructor of a static object - I guess whether the regex library statics are destructed first depends on the order of loading - not sure if there is any easy way of ensuring that the unit test framework is destructed last (perhaps if I link to UTF as a static library?).

4) Other leak detectors such as valgrind and VLD report no errors (and give much more useful reports than the brain-dead MS ones IMO).

HTH, John.

:-) yes I agree - my current solution is --detect_memory_leaks=0 when running the unit tests - which at least stops the report. I was hoping that this was a reasonably common issue and there was some clean up function (like u_cleanup()) specifically for the regex library but if not can live with switching off memory loss detection. Thanks a lot for the help here though - it is much appreciated. Alex