From: Wang Weiwei (wwwang_at_[hidden])
Date: 2006-07-16 21:26:13
>Wang Weiwei wrote:
>>> On Sat, 15 Jul 2006 18:12:57 +0100, "John Maddock"
>>> <john_at_[hidden]> 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:
>>> [ 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
>> 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."
> #include <boost/regex.hpp>
> #ifdef _DEBUG
> #define new DEBUG_NEW
>Many headers seem to escape into 'stdafx.h'.
>It looks best to include regex.hpp in 'stdafx.h'.
That really works.