[cfe-dev] Why does clang-tidy recommend deleted member functions should be public?

[Martin J. O'Riordan via cfe-dev]

Long before ‘deleted’ was added to the C++ language, reserving implicitly defined members as ‘private’ members was a very common pattern.  Indeed, I can find many examples where I (and others) routinely used this pattern.  For example, in from code I wrote in 1994 I have the following example (which I still use today -- if it ain’t broke don’t fix it):

 

class MemoryPool {

...

private: // Interface:  remove copying and address-of from the interface

  MemoryPool ( const MemoryPool& );

   MemoryPool& operator = ( const MemoryPool& );

   MemoryPool* operator & ();

...

};

 

Without this pattern, these methods were implicitly defined whether you liked it or not; but with the consistent use of this pattern if these methods were referenced by a non-member there was a compile-time error (access constraint), and if a member accidentally referenced them there was a link-time error (undefined symbol), ‘deleted’ just elevated this to being also a compile-time error.

 

So aside from necessity in modern C++, I would expect that this pattern still persists, and that ‘deleted’ has been added (probably as a macro whose definition is dependent on C++ Standard version for portability)  to such declarations to bring it up to date with the Standard, but they are almost certainly more likely to be ‘private’.  This would make ‘private/deleted’ more likely than ‘public/deleted’, especially in portable legacy code-bases.  The incredibly helpful ‘overloaded’ is often used in a similar way with a Standard dependent macro definition.

 

            MartinO

 

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of James Dennett via cfe-dev
Sent: 31 October 2017 15:12
To: Nicolas Lesser <blitzrakete at gmail.com>
Cc: Clang Dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Why does clang-tidy recommend deleted member functions should be public?

 

On Mon, Oct 30, 2017 at 11:34 PM, Nicolas Lesser via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > wrote:

There's nothing inherently wrong with deleting member functions that are private, but if they are public, you will get a better error message (namely that the function is deleted) instead of an error message that says that the functions are private.

 

AFAIK, Qt supports C++11, but also previous versions. I don't know how they implemented Q_DISABLE_COPY, but it probably expands to copy constructor and copy assignment declarations before C++11, and if you enable C++11 mode, deletes them instead. In pre-C++11, the declarations would have to be private, so you get an error at compile time and not at link time.

 

If you're only compiling with C++11, it should be safe to put the macro in public. Alternately, you can always delete the copy constructor and assignment yourself.

 

Another reason to prefer making these "public" is non-technical: they affect fundamental aspects of the client interface of a class, and hiding them in "private" as if they were implementation details is unhelpful.  Unfortunately necessary in C++98, but no longer needed with C++11.

 

-- James

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171031/7b3ee998/attachment.html>