Wang Weiwei wrote:

...

...

On Sat, 15 Jul 2006 18:12:57 +0100, "John Maddock" <john@johnmaddock.co.uk> wrote:

...

Ah, that might do it, it's not a placement new, it's a call to ::operator new. There's no way to suppress macro expansion on a non-function macro either is there? AFAIK, no, but nobody can be sure of any pp statement without talking to Paul Mensonides, first :) You could detect whether "new" remains the same after an attempted expansion or not, though.

Quite depressing, I know. As you'll see, this causes problems to themselves too:

<http://support.microsoft.com/kb/317799/EN-US/>

-- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

Yes, the MS nasty macro definition is the source of problem. The workaround is commenting out the macro as follows:

//#ifdef _DEBUG //#define new DEBUG_NEW //#endif

As indicated in the MS web page, the drawbak of this solution is, as quoted from the page:

"NOTE: This method has the disadvantage of not using features in MFC that help you track memory allocations and leaks."

Doesn't work?:

#include <boost/regex.hpp>

#ifdef _DEBUG #define new DEBUG_NEW #endif

Many headers seem to escape into 'stdafx.h'. It looks best to include regex.hpp in 'stdafx.h'.

-- Shunsuke Sogame

That really works. Thanks, Sogame Max