276
class my_class
{
    ...
    my_class(my_class const &) = delete;
    ...
};

What does = delete mean in that context?

Are there any other "modifiers" (other than = 0 and = delete)?

Sam
  • 6,961
  • 15
  • 44
  • 63
Pat O'Keefe
  • 2,763
  • 2
  • 13
  • 5
  • 1
    I stand corrected, I had missed this C++0x feature. I was thinking it was a `#define` a la Qt that evaluated to a 0 and then declared a hidden function or something. – Blindy Apr 01 '11 at 15:13
  • I've a recollection of a 'disable' keyword which means the same or something similar. Am I imagining it? Or is there a subtle difference between them? – Stewart Dec 30 '18 at 18:32

9 Answers9

229

Deleting a function is a C++11 feature:

The common idiom of "prohibiting copying" can now be expressed directly:

class X {
    // ...
    X& operator=(const X&) = delete;  // Disallow copying
    X(const X&) = delete;
};

[...]

The "delete" mechanism can be used for any function. For example, we can eliminate an undesired conversion like this:

struct Z {
    // ...

    Z(long long);     // can initialize with an long long         
    Z(long) = delete; // but not anything less
};
Danica
  • 26,635
  • 6
  • 86
  • 118
Prasoon Saurav
  • 85,400
  • 43
  • 231
  • 337
  • 5
    Isn't the traditional method to "prohibit copying" just to make the copy-ctor and operator= "private?" This goes a bit further and instructs the compiler to not even generate the functions. If they're both private and =delete, is copying doubly-prohibited? – Reb.Cabin Feb 02 '17 at 01:50
  • 13
    @Reb, `=delete` makes the method inaccessible even from contexts that can see `private` methods (i.e. within the class and its friends). This removes any uncertainty when you're reading the code. @Prasoon, that second example is still only deleting constructors - it would be nice to see a deleted `operator long ()` for example. – Toby Speight Aug 17 '17 at 14:34
  • 3
    @Reb.Cabin Using `= delete` is better than using `private` or other similar mechanisms because usually you *want* the forbidden function to be visibly declared and considered for overload resolution etc., so that it can fail as early as possible and provide the clearest error to the user. Any solution which involves "hiding" the declaration reduces this effect. – Leushenko Feb 26 '19 at 16:34
  • 1
    Is there a special reason to make the copy constructor public and apply the delete keyword. Why not leave the constructor private and apply the keyword? – Dohn Joe Jun 24 '19 at 08:39
  • Not always. You can't delete a base class virtual function in derived. – The Philomath Jan 15 '21 at 06:45
94
  1. = 0 means that a function is pure virtual and you cannot instantiate an object from this class. You need to derive from it and implement this method
  2. = delete means that the compiler will not generate those constructors for you. AFAIK this is only allowed on copy constructor and assignment operator. But I am not too good at the upcoming standard.
Alexis Wilke
  • 15,168
  • 8
  • 60
  • 116
mkaes
  • 12,760
  • 9
  • 50
  • 67
  • 5
    There are some other uses of the `=delete` syntax. For example you can use it to explicitly disallow some kind of implicit conversions that might take place with the call. For this you just delete the overloaded functions. Have a look a the Wikipedia page on C++0x for more info. – LiKao Apr 01 '11 at 13:59
  • I will do that as soon as I find some. Guess it it time to catch up with c++0X – mkaes Apr 01 '11 at 15:08
  • 1
    Yeah, C++0x rocks. I can't wait for GCC 4.5+ to be more common, so I can start using lambdas. – LiKao Apr 01 '11 at 15:21
  • 9
    The description for `= delete` is not entirely correct. `= delete` can be used for any function, in which case it is explicitly marked as deleted and any use results in a compiler error. For special member functions, this also means in particular that they then aren't generated for you by the compiler, but that is only a result of being deleted, and not what `= delete` truly is. – MicroVirus Oct 04 '16 at 09:11
35

This excerpt from The C++ Programming Language [4th Edition] - Bjarne Stroustrup book talks about the real purpose behind using =delete:

3.3.4 Suppressing Operations

Using the default copy or move for a class in a hierarchy is typically a disaster: given only a pointer to a base, we simply don’t know what members the derived class has, so we can’t know how to copy them. So, the best thing to do is usually to delete the default copy and move operations, that is, to eliminate the default definitions of those two operations:

class Shape {
public:
  Shape(const Shape&) =delete; // no copy operations
  Shape& operator=(const Shape&) =delete;

  Shape(Shape&&) =delete; // no move operations
  Shape& operator=(Shape&&) =delete;
  ˜Shape();
    // ...
};

Now an attempt to copy a Shape will be caught by the compiler.

The =delete mechanism is general, that is, it can be used to suppress any operation

Omar
  • 183
  • 1
  • 18
Saurav Sahu
  • 9,755
  • 5
  • 42
  • 64
14

Are there any other "modifiers" (other than = 0 and = delete)?

Since it appears no one else answered this question, I should mention that there is also =default.

https://docs.microsoft.com/en-us/cpp/cpp/explicitly-defaulted-and-deleted-functions#explicitly-defaulted-functions

Kyle Delaney
  • 9,521
  • 4
  • 27
  • 49
6

The coding standards I've worked with have had the following for most of class declarations.

//  coding standard: disallow when not used
T(void)                  = delete; // default ctor    (1)
~T(void)                 = delete; // default dtor    (2)
T(const T&)              = delete; // copy ctor       (3)
T(const T&&)             = delete; // move ctor       (4)
T& operator= (const T&)  = delete; // copy assignment (5)
T& operator= (const T&&) = delete; // move assignment (6)

If you use any of these 6, you simply comment out the corresponding line.

Example: class FizzBus require only dtor, and thus do not use the other 5.

//  coding standard: disallow when not used
FizzBuzz(void)                         = delete; // default ctor (1)
// ~FizzBuzz(void);                              // dtor         (2)
FizzBuzz(const FizzBuzz&)              = delete; // copy ctor    (3)
FizzBuzz& operator= (const FizzBuzz&)  = delete; // copy assig   (4)
FizzBuzz(const FizzBuzz&&)             = delete; // move ctor    (5)
FizzBuzz& operator= (const FizzBuzz&&) = delete; // move assign  (6)

We comment out only 1 here, and install the implementation of it else where (probably where the coding standard suggests). The other 5 (of 6) are disallowed with delete.

You can also use '= delete' to disallow implicit promotions of different sized values ... example

// disallow implicit promotions 
template <class T> operator T(void)              = delete;
template <class T> Vuint64& operator=  (const T) = delete;
template <class T> Vuint64& operator|= (const T) = delete;
template <class T> Vuint64& operator&= (const T) = delete;
Stewart
  • 3,675
  • 3
  • 25
  • 34
2785528
  • 5,162
  • 2
  • 16
  • 18
  • Creating an object of a class with a deleted constructor is illegal. – KeyC0de Oct 23 '20 at 20:54
  • @Nikos - No -- You simply need to provide a constructor. The example of Adding " T() = delete; " stops the compiler from adding a (do minimal) default ctor, which is occasionally useful, but still allows you to add a (presumably-does-something-useful) ctor. – 2785528 Oct 25 '20 at 01:07
3

= delete is a feature introduce in C++11. As per =delete it will not allowed to call that function.

In detail.

Suppose in a class.

Class ABC{
 Int d;
 Public:
  ABC& operator= (const ABC& obj) =delete
  {

  }
};

While calling this function for obj assignment it will not allowed. Means assignment operator is going to restrict to copy from one object to another.

Richard
  • 44,865
  • 24
  • 144
  • 216
ashutosh
  • 337
  • 2
  • 10
2

New C++0x standard. Please see section 8.4.3 in the N3242 working draft

dubnde
  • 4,171
  • 8
  • 40
  • 63
2

A deleted function is implicitly inline

(Addendum to existing answers)

... And a deleted function shall be the first declaration of the function (except for deleting explicit specializations of function templates - deletion should be at the first declaration of the specialization), meaning you cannot declare a function and later delete it, say, at its definition local to a translation unit.

Citing [dcl.fct.def.delete]/4:

A deleted function is implicitly inline. ( Note: The one-definition rule ([basic.def.odr]) applies to deleted definitions. — end note ] A deleted definition of a function shall be the first declaration of the function or, for an explicit specialization of a function template, the first declaration of that specialization. [ Example:

struct sometype {
  sometype();
};
sometype::sometype() = delete;      // ill-formed; not first declaration

end example )

A primary function template with a deleted definition can be specialized

Albeit a general rule of thumb is to avoid specializing function templates as specializations do not participate in the first step of overload resolution, there are arguable some contexts where it can be useful. E.g. when using a non-overloaded primary function template with no definition to match all types which one would not like implicitly converted to an otherwise matching-by-conversion overload; i.e., to implicitly remove a number of implicit-conversion matches by only implementing exact type matches in the explicit specialization of the non-defined, non-overloaded primary function template.

Before the deleted function concept of C++11, one could do this by simply omitting the definition of the primary function template, but this gave obscure undefined reference errors that arguably gave no semantic intent whatsoever from the author of primary function template (intentionally omitted?). If we instead explicitly delete the primary function template, the error messages in case no suitable explicit specialization is found becomes much nicer, and also shows that the omission/deletion of the primary function template's definition was intentional.

#include <iostream>
#include <string>

template< typename T >
void use_only_explicit_specializations(T t);

template<>
void use_only_explicit_specializations<int>(int t) {
    std::cout << "int: " << t;
}

int main()
{
    const int num = 42;
    const std::string str = "foo";
    use_only_explicit_specializations(num);  // int: 42
    //use_only_explicit_specializations(str); // undefined reference to `void use_only_explicit_specializations< ...
}

However, instead of simply omitting a definition for the primary function template above, yielding an obscure undefined reference error when no explicit specialization matches, the primary template definition can be deleted:

#include <iostream>
#include <string>

template< typename T >
void use_only_explicit_specializations(T t) = delete;

template<>
void use_only_explicit_specializations<int>(int t) {
    std::cout << "int: " << t;
}

int main()
{
    const int num = 42;
    const std::string str = "foo";
    use_only_explicit_specializations(num);  // int: 42
    use_only_explicit_specializations(str);
    /* error: call to deleted function 'use_only_explicit_specializations' 
       note: candidate function [with T = std::__1::basic_string<char>] has 
       been explicitly deleted
       void use_only_explicit_specializations(T t) = delete; */
}

Yielding a more more readable error message, where the deletion intent is also clearly visible (where an undefined reference error could lead to the developer thinking this an unthoughtful mistake).

Returning to why would we ever want to use this technique? Again, explicit specializations could be useful to implicitly remove implicit conversions.

#include <cstdint>
#include <iostream>

void warning_at_best(int8_t num) { 
    std::cout << "I better use -Werror and -pedantic... " << +num << "\n";
}

template< typename T >
void only_for_signed(T t) = delete;

template<>
void only_for_signed<int8_t>(int8_t t) {
    std::cout << "UB safe! 1 byte, " << +t << "\n";
}

template<>
void only_for_signed<int16_t>(int16_t t) {
    std::cout << "UB safe! 2 bytes, " << +t << "\n";
}

int main()
{
    const int8_t a = 42;
    const uint8_t b = 255U;
    const int16_t c = 255;
    const float d = 200.F;

    warning_at_best(a); // 42
    warning_at_best(b); // implementation-defined behaviour, no diagnostic required
    warning_at_best(c); // narrowing, -Wconstant-conversion warning
    warning_at_best(d); // undefined behaviour!

    only_for_signed(a);
    only_for_signed(c);

    //only_for_signed(b);  
    /* error: call to deleted function 'only_for_signed' 
       note: candidate function [with T = unsigned char] 
             has been explicitly deleted
       void only_for_signed(T t) = delete; */

    //only_for_signed(d);
    /* error: call to deleted function 'only_for_signed' 
       note: candidate function [with T = float] 
             has been explicitly deleted
       void only_for_signed(T t) = delete; */
}
dfrib
  • 56,823
  • 7
  • 97
  • 157
0

This is new thing in C++ 0x standards where you can delete an inherited function.

Tayyab
  • 8,409
  • 1
  • 14
  • 19
  • 13
    You can delete any function. E.g `void foo(int); template void foo(T) = delete;` stops all implicit conversions. Only arguments of `int` type are accepted, all others will try to instantiate a "deleted" function. – UncleBens Apr 01 '11 at 14:38