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: http://home.twcny.rr.com/hinnant/cpp_extensions/shared_mutex 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 lost. -Howard