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

Subject: Re: [Boost-users] std::string corrupt after including boost
From: John Dlugosz (JDlugosz_at_[hidden])
Date: 2010-10-29 11:56:01

> 
> 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.

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.