problem with virtual functions and -Weffc++

[Gorlash]

I'm writing my first class that uses virtual functions. Here's my parent function declaration:

//********************************************************************
class graph_object {
private:
// disable copy and assignment operators
// for classes with pointer members
graph_object operator=(const graph_object &src) ;
graph_object(const graph_object&);

// make this field protected, rather than private,
// so derived classes can access it.
protected:
char *title ;

public:
graph_object(char *title) ;
virtual ~graph_object() {} ;
virtual void update_display(HWND hwnd) = 0 ;
virtual bool process_key(unsigned key_id) = 0 ;
} ;

I have many different sub-classes of this virtual parent. They were all building and running fine under MinGW g++ V4.3.3. Then I added -Weffc++, which I've been adding to all my C++ projects, but in this project it's generating some challenges that I don't understand at all; hopefully someone here can clarify what is going on.

I've been disabling the copy and assignment operators for any class which has pointers in it, as I learned on this group in the past. However, I get an error on the assignment operator:

gobjects.h:20: error: invalid abstract return type for member function
'graph_object graph_object::operator=(const graph_object&)'
gobjects.h:8: note: because the following virtual functions are pure within 'graph_object':
gobjects.h:42: note: virtual void graph_object::update_display(HWND__*)
gobjects.h:43: note: virtual bool graph_object::process_key(unsigned int)

I have no clue what this is referring to!! Please comment...

[JLBorges]

We can't return a graph_object by value (abstract); return by reference instead:

// private: graph_object operator=(const graph_object &src) ;
private: graph_object& operator=(const graph_object &src) ;

Or: graph_object& operator=(const graph_object &src) = delete ; // C++11

Or:

#include <boost/utility.hpp>

class graph_object : private boost::noncopyable { 

> I've been disabling the copy and assignment operators for any class which has pointers in it

Consider converting these raw pointers to std::unique_ptr<>
(MoveConstructible and MoveAssignable, but not CopyConstructible or CopyAssignable).
http://en.cppreference.com/w/cpp/memory/unique_ptr

[Gorlash]

Ahhh... you're right, that works, though it's a bit moot in this case, since I'm disabling the operators!!

However, this caused me to go back and look at my other projects, and I realized that what I've been doing in all of my classes is actually using:

my_class operator=(const my_class src) ;
which is clearly wrong now that I think about it, since I certainly know better than to pass an actually struct or object to a function, rather than a pointer...

I wonder if this might even back-fire on me?? Since the operator that I'm disabling here takes an object, not a pointer to an object, the user might actually be able to call the default copy operator with "pointer to object" and receive a "pointer to object", without getting blocked by the preceding declaration. Maybe I'll test that later.

ITM, thanks for the advice, and I'll read further on unique_ptr (which I've never heard of before!)

[JLBorges]

> my_class operator=(const my_class src) ;

The const in a parameter passed by value does not make sense. Remove it.

And, ideally mimic the standard assignment semantics; return a reference to the object on the left of the assignment operator:

my_class& operator=( my_class src ) ; // myclass is not abstract
or: my_class& operator=( const my_class& src ) ;


> the user might actually be able to call the default copy operator with "pointer to object" and receive a "pointer to object"

The default copy of a pointer would be just be a copy the address.

my_class a ;
my_class b(a) ; // creates a new object of type my_class (copy of a)

my_class* c = std::addressof(a) ;
my_class* d(c) ; //  creates a new pointer (copy of c), it too points to object a 

[Gorlash]

hmmm... okay, thanks for these notes. I'll have to think about this a bit before I completely understand it!!