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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
