Hey Jeff, Just wanted to thank you for the input. I ended up partially relying on VLD. Although it, understandably, detects a number of false positives via static objects that are left for the OS to destroy. Not really an optimal solution, but better than nothing, since I can keep it off until I detect more leaks going off than usual... Regards, Lasse On 12-04-2013 14:27, Jeffrey Lee Hellrung, Jr. wrote:

On Thu, Apr 11, 2013 at 10:00 PM, Lasse Laursen mailto:gazoo@42.dk> wrote:

Hellos,

I recently upgraded to vs2012 and am making liberal use of its leak detection described here:

http://msdn.microsoft.com/en-__us/library/x98tx3cf.aspx http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

However, I'm running into a spot of trouble. I rely on the C++ style new commands to allocate memory and as such, I make use of redefining this call in order to get a specific file and line, at the end of my programs execution, to where I allocated memory which is leaking. It's super effective!

According to the link above, the new command is to be redefined thusly:

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

Looks like a bad idea...

However, boost no likey. I get a syntax error in 'initializer.hpp' at the following line (122) of code:

new(dest) value_T( boost::detail::variant::move(__operand) );

...since it doesn't play well with placement new.

... saying it no longer knows what 'dest' is. A bit puzzling to be honest. I'm no C++ artisan, so I'm a bit stumped as to how I should elegantly avoid this issue. I really don't need boost to use this redefined new, as I'm sure it's as leak proof as can be, but I'm not sure if it's possible to somehow define my way out of that jam? Or perhaps change the definition so that the line no longer results in a syntax error. Any ideas?

Well, if you really wanna do the macro thing, you'd probably have to #undef new prior to including any boost headers, and subsequently redefine it to your debug version afterwards. And...I think using a macro is the only way you'll grab the file and line number (the merits of which I won't discuss here).

HTH,

- Jeff

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hey John, Just wanted to thank you for the input. I ended up partially relying on VLD. Although it, understandably, detects a number of false positives via static objects that are left for the OS to destroy. Not really an optimal solution, but better than nothing, since I can keep it off until I detect more leaks going off than usual... Regards, Lasse On 12-04-2013 17:22, John Maddock wrote:

...

I recently upgraded to vs2012 and am making liberal use of its leak detection described here:

http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

However, I'm running into a spot of trouble. I rely on the C++ style new commands to allocate memory and as such, I make use of redefining this call in order to get a specific file and line, at the end of my programs execution, to where I allocated memory which is leaking. It's super effective!

According to the link above, the new command is to be redefined thusly:

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

Which will break quite a bit of perfectly conforming C++ code :-(

I use Visual Leak Detector: http://vld.codeplex.com/ which offers much better error reporting than MSVC's built in stuff and is still free.

HTH, John.