|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-11-10 14:56:31
"Bronek Kozicki" <brok_at_[hidden]> writes:
> David Abrahams <dave_at_[hidden]> wrote:
>> Do you understand what _CRT_NOFORCE_MANIFEST really does?
>
> No :-( I see this has been raised already on boost-testing
> http://lists.boost.org/boost-testing/2005/08/1920.php
>
> As it turned out in discussion with Martyn Lovell, mixing C headers with
> _DEBUG and without this symbol *is* a bug, at least in Visual C++, and
> this is exactly what we are doing in wrap_python.hpp . We have a block
> of code where we #undef _DEBUG, then #include Python headers (which in
> turn #include some C headers) and several C headers too, and then we
> #define _DEBUG back. Any following #include of C header will trigger the
> error in vc8, and is a (silent one!) source of problems in previous
> versions of MSVC. What I think we could do is to #include all required C
> headers *before* #undef _DEBUG, and depend on their own inclusion guards
> (or #pragma once) to prevent them being parsed in the following part of
> the code where _DEBUG is #undef-ed. This means modyfing part of
> wrap_python.hpp to something like (I will test it right away):
>
> #ifdef _DEBUG
> # ifndef BOOST_DEBUG_PYTHON
> # ifdef _MSC_VER
> # include <io.h>
> # include <stdio.h>
> # include <limits.h>
> # include <float.h>
> # include <basetsd.h>
^^^^^^^^^
> # include <string.h>
> # include <errno.h>
> # include <stdlib.h>
> # include <unistd.h>
> # include <stddef.h>
> # include <assert.h> // possibly more headers, to be verified
> # endif
> # undef _DEBUG // Don't let Python force the debug library
> # define DEBUG_UNDEFINED_FROM_WRAP_PYTHON_H
> # endif
> #endif
> // No changes below this line
>
> Dave, what do you think?
Unfortunately the line above is causing this to break with Visual
Studio 8 Express edition. That header doesn't exist after installing
the Core Windows part of the PSDK.
How did you come up with this list?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk