|
Boost : |
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:
>>>
>>> <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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk