Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-08-22 14:13:24

On Aug 22, 2007, at 12:49 PM, Peter Dimov wrote:

> Howard Hinnant wrote:
>> Vendor C, with the best of intentions, decides that the release build
>> of the std::lib should contain this checking (std::lib vendors
>> including debug checks in release builds should sound familiar to
>> many
>> of you). Now we have goal #3, but have lost goal #1, and there is no
>> wrapper we can use to get it back.
>> How do we prevent, or at least discourage, Vendor C from taking this
>> path?
> Shouldn't Vendor C be allowed this freedom? If its customers prefer
> paying
> the price of a pointer in exchange for the ever-present checks, why
> should
> the vendor be prevented from delivering the product they want? We can
> explain the rationale for the design and our suggested
> implementation in
> non-normative notes and let the vendors make the informed decision.

Today I don't use list::size() in portable code. Why? Because we
gave the vendor too much freedom.

Being a vendor myself, I appreciate vendor freedom. But I try to
recognize where the line is between vendor freedom, and the client's
ability to use the library.

If it comes to pass that std::condition<std::mutex> (or some unchecked
variant) sometimes has a size penalty over the native condition
variable, I will write shared_mutex/upgrade_mutex in terms of
pthread_cond_t and pthread_mutex_t instead of the code shown here:

class shared_mutex
     typedef mutex mutex_t;
     typedef condition<unchecked<mutex_t>> cond_t;

     mutex_t mut_;
     cond_t gate1_;
     cond_t gate2_;
     unsigned state_;

I've already done it (just to explore the consequences). It isn't
pretty. But clients of shared_mutex don't care how messy it is to
implement. Only I, the maintainer of that code care. And the
client's concerns trump my own.

When we get to the point that I won't eat my own dog food, goal #1 is


Boost list run by bdawes at, gregod at, cpdaniel at, john at