|
Boost : |
Subject: Re: [boost] [property_tree] Copy constructor and assignment operator in xml_writer_settings class
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-10-18 10:02:39
On 18/10/10 14:50, Sebastian Redl wrote:
> On 18.10.2010, at 14:22, mloskot wrote:
>> Sebastian Redl wrote:
>>>
>>> On 18.10.2010 12:22, mloskot wrote:
>>>> mloskot wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> What is recommended or required policy regarding copy
>>>>> operations for types which consist of const data members,
>>>>> within Boost?
>>>>>
>>>>> I'm having problem with understanding why the
>>>>> xml_writer_settings class do not have the copying operations
>>>>> disabled.
>>>
>>> Why would it? There's nothing semantically wrong with copying a
>>> settings object. It's just not very useful.
>>>
>>
>> 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.
> 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. Thus, IMO, either the
definition should change or both copy operations disabled.
> 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.
Best regards,
-- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk