At Mon, 18 Oct 2010 15:02:39 +0100, Mateusz Loskot wrote:
Looking at the current definition [1], I'm not convinced. According to C++(n3092)/12.8/25, assignment operator for this class is defined as deleted due to "non-static data members of const non-class type".
I have no idea what your point is.
My point is that the class definition suggests its copying might not be kosher. It is valid to copy-construct it but not assign.
That's because it has members that are, um, const. Assignment is a mutating operation. Construction is not.
Do you want me to prevent copy construction too, just because copy assignment is not possible? Or do you want me to make the members non-const so that copy assignment is possible?
In my opinion, copy constructor and assignment operator walk together to make a type fully copyable.
The proper term here is "regular," I think (see http://www.stepanovpapers.com/DeSt98.pdf). But then you need equality and a bunch of other operations to make it meaningful.
Thus, IMO, either the definition should change or both copy operations disabled.
I disagree. We have movable but noncopyable types. There's nothing wrong in principle with copyable but not-assignable types.
If the former, why? If the latter, I suppose I could do that. I'm not the one who made the members const in the first place.
I would suggest to either disable both copy operations (does it make sense to have copy ctor without assignment operator?) or change the definition.
I'd also like to point that I have asked generally: What is recommended or required policy regarding copy operations, it is copy ctor and assignment operator. So, I have asked for comments and discussions too, as my understanding of this matter may be incorrect.
There's no required policy. As for recommendations, I say strive for regularity, but sometimes it's just not appropriate. -- Dave Abrahams BoostPro Computing http://www.boostpro.com