[Scummvm-devel] The Curious Case of NonCopyable

[Max Horn]

Am 28.04.2009 um 20:37 schrieb Matt:

> Hello,
>
> In doing some cleanups of warnings reported by G++'s -Weffc++ and PC- 
> Lint,
> I came across this kind of warning:
>
> lint-undeserved-173x.cpp:11: warning: 'class PluginManager' has  
> pointer
> data members
> lint-undeserved-173x.cpp:11: warning:   but does not override
> 'PluginManager(const PluginManager&)'
> lint-undeserved-173x.cpp:11: warning:   or 'operator=(const
> PluginManager&)'
>
> PluginManager (indirectly) inherits from NonCopyable, which defines a
> private copy ctor and assignment operator that do not have an
> implementation. If anyone ever tried to use either, they'll get a link
> error. This is the desired effect, and helps avoid a whole host of  
> pointer
> aliasing bugs.

Aye...

> However, the checks in these tools basically say it doesn't count.  
> This is
> because the pointer member is in the subclass, which the NonCopyable
> parent can't possibly know about and therefore handle the copy (deep  
> or
> otherwise).

Frankly I don't quite understand what you are saying here. So, those  
tools say something, fine -- yet I have seen tons of lint tools  
outputting spurious and incorrect warnings, so... What is the actual  
*issue* you perceive here? Can you give a code example that does  
something bad / wrong in an unexpected fashion?

In particular, trying to make a copy of a PluginManager does cause a  
compile time error (and the class is never to be subclassed, being a  
singleton). The only way I know of to defeat the purpose of  
NonCopyable is to make a subclass which provides its own explicit copy  
constructor / assignment operator -- well, if you try hard enough, you  
can always shoot into your own foot ;-).


> Also, the indirect nature of this might be confusing to some
> folks who would add a copy ctor or assignment operator in the  
> subclass.

That seems contrived to me, frankly (see above). Those classes are not  
to subclassed, too. In the end, C++ provides no way to fully protect  
the programmer from these kinds of mistakes.


All in all, I am not convinced there is actually an issue, but then  
again, I am not sure I understood what your point is (it didn't come  
across from what you wrote, at least). So, I'll wait for some more  
explanations from you, resp. an example :-).


Cheers,
Max