On 05/02/2010 08:29 AM, Chad Nelson wrote:
On 05/02/2010 03:19 AM, Jeffrey Hellrung wrote: [...]
Regarding COW specifically: I'm guessing COW will be a tough sell,
I keep hearing that, but why? It's an internal detail, one that provides (or at least seems to) a very noticeable speed boost under some circumstances, and is disabled when it can't be safely used. Why would anyone, other than developers doing work on the library (i.e. me), care one way or another that the library uses it?
Because COW is not thread-safe ;) And I'm very curious how this speed "boost" (pun intended?) has come about. As Pavel has pointed out, yes, if you make 10 unmodified copies of a COW object, it's much faster than 10 unmodified copies of a non-COW object. But if I make 10 reference-to-consts of the same object, that's *even faster*. Can you give a "real" example where you'd actually *want* to produce an unmodified copy of an object, rather than just creating a reference-to-const? And doesn't the reference-to-const make your intentions ("Dude, I'm not modifying this thing!") that much clearer? The only example I can think of where COW might come in handy is if you do something like cow* p_x1 = new cow(); cow* p_x2 = new cow(*p_x1); // no deep copy / shared ownership // ... [A] Read from *p_x1, maybe? ... delete p_x1; // *p_x2 now has exclusive ownership I.e., the lifetimes of the handles are not in a subset relation (the lifetime of *p_x1 begins before, but also *ends* before, the lifetime of *p_x2). There's no way to avoid the copy with move semantics without affecting the code at [A] (*p_x1 is probably only guaranteed to be assignable at that point). However, I'd venture to say that 99% of the time, variable lifetimes are in fact subset related, and certainly make the reasoning of code easier. So, bottom line: Give me a real example of an algorithm where COW gives superior performance to move semantics, and I'll buy into the COW implementation. - Jeff