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: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-04-12 01:27:40

On Thu, Apr 11, 2013 at 10:00 PM, Lasse Laursen <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
>

>
> 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