Boost::Process doesn't work with #define new (boost 1.69)
Hello, I did #define new for debugging memory leaks, and I get this error: "no instance of boost::process::detail::windows::windows_file_codecv operator new matches arguement list" in file boost\process\local.hpp So I did #ifdef new #undef new #endif right before it and it works fine. Hope that this could be of use to someone! Thanks and Regards, Vivek S
On Mon, Feb 11, 2019 at 10:51 AM Vivek Subramanian via Boost-users < boost-users@lists.boost.org> 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. -- Marshall
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.
Well, okay, but Win32 code doesn #undef new at the start, and Microsoft themselves say to #define new for using CRT! https://docs.microsoft.com/en-us/visualstudio/debugger/finding-memory-leaks-... On Tue, Feb 12, 2019 at 12:27 AM Marshall Clow <mclow.lists@gmail.com> wrote:
On Mon, Feb 11, 2019 at 10:51 AM Vivek Subramanian via Boost-users < boost-users@lists.boost.org> 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.
-- Marshall
On 12/02/2019 17:52, Vivek Subramanian wrote:
Well, okay, but Win32 code doesn #undef new at the start, and Microsoft themselves say to #define new for using CRT!
https://docs.microsoft.com/en-us/visualstudio/debugger/finding-memory-leaks-...
Actually, no, they don't -- at least not on that page. (In fact it specifically un-recommends that.) The technique shown there is to define a DBG_NEW macro. You then replace "new" with "DBG_NEW" whenever it appears in your application code. Hopefully this included the source of the leak. (You're doing this manually or via find/replace, not by #define new DBG_NEW.) It is true that in the past (and with MFC) they did recommend redefining new, but that has caveats. To minimise problems you were always supposed to do it only after all #includes, as I said in my other reply.
participants (4)
-
Gavin Lambert -
Marshall Clow -
Vinnie Falco -
Vivek Subramanian