RE: [boost] Re: Re: Re: PlatformNeutrality-withoutreinterpret_cas t<>andifdef

From: Darryl Green (green_at_[hidden])
Date: 2002-08-05 21:40:15

Eric,
In among the boost "principles" is one of producing candidates for inclusion
in a future c++ standard library. The important things in that context (I
would think - there are others on this list with a bit more knowledge of the
issues here than me) are the interface (which is what gets standardised) and
some evidence that it is implementable and useable on a wide variety of
platforms. I think the boost threads library does a fine job in that
context. For many threading lib users (and certainly this one) the issues
are implementation correctness,  interface design and performance in that
order (elegance of implementation doesn't rate at all). One would think it
likely that library/compiler/platform vendors (or users) would modify the
implementation to optimise performance (certainly not to optimise
readeability). Of course, that doesn't preclude having a very clear portable
implementation, but I don't really see that the relatively simple thread
impl. is really at the heart of the issue in terms of implementation
readability. Take a look at win32 cond. vars. implementation for example.
Personally, if I was looking to do a port, I'd run it through the
preprocessor with posix selected as the platform and take it from there,
hoping despearately that the target wasn't as ugly as win32... In that
respect a scheme which maintained implementation for different platforms in
different files would be good - but I think this has to be done in a way
which has no runtime penalty.

That said, I was/am interested in higher-level concepts implemented using
boost threads - I see your proposed async function as something that is
worth looking at and seeing where it (or features of it) fits in a toolkit
of thread-related libs. I don't see how it can be considered as a
replacement foundation - it looks to me more like a threadpool variant? I'd
be happy to be shown otherwise, but I don't see how attacking an unimportant
aspect of the current foundation component (ie boost::thread) helps your
argument.

> -----Original Message-----
> From: Eric Woodruff [mailto:Eric.Woodruff_at_[hidden]]
> Sent: Tuesday, 6 August 2002 8:22 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Re: Re:
> PlatformNeutrality-withoutreinterpret_cast<>andifdef
> 
> 
> I'm sure you recognize that a fork of boost would be next to 
> impossible to
> maintain, aside from inconvenient. It would also be void of the
> ubiquitousness currently held by boost.
> 

snip..

> >"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
> >news:0a7e01c23cc4$5e5d61f0$1800000a_at_soy...
> >
> > Please explain how boost users are supposed to maintain a level of
> > confidence in the safety of this foundation that is aimed 
> at addressing
> > the impotence of C++ itself, by providing things that were 
> left out of the
> > standard, when the communities own design philosophies are brutally
> > ignored by its own members.

snip...
 
> > Boost doesn't stand to make any profit, so then why doesn't it stand
> > on it's principles above the alternatives? It seems that 
> upon examination,
> > boost is going the way of all other open projects that 
> exist. This is
> > leading me to believe that inspecting of OpenSceneGraph, which also
> > provides an image of holding high-standards, will prove the same.

Regards
Darryl Green.