[property_tree] Copy constructor and assignment operator in xml_writer_settings class

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[property_tree] Copy constructor and assignment operator in xml_writer_settings class

Mateusz Loskot
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.
Perhaps it should be patched?

Quick chat on the #boost IRC channel confirms it could be improved.

I'm looking forward comments.

[1]
https://svn.boost.org/trac/boost/browser/trunk/boost/property_tree/detail/xml_parser_writer_settings.hpp

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

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

Mateusz Loskot
Hi,

Timorously, I'd like to bump my question.

Mat

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.
Perhaps it should be patched?

Quick chat on the #boost IRC channel confirms it could be improved.

I'm looking forward comments.

[1]
https://svn.boost.org/trac/boost/browser/trunk/boost/property_tree/detail/xml_parser_writer_settings.hpp

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Redl
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.

Sebastian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Mateusz Loskot
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".

[1] https://svn.boost.org/trac/boost/browser/trunk/boost/property_tree/detail/xml_parser_writer_settings.hpp?rev=61609#L33

Best regards,
Mateusz
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Redl

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. 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?

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.

Sebastian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Mateusz Loskot
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

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

Dave Abrahams
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Mateusz Loskot
On 18/10/10 15:27, David Abrahams wrote:

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

Yes, it's clear to me.

>>> 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).

Interesting.

> But then you need equality
> and a bunch of other operations to make it meaningful.

I wasn't looking that far.

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

Yes, I forgot and confused CopyConstructible != Assignable

So, xml_writer_settings should be considered as CopyConstructible
having implicitly declared copy constructor, but not Assignable
having implicitly disabled assignment operator.
No explicit motions are required here.

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

Understood. I'm still digesting Stepanov's elements of programming
and finding their applications in practice.

Thanks David!

Sebastian, my apologies for wasting your time.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Mateusz Loskot, http://mateusz.loskot.net