Re: [Boost-users] std::string corrupt after including boost

Subject: Re: [Boost-users] std::string corrupt after including boost
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-11-01 01:52:37

On Fri, Oct 29, 2010 at 9:56 AM, John Dlugosz <JDlugosz_at_[hidden]> wrote:
>>
>> Indeed, it's likely related to the problems explained here:
>>
>> Allocating and freeing memory across module boundaries
>>
>> http://blogs.msdn.com/oldnewthing/archive/2006/09/15/755966.aspx
>>
>
> I've dealt with that by setting up projects to use the DLL version of the run-time library. Â Even before that was the default in Visual Studio, it has this big advantage. Â It's like virtual inheritance in C++: Â all DLLs that link to the DLL RTL will refer to the _same_ copy of the RTL.
>
> With Visual Studio 2008 (maybe it started earlier, I'm not sure) there is a new wrinkle: Â different DLLs compiled with the same version of the compiler can refer to different patch versions of the RTL. Â So, either make sure all DLLs are compiled with the default options (link to original RTL version regardless of newer ones available) or compile all with _BIND_TO_CURRENT_VCLIBS_VERSION=1 which binds to the latest version available at compile-time, with the same latest one seen at compile-time for each module.
>
> It's crazy really. Â Win32 addressed this issue by having a process global heap. Â If all the copies of the RTL used that, they would interoperate just fine. Â But the start-up code goes out of its way to ignore it and create its own heap instead, so each copy of the RTL is its own memory pool.
>
> The problems reported by the OP have, if I read and remember correctly, with conditional compilation in the standard library headers. Â Specifically, if debug builds are compiled with _HAS_ITERATOR_DEBUGGING=0 then all DLLs must be built that way. Â Since the conditional compilation this triggers is in the STL iterators, than it's only a problem if iterators are involved in the calls or member accesses etc. across the DLL boundaries.
>
> Likewise _SECURE_SCL=0 will change the layout of the STL container classes. Â string and wstring are compatible across, since special support is included to make that polymorphic at run-time and allow those instantiations to live inside the single DLL. Â But other containers will change their size, messing up other structures that contain them, and calls using them will refer to wrong addresses. Â So, if STL is involved, the DLLs must have this option set the same way.
>
> Personally, I solved this with Boost by remaking the Visual Studio project files for the (few) Boost DLLs I needed, and not using Jam at all. Â I specifically recommend using a "property sheet" in Visual Studio to record these build conventions, and refer to the same property sheet in all the projects of your application suite.

I just build boost like this:
  bjam --build-type=complete --toolset=msvc-8.0 --without-mpi
--prefix=R:/SDKs/boost/built_head --build-dir=R:/SDKs/boost/build_head
define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE
define=_CRT_SECURE_NO_WARNINGS define=_SECURE_SCL=0
define=_SCL_SECURE_NO_DEPRECATE define=_HAS_ITERATOR_DEBUGGING=0
install>..\build-HEAD.log 2>&1

Along with the appropriate macros in my own projects, I have no
issues, and in some cases some tremendous speed benefits (iterator
debugging slowed some of my apps down from running in milliseconds to
running in 12 seconds, screw that!).