RE: [boost] Re: Re: Thread lib (good reason for static)

From: scott (scottw_at_[hidden])
Date: 2004-06-03 01:02:41

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Peter Danford
> Sent: Thursday, June 03, 2004 3:28 PM
> To: boost_at_[hidden]
> 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