Re: [SOLVED] Re: Question about operator = overloaded in reportdesign module

On Sun, Dec 30, 2012 at 09:58:30PM +0100, Julien Nabet wrote:
> On 30/12/2012 21:48, Markus Mohrhard wrote:

> > > Cppcheck reported this:
> > > [reportdesign/source/filter/xml/xmlComponent.hxx:37]: (style)
> > > 'OXMLComponent::operator=' should return 'OXMLComponent&'.
> > > [reportdesign/source/filter/xml/xmlFunction.hxx:41]: (style)
> > > 'OXMLFunction::operator=' should return 'OXMLFunction&'.
> > > [reportdesign/source/filter/xml/xmlGroup.hxx:38]: (style)
> > > 'OXMLGroup::operator=' should return 'OXMLGroup&'.
> > > [reportdesign/source/filter/xml/xmlCell.hxx:41]: (style)
> > > 'OXMLCell::operator=' should return 'OXMLCell&'.

> > > By trying to fix these, I noticed that none of them was implemented. So can
> > > they just be removed, is it another C++ "trick", or something obvious I
> > > missed?

> > You can't remove them. They are declared there to prevent the default
> > operator= and copy c'tor. If you don't declare them private and leave
> > out the implementation the compiler will generate a default operator=
> > (the same is true for the copy c'tor).

> I didn't think that one's want prevent default behaviour without
> overloading

The intent is to *forbid* copying of objects of this type. The
canonical example is a smart pointer that deletes what it points
to when it goes out of scope (when it is destructed). This is a kind
of primitive garbage collector / automatic memory management, that
does not require any collaboration from the managed object (the
pointer pointed to), as opposed to reference counting (which needs the
object to have an integer member for the reference count and a mutex
member to handle changing / reading the reference count).

C++11 has a specific syntax to achieve mostly the same effect more
cleanly:

  OXMLCell& operator =(const OXMLCell&) = delete;

That's slightly better since it tells the compiler that this class
should have *no* assignment operator. So any code that tries to use it
will have an error message "no such operator".

The "private + unimplemented" trick tells the compiler the operator
exists, but only the class itself is allowed to use it.

So, if some non-member function code tries to use the operator, it
will get an error message like "this operator is private", which is
nearly as good as "this operator does not exist"... if the user knows
of this trick, but is arguably less clear.

If a member class function tries to use that operator, the compiler
will accept it, and produce no error. The error will only come at the
linker stage, something like "undefined reference to operator=". Which
could be caused by a forgotten .o in the linker command line rather
than by design, so is a rather poor error message for this situation.

(We cannot yet use C++11 in LibreOffice because not all platforms we
 want to support have good (any?) support for C++11)


-- 
Lionel