Boost::Process doesn't work with #define new (boost 1.69)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost::Process doesn't work with #define new (boost 1.69)

Boost - Users mailing list
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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

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

Boost - Users mailing list
On Mon, Feb 11, 2019 at 10:51 AM Vivek Subramanian via Boost-users <[hidden email]> 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


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

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

Boost - Users mailing list
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.
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

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

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On Mon, Feb 11, 2019 at 10:51 AM Vivek Subramanian via Boost-users
<[hidden email]> wrote:
> So I did
>
> #ifdef new
> #undef new
> #endif

What is this, the way to guarantee that the compiler won't allocate
dynamic memory for the coroutine frame?
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

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

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
Well, okay, but Win32 code doesn #undef new at the start, and Microsoft themselves say to #define new for using CRT!


On Tue, Feb 12, 2019 at 12:27 AM Marshall Clow <[hidden email]> wrote:
On Mon, Feb 11, 2019 at 10:51 AM Vivek Subramanian via Boost-users <[hidden email]> 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


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

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

Boost - Users mailing list
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-using-the-crt-library?view=vs-2017

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.
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users