Re: [boost] [property_tree] Copy constructor and assignment operator in xml_writer_settings class

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 [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