Re: [Boost-users] Redefining new, to detect memory leaks, causes issues in boost

Subject: Re: [Boost-users] Redefining new, to detect memory leaks, causes issues in boost
From: Lasse Laursen (gazoo_at_[hidden])
Date: 2013-05-10 03:22:14

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 <gazoo_at_[hidden]
> <mailto:gazoo_at_[hidden]>> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>