[boost] Re: Platform Neutrality - Users choice to pollute theglobalnamespace

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-06 13:57:18

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.

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. 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.

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

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

----- Original Message -----
From: William E. Kempf
Newsgroups: gmane.comp.lib.boost.devel
Sent: Tuesday, 2002:August:06 2:43 PM
Subject: Re: Platform Neutrality - Users choice to pollute
theglobalnamespace

----- Original Message -----
From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
To: "boost" <boost_at_[hidden]>
Sent: Tuesday, August 06, 2002 12:10 PM
Subject: [boost] Platform Neutrality - Users choice to pollute the
globalnamespace

> Here's another option:
>
> As I suggest before, to use a secondary class with the specific
> implementation in it, why not make it a flag that the user can set whether
> to use a "PIMPL" or just a normal instance of it. Some people might rather
> not have <windows.h> or <pthread.h> include in their dependency
hierarchy --
> this is after all, one of the key points of the abstraction.

1) This won't help any with the readability of the code.
2) This will require duplicate code.
3) This will be much harder to maintain.
4) I very specifically do *NOT* include any of the windows headers today.  I
could go the extra mile and not include <pthread.h> as well, but there's not
much of a compelling reason to do so, since that header doesn't define
numerous macros that are likely to conflict with user code.

Bill Kempf
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost