Subject: Re: [boost] [property_tree] Copy constructor and assignment operator in xml_writer_settings class
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-18 10:27:15
At Mon, 18 Oct 2010 15:02:39 +0100,
Mateusz Loskot wrote:
> >> Looking at the current definition , 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
> 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