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.