Re: [boost] Re: Platform Neutrality - Users choice to pollutetheglobalnamespace

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-06 16:55:53

----- Original Message -----
From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, August 06, 2002 1:57 PM
Subject: [boost] Re: Platform Neutrality - Users choice to
pollutetheglobalnamespace

> Half of your arguments are subjective.
>
> The only duplication is the constructor which has one version for each
> setting. I think you are failing to recognize that the code is already
> duplicated but just _feels_ like one cohesive implementation that
magically
> works on all platforms. It would be far superior and far easier to
maintain
> as separated implementations that can each do as they please, because each
> platform has their own quirks.

The duplication is in the PIMPL and non-PIMPL implementations, not in
duplication between platforms (which isn't really duplication).

> There is a very compelling reason to not include any pthreads or any other
> headers. If anyone would like to write even the most minimalist
> platform-neutral application using boost and multithreading, they should
be
> able to get a precompiled boost library and link it in with their project
> without any other header dependencies.

Precompile the boost headers now and you have the same performance as you
would if the headers didn't include <pthread.h>.  However, now I understand
what your objection is.  Your objection is to the added compilation time
added here.  As just pointed out, if you use precompiled headers this is a
nearly non-issue, and last I heard bench marks on various
compilers/platforms showed a nearly non-existent compile time benefit with
out precompiled headers.  I'm sorry but an optimization for compile time
doesn't seem to weigh heavier then an optimization for runtime.  The
readability argument was more compelling.

> One should not require pthreads or
> win32sdk installed on their system if they have a statically build STLport
> and boost. The idea is to address the impotency of the standard library
> itself, by providing something that is autonomous and complete.

The pthreads and Win32 SDK libraries are required, regardless.  All that's
not necessarily required is the headers, but are there really any platforms
where the headers aren't already installed when the compilers are?  I don't
think this argument is very compelling either.

> Every time an abstraction layer is made, it helps remove more and more
> dependencies from a project, only adding more simplicity and
> maintainability.

And more overhead.  Some times that's acceptable, and some times it's not.
My users spoke out loudly and told me it wasn't acceptable in this case.

> I think the majority of users would not want to enable
> #BOOST_POLLUTE_HEADER_AND_NAME_SPACE

Actually, they have already said they prefer this.

Bill Kempf