RE: [boost] Critique of Boost.Threads

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-05-05 14:00:43

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Aaron W. LaFramboise
> 
> Of Aaron W. LaFramboise Wrote:
> 
> 
> I've been thinking about Dave Abraham's suggestion
> <http://lists.boost.org/boost/2005/03/21839.php> that theres no reason
> to provide a special protection mechanism for these inner handles.
The
> feeling I get from many here is that you should be able to hit a red
> button, such as including a special implementation header, and you're
> back in shoot-yourself-in-the-foot land, with the confidence that "the
> programmer knows what he's doing."
> 
> I've decided that this is not compelling for me.  We always know what
> we're doing--we're superheroes, we're C++ programmers.  Yet C++ is
> partly about letting us define a set of rules for ourselves, to catch
> our mistakes, and keep us honest.  I think the ability to hit this red
> button and suddenly have full license to blow away a class's
invariants
> without any of the traditional protection mechanisms is downright
> barbaric.
> 
> I think there *is* something special about inheritance.  The
"protected"
> keyword gets wonderful milage in other application domains, and I have
> no idea why system abstractions need to be any different, such that
for
> system dependence, its perfectly acceptable to revert to
> pre-Dijkstraesque programming practices.  Certainly noone would
tolerate
> this additude with other well-defined standard libraries: no matter
how
> much you beg, you just aren't going to get anyone to give you a
pointer
> to std::list's linked list head.
[Brian Braatz Writes:] 

Weighing in. I am IN agreement with DaveA in the following
"> David Abrahams wrote: 
> 
>> I have always thought that concrete implementations of portable 
>> libraries should supply users a way to get at the OS-specific data so

>> they can use platform-specific facilities on them if neccessary. 
>"
        One of the problems of standardization of interface is that it
HAS TO BE expandable and allow for future work to be piled on top of it.

        In this case the best analogy I can provide is Microsoft
Foundation Classes. Yes, yes, YES. I know it is evil in it's design. But
one thing they was make it EASY for you to use "their" abstractions, but
at the same time, allow for the programmer to decide they need to use a
special API call.

        MFC is evil in many ways, but it has lasted a VERY long time and
there are many applications written with it. I personally believe this
is largely due to the notion that they ALLOW me to get to the underlying
handle. This way, when the OS gets the ability to allow me to BLT
semi-transparent gradient images, I can USE this in MFC, even though
they never designed this model into it.
        While It is easy to argue MFC is mentally deficient in its
design, I believe this one trait has given it utility and longevity.

        With THREADING-
                I believe the following: Moore's law is dead. Multi-core
is where the HW folks are headed. 
        
        The OS vendors, will naturally begin to add more API functions
giving me more bells and whistles to play with in the threading world.
Without access to the underlying handle, a threading library will not be
quite as useful in "the real world" where I MIGHT need to take the
plunge and hook up to some OS specific (or HW specific) concept.

        We must think about threading (and many other types of standard
interfaces) as the FOUNDATION of further thinking. NOT the "final"
design in the domain.

:)