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