Re: [Boost-users] Boost::Process doesn't work with #define new (boost 1.69)

Subject: Re: [Boost-users] Boost::Process doesn't work with #define new (boost 1.69)
From: Gavin Lambert (boost_at_[hidden])
Date: 2019-02-11 23:16:13

On 12/02/2019 07:57, Marshall Clow wrote:
> On Mon, Feb 11, 2019 at 10:51 AM Vivek Subramanian wrote:
> 
>     Hello,
>      Â  Â  Â  Â  Â  Â  Â  I did #define new for debugging memory leaks, and I
>     get this error:
> 
> 
> Sigh. I would have hoped that your compiler would have rejected the code 
> out of hand.
> 
> [macro.names]/2:
> A translation unit shall not #define or #undef names lexically identical 
> to keywords, to the identifiers listed in Table 4, to the 
> attribute-tokens described in 9.11, or to the identifiers expects or 
> ensures, except that the names likely and unlikely may be defined as 
> function-like macros (14.3).
> 
> 'new' is a keyword listed in Table 4.

"#define new DEBUG_NEW" is one of the code patterns used with the 
built-in MSVC debug CRT or MFC, used to provide source line information 
to the memory leak detection and reporting.  So it should always be 
"safe" with that compiler and platform. 
(https://msdn.microsoft.com/en-us/library/tz7sxz99.aspx)

Having said that, very little in the STL or other libraries will compile 
correctly with it defined (due mostly to placement new, since all it 
does is to replace argless-new with new-with-args, and the preprocessor 
can't distinguish this from placement-new).

So if you use this, a standard rule is to always place it only after all 
#includes, and to avoid using "new" in any application header files.

Even so, in modern C++ it's fairly useless since using bare "new" is 
discouraged (in favour of make_unique/make_shared/etc).  You're better 
off using self-decorating leak detectors such as valgrind and ASan instead.