
2014-06-07 16:08 GMT+02:00 Rob Stewart
On June 7, 2014 8:05:39 AM EDT, Andrzej Krzemienski
wrote: 2014-06-06 3:51 GMT+02:00 Vladimir Batov
: On 06/06/2014 07:21 AM, Andrzej Krzemienski wrote:
I still claim that pimpl::pointer_semantics breaches value semantics expectations in an unprecedented way. Both non-const refs and shared_ptr, and raw pointer and normal value semantic classes have one property in common: Their operator== reflects their *salient attributes*. Sorry for a fancy term. I borrowed it from John Lakos: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2479.pdf,
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/accu...
The point of the Pimpl Idiom is to move what would be private data members out of the header. Any semantic thing you would have done, had the members been declared in the header, should be possible after applying the Pimpl Idiom. If value_semantics precludes proper equality comparisons, that's a major problem. If it doesn't preclude them, but changes the default behavior, relative to non-Pimpl classes, it's unfortunate.
From what I understand the, pimpl::value_semantics part behaves intuitively. It is just the other part of the library:
pimpl::pointer_semantics that has the controversial behaviour, and I wouldn't even call it "pointer semantics", because pointers expose value semantics. Regards, &rzej