-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Peter Danford Sent: Thursday, June 03, 2004 3:28 PM To: boost@lists.boost.org Subject: Re: [boost] Re: Re: Thread lib (good reason for static)
By introducing the tss into the thread implementation mentioned below, are we gaining functionality so useful it outweighs the benefit realized by having a static option available?
Hi Boosters, While I cannot respond directly to the question posed above, maybe I can make useful observations on the wider issue? I have just been through the process of upgrading a plug-in architecture. This was based fundamentally (no surprise to anyone) on DLLs. A few relevant experiences from this upgrade follow; 1. Exposing STL containers across load modules is problematic Firstly, this was implementation-related; statics in template classes (STL - MSVC6/P.J. Plauger). An STL upgrade fixed that. Secondly, any runtime changes to such a container involve heap operations. If you modify the containers in different load modules then chaos ensues as the template generated code operates on the heap in the calling load module. 2. Complex link-time dependencies forced a backdown on wide use of DLLs as a general library strategy. An explanation is a bit too involved to take up space here. Suffice to say that with the complex combination of parts (application, local static libs, compiler runtime support; CRT, STL, Boost and 3rd party libs), DLLs as a general approach did not appear to be viable. Some effort was expended in this direction as the perceived benefits were very cool. The effort wasnt quite wasted but the goal was not reached. While this experience is not specifically about Boost it did involve templates and DLLs. It also quite possible that the goals of the upgrade were just too ambitious; limitations of DLLs were just not properly appreciated (they are now :-). So far I have sidestepped the issue with Boost by only using those components that come in header(s). Cheers, Scott