From: Francis Glassborow on
DeMarcus wrote:
> Hi,
>
> I'm working on a new project using C++0x.
>
> Before I have always made disabled functions private, like this.
>
> class SomeClass
> {
> public:
> SomeClass() {}
>
> private:
> // Disable copying.
> SomeClass( const SomeClass& );
> SomeClass& operator=( const SomeClass& );
> };
>
> Is your recommendation to do the following instead?
>
> class SomeClass
> {
> public:
> SomeClass() {}
> SomeClass( const SomeClass& ) = delete;
> SomeClass& operator=( const SomeClass& ) = delete;
> };
>
> Is there anything that speaks against converting to using delete?
Not that I am aware of. The new syntax was originally designed for that
so that the implementation could diagnose an attempt to use such
functions early. It also allows us to suppress conversions (by declaring
a deleted overload) and probably several other good things as well.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: SG on
On 3 Mrz., 21:29, DeMarcus wrote:
>
> class SomeClass
> {
> public:
> SomeClass() {}
> private:
> // Disable copying.
> SomeClass( const SomeClass& );
> SomeClass& operator=( const SomeClass& );
> };
>
> Is your recommendation to do the following instead?
>
> class SomeClass
> {
> public:
> SomeClass() {}
> SomeClass( const SomeClass& ) = delete;
> SomeClass& operator=( const SomeClass& ) = delete;
> };
>
> Is there anything that speaks against converting to using delete?

Not that I'm aware of -- aside from the obvious C++0x dependency.

But I'd like to mention that -- according to Doug Gregor -- no access
control checking is done during template argument deduction whereas
any would-be invocation of a deleted function (as part of an
unevaluated context) qualifies as template argument deduction failure.
What this means is that if you use SFINAE techniques for constraining
function templates, deleted functions can be detected whereas not-
deleted private functions "pass" the test even though you are not
allowed to invoke them. So, deleted functions should be preferred.

Jeffrey's example using the base class "noncopyable_t" is also fine.
It disables any implicit generation of copy ctors for the derived
class which should also be "SFINAE-detectable" since there is simply
no copy ctor in the derived class, neither public nor private.

Cheers,
SG


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]