Boost logo

Boost :

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-08 12:18:50

Do you misunderstand "duality", or "functionality"? If boost has source
dependencies, the the threading models of its dependencies are also
available to the user, providing a duality in multithreading support.

Dualities introduce complexities. For the same reason I wont use the better
ZThreads library because boost provides threading, it should not expose the
functionality that it depends on. There is no reason to have overlapping
instances of the same abstraction level.

Somewhere the line has to be drawn in the sand and a layer has to be created
that is completely platform agnostic. From that point on, all the layers
above it will be so implicitly. Everyone will agree that this is best done
at boosts level because it has the operating system accessibility to be

boost is a ubiquitous, dependable framework -- as such it inherits ethical

----- Original Message -----
From: Braden McDaniel
Newsgroups: gmane.comp.lib.boost.devel
Sent: Thursday, 2002:August:08 11:34 AM
Subject: Re: Pure Abstraction Layer

On Wed, 07 Aug 2002 20:42:32 -0400, Eric Woodruff wrote:

> A boost as you describe it turns into a big pile of standardized
> convenience/code reuse instead of a cohesive framework that hides the
> irrelevant implementation details into a binary package.

Because... ???

And note that I did not describe Boost. I simply stated some perceived
flaws in your argument; perceptions which, I note, you've made no attempt
to address. I can find only unsubstantiated assertions in your posting.

> boost needs standardization and needs to be the ultimate definative
> framework. It would be a tragedy to introduce another duality of
> funtionality.

What is your basis for supposing that "duality of functionality" will be
introduced? Where in Boost have you encountered problems with platform
parity, and how exactly would your proposal diminish their occurrence?


Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at