Boost logo

Boost :

From: Bronek Kozicki (brok_at_[hidden])
Date: 2005-11-04 05:06:22


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?

As it currently stands out (without this or similar fix) we are actually
injecting bug into all MSVC projects (not only vc8 - it's only
protection built into vc8 headers that exposed the problem) that happen
to #include wrap_python.hpp . I think this is showstopper for 1.33.1,
even though regression tests currently are all green for other versions
of MSVC.

B.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk