Re: [boost] Re: Re: Re: Platform Neutrality-withoutreinterpret_cast<>andifdef

From: David Brownstein (David_at_[hidden])
Date: 2002-08-05 16:59:40

Eric,
Please explain which of the communities design principles you believe have been "brutally" ignored? I assume that you have followed the design and implementation of boost::threads since the beginning (with all the attendant discusions), and are hence prepared to provide a detailed analysis that will back up this claim?

David
  ----- Original Message ----- 
  From: Eric Woodruff 
  To: boost_at_[hidden] 
  Sent: Monday, August 05, 2002 2:09 PM
  Subject: [boost] Re: Re: Re: Platform Neutrality-withoutreinterpret_cast<>andifdef

  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.

  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.
    ----- Original Message ----- 
    From: William E. Kempf 
    Newsgroups: gmane.comp.lib.boost.devel
    Sent: Monday, 2002:August:05 4:40 PM
    Subject: Re: Re: Re: Platform Neutrality -withoutreinterpret_cast<>andifdef

    ----- Original Message -----
    From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
    To: <boost_at_[hidden]>
    Sent: Monday, August 05, 2002 3:07 PM
    Subject: [boost] Re: Re: Platform Neutrality -
    withoutreinterpret_cast<>andifdef

    > I can understand the hit taken in the readability of the mutex
    > implementation for "efficiency," but it is unacceptable for thread. I've
    > read boost's biases and the thread implementation is a certain violation
    of
    > the heart of boost's principles.

    Eric, I think you're getting confrontational.  Boost went through formal
    review and no one had the objections to the *implementation* that you do.
    More over, Boost.Threads is hardly the only Boost library that uses
    conditional compilation in this manner.  If you're going to accuse me of
    violating the heart of Boost's principles you'd better back it up with
    citations.

    Truth be told, a pre-review version of the library used the PIMPL idiom for
    the reasons you cited, and it received numerous complaints for having done
    so.  The current usage of conditional compilation is a result of the Boost
    membership requesting this.

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