Deletion of copy-ctor & copy-assignment - public, private or protected?Can copy-constructor with delete qualifier be private?Must a deleted constructor be private?What are the differences between a pointer variable and a reference variable in C++?What is the difference between public, protected, package-private and private in Java?In C#, what is the difference between public, private, protected, and having no access modifier?Difference between private, public, and protected inheritanceWhat is the copy-and-swap idiom?What is The Rule of Three?What are the basic rules and idioms for operator overloading?Why should C++ programmers minimize use of 'new'?Replacing a 32-bit loop counter with 64-bit introduces crazy performance deviationsDefault move constructor/assignment and deleted copy constructor/assignment

How can I use the arrow sign in my bash prompt?

Modify casing of marked letters

Opposite of a diet

How will losing mobility of one hand affect my career as a programmer?

Is there a problem with hiding "forgot password" until it's needed?

Everything Bob says is false. How does he get people to trust him?

Should my PhD thesis be submitted under my legal name?

Hide Select Output from T-SQL

Ways to speed up user implemented RK4

Is a roofing delivery truck likely to crack my driveway slab?

Why is `const int& k = i; ++i; ` possible?

Do I need a multiple entry visa for a trip UK -> Sweden -> UK?

How do I define a right arrow with bar in LaTeX?

What would be the benefits of having both a state and local currencies?

Is there any reason not to eat food that's been dropped on the surface of the moon?

What defines a dissertation?

Do there exist finite commutative rings with identity that are not Bézout rings?

Is it okay / does it make sense for another player to join a running game of Munchkin?

Can somebody explain Brexit in a few child-proof sentences?

Time travel short story where a man arrives in the late 19th century in a time machine and then sends the machine back into the past

How does residential electricity work?

At which point does a character regain all their Hit Dice?

Is the destination of a commercial flight important for the pilot?

Curses work by shouting - How to avoid collateral damage?



Deletion of copy-ctor & copy-assignment - public, private or protected?


Can copy-constructor with delete qualifier be private?Must a deleted constructor be private?What are the differences between a pointer variable and a reference variable in C++?What is the difference between public, protected, package-private and private in Java?In C#, what is the difference between public, private, protected, and having no access modifier?Difference between private, public, and protected inheritanceWhat is the copy-and-swap idiom?What is The Rule of Three?What are the basic rules and idioms for operator overloading?Why should C++ programmers minimize use of 'new'?Replacing a 32-bit loop counter with 64-bit introduces crazy performance deviationsDefault move constructor/assignment and deleted copy constructor/assignment













24















In order to make an object non-copiable we can explicitly delete both its copy-constructor and copy-assignment operator.



My question is: What is the right place to do it - in the public, private or protected section of the class? And - does this choice make any difference?










share|improve this question
























  • function_name() = delete; is new to C++11. If you want to support C++98/03 you can't use it.

    – NathanOliver
    Jan 30 '17 at 17:34







  • 1





    If you throw your old shoes away, do you think about where to store them?

    – Klaus
    Mar 17 at 10:11






  • 13





    @Klaus: No, but you think about where to throw them...

    – einpoklum
    Mar 17 at 11:21















24















In order to make an object non-copiable we can explicitly delete both its copy-constructor and copy-assignment operator.



My question is: What is the right place to do it - in the public, private or protected section of the class? And - does this choice make any difference?










share|improve this question
























  • function_name() = delete; is new to C++11. If you want to support C++98/03 you can't use it.

    – NathanOliver
    Jan 30 '17 at 17:34







  • 1





    If you throw your old shoes away, do you think about where to store them?

    – Klaus
    Mar 17 at 10:11






  • 13





    @Klaus: No, but you think about where to throw them...

    – einpoklum
    Mar 17 at 11:21













24












24








24


3






In order to make an object non-copiable we can explicitly delete both its copy-constructor and copy-assignment operator.



My question is: What is the right place to do it - in the public, private or protected section of the class? And - does this choice make any difference?










share|improve this question
















In order to make an object non-copiable we can explicitly delete both its copy-constructor and copy-assignment operator.



My question is: What is the right place to do it - in the public, private or protected section of the class? And - does this choice make any difference?







c++ c++11 access-modifiers deleted-functions






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 17 at 16:29









StoryTeller

103k12218280




103k12218280










asked Mar 17 at 10:01









SajalSajal

683516




683516












  • function_name() = delete; is new to C++11. If you want to support C++98/03 you can't use it.

    – NathanOliver
    Jan 30 '17 at 17:34







  • 1





    If you throw your old shoes away, do you think about where to store them?

    – Klaus
    Mar 17 at 10:11






  • 13





    @Klaus: No, but you think about where to throw them...

    – einpoklum
    Mar 17 at 11:21

















  • function_name() = delete; is new to C++11. If you want to support C++98/03 you can't use it.

    – NathanOliver
    Jan 30 '17 at 17:34







  • 1





    If you throw your old shoes away, do you think about where to store them?

    – Klaus
    Mar 17 at 10:11






  • 13





    @Klaus: No, but you think about where to throw them...

    – einpoklum
    Mar 17 at 11:21
















function_name() = delete; is new to C++11. If you want to support C++98/03 you can't use it.

– NathanOliver
Jan 30 '17 at 17:34






function_name() = delete; is new to C++11. If you want to support C++98/03 you can't use it.

– NathanOliver
Jan 30 '17 at 17:34





1




1





If you throw your old shoes away, do you think about where to store them?

– Klaus
Mar 17 at 10:11





If you throw your old shoes away, do you think about where to store them?

– Klaus
Mar 17 at 10:11




13




13





@Klaus: No, but you think about where to throw them...

– einpoklum
Mar 17 at 11:21





@Klaus: No, but you think about where to throw them...

– einpoklum
Mar 17 at 11:21












5 Answers
5






active

oldest

votes


















32















what is the right place to do it - in the public, private or protected section of the class?




I would put them in the public section.



This is because deleting a constructor or an assignment operator is orthogonal to making them private / protected; and when these aren't deleted, they are public by default. Putting the deletions in one of those two sections seems to me like hinting "If I hadn't deleted them, I would have made them private/protected" - which is not a message you want to convey in your case.



Note, though, that the compiler doesn't care which section you put the deletion in.






share|improve this answer




















  • 8





    Exactly this. Back in the day we made these things private specifically to deny folks access to them, but this was always a hack and was only because we couldn't delete them. That consideration is no longer in play. I don't remember whether the "copy constructor is private" diagnostic tends to take precedence over the "copy constructor is deleted" diagnostic (I doubt it) but even if it doesn't changing the access level is not the right thing to do for the reasons you give.

    – Lightness Races in Orbit
    Mar 17 at 16:32











  • @LightnessRacesinOrbit I know I've seen some compilers give both errors when a function is private and deleted. The one about private access becomes just extra noise.

    – aschepler
    Mar 17 at 21:55











  • @aschepler Fair does

    – Lightness Races in Orbit
    Mar 17 at 22:03











  • gcc 7.4, but not gcc 8.1: godbolt.org/z/udzwB2 (so I guess they improved that).

    – aschepler
    Mar 17 at 22:24











  • @aschepler: Hmm... you switched the output tabs in there, so it almost looks like it's 7.4 that's doing the right thing. Anyway, thanks.

    – einpoklum
    Mar 17 at 22:37


















18















Does where we put the deleted definition make any difference?




From a pure language standpoint it makes absolutely zero difference. Name lookup and overload resolution happen before access checking. And attempting to refer to a deleted function at the end of overload resolution makes your program ill-formed, period. A compiler may or may not issue another diagnostic about the accessibility, but the program already has an error that must be reported.



So you can put that deleted definition with whatever accessibility you desire. I think most will keep it private, to be inline with the "old" practice of making a class non-copyable (put the declaration of those members in the private section of the class, and not define them), if only to help those who know the old ways "get it" sooner. A mixture of idioms, if you would.



Marking as private is also something you can't avoid if you need to support both C++03 and C++11 mode. With the help of a macro, a header can be made to conform to both standards easily:



#if __cplusplus >= 201103L
#define DELETED_DEFINITION = delete
#else
#define DELETED_DEFINITION
#endif

class noncopyable
private:
// This header can be compiled as both C++11 and C++03
noncopyable(noncopyable const&) DELETED_DEFINITION;
void operator=(noncopyable const&) DELETED_DEFINITION;
;





share|improve this answer

























  • If you want backwards compatibility then this is a must.

    – Lightness Races in Orbit
    Mar 17 at 16:32






  • 1





    @LightnessRacesinOrbit If you want backward compability, you should NEVER use C++11 features. In the case of deleted functions, the workaround is proposed by StoryTeller. But what is the backward compability solution when using lambdas, stl, concurrency, etc. ?

    – hsalimi
    Mar 18 at 8:23






  • 1





    @hsalimi There's only so far you can go with C++11 features if you want a useful compatibility layer, true, but I did have an event framework lib in a previous project that could be compiled in either C++03 or C++11 mode (it was still used by legacy embedded projects), and in the latter case it had a bunch of optimisations (mostly relating to rvalue refs) that improved things greatly without bunging up the interface too badly. I did need it to switch between Boost.Thread and std::thread, but then in the latter case it alleviates a library (and link!) dependency so it's not for naught.

    – Lightness Races in Orbit
    Mar 18 at 11:23












  • @hsalimi But yeah it meant I couldn't use lambdas in the lib ... or, at least, doing so would have been more trouble than it were worth.

    – Lightness Races in Orbit
    Mar 18 at 11:24


















11














From Scott Meyers's book, Effective Modern C++ (Item 10), it seems that it is better to define them as public:




By convention, deleted functions are declared public, not private.
There’s a reason for that. When client code tries to use a member
function, C++ checks accessibility before deleted status. When client
code tries to use a deleted private function, some compilers complain
only about the function being private, even though the function’s
accessibility doesn’t really affect whether it can be used. It’s worth
bearing this in mind when revising legacy code to replace
private-and-not-defined member functions with deleted ones, because
making the new functions public will generally result in better error
messages.




In addition, I believe that a deleted copy constructor/assignment, should be part of the class interface to be shared with ALL of the class users. Such kind of information should not be kept as secret by making them private.






share|improve this answer




















  • 2





    Meyers contradicts StoryTeller's answer, and my tests. It's still good advice, but I find einpoklum's reasoning to be superior.

    – Lightness Races in Orbit
    Mar 17 at 22:04












  • @LightnessRacesinOrbit I did the check on VS2013. The error message is different than g++ and it rightly shows the error. In addition, from a conceptual point of view, when a class deletes a ctor/cctor, etc., the class wants to say to ALL of its clients that: "Hey, this member is deleted, and you are not allowed to use it". There is no secret about this fact to keep it private.

    – hsalimi
    Mar 18 at 8:18











  • Agreed; that is einpoklum's reasoning that I find excellent ;)

    – Lightness Races in Orbit
    Mar 18 at 11:25


















3














delete works just as well with private access.



The effect of delete is to cause an error if the function is chosen by overload resolution.



The effect of private is to cause an error if the function is chosen by overload resolution from outside the class or its friends.



If both errors apply, the ultimate outcome is the same either way, but public might help avoid compiler messages about access privileges, which could cause confusion.






share|improve this answer


















  • 1





    It is recomended to make deleted functions public. See stackoverflow.com/a/18931192/108238. Also Clang-Tidy suggests this.

    – schoetbi
    Feb 6 '18 at 12:03


















1














The access of a deleted function is irrelevant. In fact, for class members, it would have made more sense to add an additional access specifier (delete:). I suspect the reason they didn't do that, was that it wouldn't work for non-member functions.



For things like the copy constructor, it makes more sense stylistically to put it in the public section. The fact that a class doesn't have a copy constructor is a pretty major fact to know about the interface to the class.



For internal functions where you are declaring a particular overload as deleted in order to get compiler-time detection of an error, it makes sense to declare the function in the same section as all the other overloads.






share|improve this answer






















    Your Answer






    StackExchange.ifUsing("editor", function ()
    StackExchange.using("externalEditor", function ()
    StackExchange.using("snippets", function ()
    StackExchange.snippets.init();
    );
    );
    , "code-snippets");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "1"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55205874%2fdeletion-of-copy-ctor-copy-assignment-public-private-or-protected%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    32















    what is the right place to do it - in the public, private or protected section of the class?




    I would put them in the public section.



    This is because deleting a constructor or an assignment operator is orthogonal to making them private / protected; and when these aren't deleted, they are public by default. Putting the deletions in one of those two sections seems to me like hinting "If I hadn't deleted them, I would have made them private/protected" - which is not a message you want to convey in your case.



    Note, though, that the compiler doesn't care which section you put the deletion in.






    share|improve this answer




















    • 8





      Exactly this. Back in the day we made these things private specifically to deny folks access to them, but this was always a hack and was only because we couldn't delete them. That consideration is no longer in play. I don't remember whether the "copy constructor is private" diagnostic tends to take precedence over the "copy constructor is deleted" diagnostic (I doubt it) but even if it doesn't changing the access level is not the right thing to do for the reasons you give.

      – Lightness Races in Orbit
      Mar 17 at 16:32











    • @LightnessRacesinOrbit I know I've seen some compilers give both errors when a function is private and deleted. The one about private access becomes just extra noise.

      – aschepler
      Mar 17 at 21:55











    • @aschepler Fair does

      – Lightness Races in Orbit
      Mar 17 at 22:03











    • gcc 7.4, but not gcc 8.1: godbolt.org/z/udzwB2 (so I guess they improved that).

      – aschepler
      Mar 17 at 22:24











    • @aschepler: Hmm... you switched the output tabs in there, so it almost looks like it's 7.4 that's doing the right thing. Anyway, thanks.

      – einpoklum
      Mar 17 at 22:37















    32















    what is the right place to do it - in the public, private or protected section of the class?




    I would put them in the public section.



    This is because deleting a constructor or an assignment operator is orthogonal to making them private / protected; and when these aren't deleted, they are public by default. Putting the deletions in one of those two sections seems to me like hinting "If I hadn't deleted them, I would have made them private/protected" - which is not a message you want to convey in your case.



    Note, though, that the compiler doesn't care which section you put the deletion in.






    share|improve this answer




















    • 8





      Exactly this. Back in the day we made these things private specifically to deny folks access to them, but this was always a hack and was only because we couldn't delete them. That consideration is no longer in play. I don't remember whether the "copy constructor is private" diagnostic tends to take precedence over the "copy constructor is deleted" diagnostic (I doubt it) but even if it doesn't changing the access level is not the right thing to do for the reasons you give.

      – Lightness Races in Orbit
      Mar 17 at 16:32











    • @LightnessRacesinOrbit I know I've seen some compilers give both errors when a function is private and deleted. The one about private access becomes just extra noise.

      – aschepler
      Mar 17 at 21:55











    • @aschepler Fair does

      – Lightness Races in Orbit
      Mar 17 at 22:03











    • gcc 7.4, but not gcc 8.1: godbolt.org/z/udzwB2 (so I guess they improved that).

      – aschepler
      Mar 17 at 22:24











    • @aschepler: Hmm... you switched the output tabs in there, so it almost looks like it's 7.4 that's doing the right thing. Anyway, thanks.

      – einpoklum
      Mar 17 at 22:37













    32












    32








    32








    what is the right place to do it - in the public, private or protected section of the class?




    I would put them in the public section.



    This is because deleting a constructor or an assignment operator is orthogonal to making them private / protected; and when these aren't deleted, they are public by default. Putting the deletions in one of those two sections seems to me like hinting "If I hadn't deleted them, I would have made them private/protected" - which is not a message you want to convey in your case.



    Note, though, that the compiler doesn't care which section you put the deletion in.






    share|improve this answer
















    what is the right place to do it - in the public, private or protected section of the class?




    I would put them in the public section.



    This is because deleting a constructor or an assignment operator is orthogonal to making them private / protected; and when these aren't deleted, they are public by default. Putting the deletions in one of those two sections seems to me like hinting "If I hadn't deleted them, I would have made them private/protected" - which is not a message you want to convey in your case.



    Note, though, that the compiler doesn't care which section you put the deletion in.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 22 at 16:45

























    answered Mar 17 at 10:38









    einpoklumeinpoklum

    36.2k28132260




    36.2k28132260







    • 8





      Exactly this. Back in the day we made these things private specifically to deny folks access to them, but this was always a hack and was only because we couldn't delete them. That consideration is no longer in play. I don't remember whether the "copy constructor is private" diagnostic tends to take precedence over the "copy constructor is deleted" diagnostic (I doubt it) but even if it doesn't changing the access level is not the right thing to do for the reasons you give.

      – Lightness Races in Orbit
      Mar 17 at 16:32











    • @LightnessRacesinOrbit I know I've seen some compilers give both errors when a function is private and deleted. The one about private access becomes just extra noise.

      – aschepler
      Mar 17 at 21:55











    • @aschepler Fair does

      – Lightness Races in Orbit
      Mar 17 at 22:03











    • gcc 7.4, but not gcc 8.1: godbolt.org/z/udzwB2 (so I guess they improved that).

      – aschepler
      Mar 17 at 22:24











    • @aschepler: Hmm... you switched the output tabs in there, so it almost looks like it's 7.4 that's doing the right thing. Anyway, thanks.

      – einpoklum
      Mar 17 at 22:37












    • 8





      Exactly this. Back in the day we made these things private specifically to deny folks access to them, but this was always a hack and was only because we couldn't delete them. That consideration is no longer in play. I don't remember whether the "copy constructor is private" diagnostic tends to take precedence over the "copy constructor is deleted" diagnostic (I doubt it) but even if it doesn't changing the access level is not the right thing to do for the reasons you give.

      – Lightness Races in Orbit
      Mar 17 at 16:32











    • @LightnessRacesinOrbit I know I've seen some compilers give both errors when a function is private and deleted. The one about private access becomes just extra noise.

      – aschepler
      Mar 17 at 21:55











    • @aschepler Fair does

      – Lightness Races in Orbit
      Mar 17 at 22:03











    • gcc 7.4, but not gcc 8.1: godbolt.org/z/udzwB2 (so I guess they improved that).

      – aschepler
      Mar 17 at 22:24











    • @aschepler: Hmm... you switched the output tabs in there, so it almost looks like it's 7.4 that's doing the right thing. Anyway, thanks.

      – einpoklum
      Mar 17 at 22:37







    8




    8





    Exactly this. Back in the day we made these things private specifically to deny folks access to them, but this was always a hack and was only because we couldn't delete them. That consideration is no longer in play. I don't remember whether the "copy constructor is private" diagnostic tends to take precedence over the "copy constructor is deleted" diagnostic (I doubt it) but even if it doesn't changing the access level is not the right thing to do for the reasons you give.

    – Lightness Races in Orbit
    Mar 17 at 16:32





    Exactly this. Back in the day we made these things private specifically to deny folks access to them, but this was always a hack and was only because we couldn't delete them. That consideration is no longer in play. I don't remember whether the "copy constructor is private" diagnostic tends to take precedence over the "copy constructor is deleted" diagnostic (I doubt it) but even if it doesn't changing the access level is not the right thing to do for the reasons you give.

    – Lightness Races in Orbit
    Mar 17 at 16:32













    @LightnessRacesinOrbit I know I've seen some compilers give both errors when a function is private and deleted. The one about private access becomes just extra noise.

    – aschepler
    Mar 17 at 21:55





    @LightnessRacesinOrbit I know I've seen some compilers give both errors when a function is private and deleted. The one about private access becomes just extra noise.

    – aschepler
    Mar 17 at 21:55













    @aschepler Fair does

    – Lightness Races in Orbit
    Mar 17 at 22:03





    @aschepler Fair does

    – Lightness Races in Orbit
    Mar 17 at 22:03













    gcc 7.4, but not gcc 8.1: godbolt.org/z/udzwB2 (so I guess they improved that).

    – aschepler
    Mar 17 at 22:24





    gcc 7.4, but not gcc 8.1: godbolt.org/z/udzwB2 (so I guess they improved that).

    – aschepler
    Mar 17 at 22:24













    @aschepler: Hmm... you switched the output tabs in there, so it almost looks like it's 7.4 that's doing the right thing. Anyway, thanks.

    – einpoklum
    Mar 17 at 22:37





    @aschepler: Hmm... you switched the output tabs in there, so it almost looks like it's 7.4 that's doing the right thing. Anyway, thanks.

    – einpoklum
    Mar 17 at 22:37













    18















    Does where we put the deleted definition make any difference?




    From a pure language standpoint it makes absolutely zero difference. Name lookup and overload resolution happen before access checking. And attempting to refer to a deleted function at the end of overload resolution makes your program ill-formed, period. A compiler may or may not issue another diagnostic about the accessibility, but the program already has an error that must be reported.



    So you can put that deleted definition with whatever accessibility you desire. I think most will keep it private, to be inline with the "old" practice of making a class non-copyable (put the declaration of those members in the private section of the class, and not define them), if only to help those who know the old ways "get it" sooner. A mixture of idioms, if you would.



    Marking as private is also something you can't avoid if you need to support both C++03 and C++11 mode. With the help of a macro, a header can be made to conform to both standards easily:



    #if __cplusplus >= 201103L
    #define DELETED_DEFINITION = delete
    #else
    #define DELETED_DEFINITION
    #endif

    class noncopyable
    private:
    // This header can be compiled as both C++11 and C++03
    noncopyable(noncopyable const&) DELETED_DEFINITION;
    void operator=(noncopyable const&) DELETED_DEFINITION;
    ;





    share|improve this answer

























    • If you want backwards compatibility then this is a must.

      – Lightness Races in Orbit
      Mar 17 at 16:32






    • 1





      @LightnessRacesinOrbit If you want backward compability, you should NEVER use C++11 features. In the case of deleted functions, the workaround is proposed by StoryTeller. But what is the backward compability solution when using lambdas, stl, concurrency, etc. ?

      – hsalimi
      Mar 18 at 8:23






    • 1





      @hsalimi There's only so far you can go with C++11 features if you want a useful compatibility layer, true, but I did have an event framework lib in a previous project that could be compiled in either C++03 or C++11 mode (it was still used by legacy embedded projects), and in the latter case it had a bunch of optimisations (mostly relating to rvalue refs) that improved things greatly without bunging up the interface too badly. I did need it to switch between Boost.Thread and std::thread, but then in the latter case it alleviates a library (and link!) dependency so it's not for naught.

      – Lightness Races in Orbit
      Mar 18 at 11:23












    • @hsalimi But yeah it meant I couldn't use lambdas in the lib ... or, at least, doing so would have been more trouble than it were worth.

      – Lightness Races in Orbit
      Mar 18 at 11:24















    18















    Does where we put the deleted definition make any difference?




    From a pure language standpoint it makes absolutely zero difference. Name lookup and overload resolution happen before access checking. And attempting to refer to a deleted function at the end of overload resolution makes your program ill-formed, period. A compiler may or may not issue another diagnostic about the accessibility, but the program already has an error that must be reported.



    So you can put that deleted definition with whatever accessibility you desire. I think most will keep it private, to be inline with the "old" practice of making a class non-copyable (put the declaration of those members in the private section of the class, and not define them), if only to help those who know the old ways "get it" sooner. A mixture of idioms, if you would.



    Marking as private is also something you can't avoid if you need to support both C++03 and C++11 mode. With the help of a macro, a header can be made to conform to both standards easily:



    #if __cplusplus >= 201103L
    #define DELETED_DEFINITION = delete
    #else
    #define DELETED_DEFINITION
    #endif

    class noncopyable
    private:
    // This header can be compiled as both C++11 and C++03
    noncopyable(noncopyable const&) DELETED_DEFINITION;
    void operator=(noncopyable const&) DELETED_DEFINITION;
    ;





    share|improve this answer

























    • If you want backwards compatibility then this is a must.

      – Lightness Races in Orbit
      Mar 17 at 16:32






    • 1





      @LightnessRacesinOrbit If you want backward compability, you should NEVER use C++11 features. In the case of deleted functions, the workaround is proposed by StoryTeller. But what is the backward compability solution when using lambdas, stl, concurrency, etc. ?

      – hsalimi
      Mar 18 at 8:23






    • 1





      @hsalimi There's only so far you can go with C++11 features if you want a useful compatibility layer, true, but I did have an event framework lib in a previous project that could be compiled in either C++03 or C++11 mode (it was still used by legacy embedded projects), and in the latter case it had a bunch of optimisations (mostly relating to rvalue refs) that improved things greatly without bunging up the interface too badly. I did need it to switch between Boost.Thread and std::thread, but then in the latter case it alleviates a library (and link!) dependency so it's not for naught.

      – Lightness Races in Orbit
      Mar 18 at 11:23












    • @hsalimi But yeah it meant I couldn't use lambdas in the lib ... or, at least, doing so would have been more trouble than it were worth.

      – Lightness Races in Orbit
      Mar 18 at 11:24













    18












    18








    18








    Does where we put the deleted definition make any difference?




    From a pure language standpoint it makes absolutely zero difference. Name lookup and overload resolution happen before access checking. And attempting to refer to a deleted function at the end of overload resolution makes your program ill-formed, period. A compiler may or may not issue another diagnostic about the accessibility, but the program already has an error that must be reported.



    So you can put that deleted definition with whatever accessibility you desire. I think most will keep it private, to be inline with the "old" practice of making a class non-copyable (put the declaration of those members in the private section of the class, and not define them), if only to help those who know the old ways "get it" sooner. A mixture of idioms, if you would.



    Marking as private is also something you can't avoid if you need to support both C++03 and C++11 mode. With the help of a macro, a header can be made to conform to both standards easily:



    #if __cplusplus >= 201103L
    #define DELETED_DEFINITION = delete
    #else
    #define DELETED_DEFINITION
    #endif

    class noncopyable
    private:
    // This header can be compiled as both C++11 and C++03
    noncopyable(noncopyable const&) DELETED_DEFINITION;
    void operator=(noncopyable const&) DELETED_DEFINITION;
    ;





    share|improve this answer
















    Does where we put the deleted definition make any difference?




    From a pure language standpoint it makes absolutely zero difference. Name lookup and overload resolution happen before access checking. And attempting to refer to a deleted function at the end of overload resolution makes your program ill-formed, period. A compiler may or may not issue another diagnostic about the accessibility, but the program already has an error that must be reported.



    So you can put that deleted definition with whatever accessibility you desire. I think most will keep it private, to be inline with the "old" practice of making a class non-copyable (put the declaration of those members in the private section of the class, and not define them), if only to help those who know the old ways "get it" sooner. A mixture of idioms, if you would.



    Marking as private is also something you can't avoid if you need to support both C++03 and C++11 mode. With the help of a macro, a header can be made to conform to both standards easily:



    #if __cplusplus >= 201103L
    #define DELETED_DEFINITION = delete
    #else
    #define DELETED_DEFINITION
    #endif

    class noncopyable
    private:
    // This header can be compiled as both C++11 and C++03
    noncopyable(noncopyable const&) DELETED_DEFINITION;
    void operator=(noncopyable const&) DELETED_DEFINITION;
    ;






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 17 at 17:20

























    answered Mar 17 at 10:26









    StoryTellerStoryTeller

    103k12218280




    103k12218280












    • If you want backwards compatibility then this is a must.

      – Lightness Races in Orbit
      Mar 17 at 16:32






    • 1





      @LightnessRacesinOrbit If you want backward compability, you should NEVER use C++11 features. In the case of deleted functions, the workaround is proposed by StoryTeller. But what is the backward compability solution when using lambdas, stl, concurrency, etc. ?

      – hsalimi
      Mar 18 at 8:23






    • 1





      @hsalimi There's only so far you can go with C++11 features if you want a useful compatibility layer, true, but I did have an event framework lib in a previous project that could be compiled in either C++03 or C++11 mode (it was still used by legacy embedded projects), and in the latter case it had a bunch of optimisations (mostly relating to rvalue refs) that improved things greatly without bunging up the interface too badly. I did need it to switch between Boost.Thread and std::thread, but then in the latter case it alleviates a library (and link!) dependency so it's not for naught.

      – Lightness Races in Orbit
      Mar 18 at 11:23












    • @hsalimi But yeah it meant I couldn't use lambdas in the lib ... or, at least, doing so would have been more trouble than it were worth.

      – Lightness Races in Orbit
      Mar 18 at 11:24

















    • If you want backwards compatibility then this is a must.

      – Lightness Races in Orbit
      Mar 17 at 16:32






    • 1





      @LightnessRacesinOrbit If you want backward compability, you should NEVER use C++11 features. In the case of deleted functions, the workaround is proposed by StoryTeller. But what is the backward compability solution when using lambdas, stl, concurrency, etc. ?

      – hsalimi
      Mar 18 at 8:23






    • 1





      @hsalimi There's only so far you can go with C++11 features if you want a useful compatibility layer, true, but I did have an event framework lib in a previous project that could be compiled in either C++03 or C++11 mode (it was still used by legacy embedded projects), and in the latter case it had a bunch of optimisations (mostly relating to rvalue refs) that improved things greatly without bunging up the interface too badly. I did need it to switch between Boost.Thread and std::thread, but then in the latter case it alleviates a library (and link!) dependency so it's not for naught.

      – Lightness Races in Orbit
      Mar 18 at 11:23












    • @hsalimi But yeah it meant I couldn't use lambdas in the lib ... or, at least, doing so would have been more trouble than it were worth.

      – Lightness Races in Orbit
      Mar 18 at 11:24
















    If you want backwards compatibility then this is a must.

    – Lightness Races in Orbit
    Mar 17 at 16:32





    If you want backwards compatibility then this is a must.

    – Lightness Races in Orbit
    Mar 17 at 16:32




    1




    1





    @LightnessRacesinOrbit If you want backward compability, you should NEVER use C++11 features. In the case of deleted functions, the workaround is proposed by StoryTeller. But what is the backward compability solution when using lambdas, stl, concurrency, etc. ?

    – hsalimi
    Mar 18 at 8:23





    @LightnessRacesinOrbit If you want backward compability, you should NEVER use C++11 features. In the case of deleted functions, the workaround is proposed by StoryTeller. But what is the backward compability solution when using lambdas, stl, concurrency, etc. ?

    – hsalimi
    Mar 18 at 8:23




    1




    1





    @hsalimi There's only so far you can go with C++11 features if you want a useful compatibility layer, true, but I did have an event framework lib in a previous project that could be compiled in either C++03 or C++11 mode (it was still used by legacy embedded projects), and in the latter case it had a bunch of optimisations (mostly relating to rvalue refs) that improved things greatly without bunging up the interface too badly. I did need it to switch between Boost.Thread and std::thread, but then in the latter case it alleviates a library (and link!) dependency so it's not for naught.

    – Lightness Races in Orbit
    Mar 18 at 11:23






    @hsalimi There's only so far you can go with C++11 features if you want a useful compatibility layer, true, but I did have an event framework lib in a previous project that could be compiled in either C++03 or C++11 mode (it was still used by legacy embedded projects), and in the latter case it had a bunch of optimisations (mostly relating to rvalue refs) that improved things greatly without bunging up the interface too badly. I did need it to switch between Boost.Thread and std::thread, but then in the latter case it alleviates a library (and link!) dependency so it's not for naught.

    – Lightness Races in Orbit
    Mar 18 at 11:23














    @hsalimi But yeah it meant I couldn't use lambdas in the lib ... or, at least, doing so would have been more trouble than it were worth.

    – Lightness Races in Orbit
    Mar 18 at 11:24





    @hsalimi But yeah it meant I couldn't use lambdas in the lib ... or, at least, doing so would have been more trouble than it were worth.

    – Lightness Races in Orbit
    Mar 18 at 11:24











    11














    From Scott Meyers's book, Effective Modern C++ (Item 10), it seems that it is better to define them as public:




    By convention, deleted functions are declared public, not private.
    There’s a reason for that. When client code tries to use a member
    function, C++ checks accessibility before deleted status. When client
    code tries to use a deleted private function, some compilers complain
    only about the function being private, even though the function’s
    accessibility doesn’t really affect whether it can be used. It’s worth
    bearing this in mind when revising legacy code to replace
    private-and-not-defined member functions with deleted ones, because
    making the new functions public will generally result in better error
    messages.




    In addition, I believe that a deleted copy constructor/assignment, should be part of the class interface to be shared with ALL of the class users. Such kind of information should not be kept as secret by making them private.






    share|improve this answer




















    • 2





      Meyers contradicts StoryTeller's answer, and my tests. It's still good advice, but I find einpoklum's reasoning to be superior.

      – Lightness Races in Orbit
      Mar 17 at 22:04












    • @LightnessRacesinOrbit I did the check on VS2013. The error message is different than g++ and it rightly shows the error. In addition, from a conceptual point of view, when a class deletes a ctor/cctor, etc., the class wants to say to ALL of its clients that: "Hey, this member is deleted, and you are not allowed to use it". There is no secret about this fact to keep it private.

      – hsalimi
      Mar 18 at 8:18











    • Agreed; that is einpoklum's reasoning that I find excellent ;)

      – Lightness Races in Orbit
      Mar 18 at 11:25















    11














    From Scott Meyers's book, Effective Modern C++ (Item 10), it seems that it is better to define them as public:




    By convention, deleted functions are declared public, not private.
    There’s a reason for that. When client code tries to use a member
    function, C++ checks accessibility before deleted status. When client
    code tries to use a deleted private function, some compilers complain
    only about the function being private, even though the function’s
    accessibility doesn’t really affect whether it can be used. It’s worth
    bearing this in mind when revising legacy code to replace
    private-and-not-defined member functions with deleted ones, because
    making the new functions public will generally result in better error
    messages.




    In addition, I believe that a deleted copy constructor/assignment, should be part of the class interface to be shared with ALL of the class users. Such kind of information should not be kept as secret by making them private.






    share|improve this answer




















    • 2





      Meyers contradicts StoryTeller's answer, and my tests. It's still good advice, but I find einpoklum's reasoning to be superior.

      – Lightness Races in Orbit
      Mar 17 at 22:04












    • @LightnessRacesinOrbit I did the check on VS2013. The error message is different than g++ and it rightly shows the error. In addition, from a conceptual point of view, when a class deletes a ctor/cctor, etc., the class wants to say to ALL of its clients that: "Hey, this member is deleted, and you are not allowed to use it". There is no secret about this fact to keep it private.

      – hsalimi
      Mar 18 at 8:18











    • Agreed; that is einpoklum's reasoning that I find excellent ;)

      – Lightness Races in Orbit
      Mar 18 at 11:25













    11












    11








    11







    From Scott Meyers's book, Effective Modern C++ (Item 10), it seems that it is better to define them as public:




    By convention, deleted functions are declared public, not private.
    There’s a reason for that. When client code tries to use a member
    function, C++ checks accessibility before deleted status. When client
    code tries to use a deleted private function, some compilers complain
    only about the function being private, even though the function’s
    accessibility doesn’t really affect whether it can be used. It’s worth
    bearing this in mind when revising legacy code to replace
    private-and-not-defined member functions with deleted ones, because
    making the new functions public will generally result in better error
    messages.




    In addition, I believe that a deleted copy constructor/assignment, should be part of the class interface to be shared with ALL of the class users. Such kind of information should not be kept as secret by making them private.






    share|improve this answer















    From Scott Meyers's book, Effective Modern C++ (Item 10), it seems that it is better to define them as public:




    By convention, deleted functions are declared public, not private.
    There’s a reason for that. When client code tries to use a member
    function, C++ checks accessibility before deleted status. When client
    code tries to use a deleted private function, some compilers complain
    only about the function being private, even though the function’s
    accessibility doesn’t really affect whether it can be used. It’s worth
    bearing this in mind when revising legacy code to replace
    private-and-not-defined member functions with deleted ones, because
    making the new functions public will generally result in better error
    messages.




    In addition, I believe that a deleted copy constructor/assignment, should be part of the class interface to be shared with ALL of the class users. Such kind of information should not be kept as secret by making them private.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 18 at 11:02

























    answered Mar 17 at 21:43









    hsalimihsalimi

    4,72022351




    4,72022351







    • 2





      Meyers contradicts StoryTeller's answer, and my tests. It's still good advice, but I find einpoklum's reasoning to be superior.

      – Lightness Races in Orbit
      Mar 17 at 22:04












    • @LightnessRacesinOrbit I did the check on VS2013. The error message is different than g++ and it rightly shows the error. In addition, from a conceptual point of view, when a class deletes a ctor/cctor, etc., the class wants to say to ALL of its clients that: "Hey, this member is deleted, and you are not allowed to use it". There is no secret about this fact to keep it private.

      – hsalimi
      Mar 18 at 8:18











    • Agreed; that is einpoklum's reasoning that I find excellent ;)

      – Lightness Races in Orbit
      Mar 18 at 11:25












    • 2





      Meyers contradicts StoryTeller's answer, and my tests. It's still good advice, but I find einpoklum's reasoning to be superior.

      – Lightness Races in Orbit
      Mar 17 at 22:04












    • @LightnessRacesinOrbit I did the check on VS2013. The error message is different than g++ and it rightly shows the error. In addition, from a conceptual point of view, when a class deletes a ctor/cctor, etc., the class wants to say to ALL of its clients that: "Hey, this member is deleted, and you are not allowed to use it". There is no secret about this fact to keep it private.

      – hsalimi
      Mar 18 at 8:18











    • Agreed; that is einpoklum's reasoning that I find excellent ;)

      – Lightness Races in Orbit
      Mar 18 at 11:25







    2




    2





    Meyers contradicts StoryTeller's answer, and my tests. It's still good advice, but I find einpoklum's reasoning to be superior.

    – Lightness Races in Orbit
    Mar 17 at 22:04






    Meyers contradicts StoryTeller's answer, and my tests. It's still good advice, but I find einpoklum's reasoning to be superior.

    – Lightness Races in Orbit
    Mar 17 at 22:04














    @LightnessRacesinOrbit I did the check on VS2013. The error message is different than g++ and it rightly shows the error. In addition, from a conceptual point of view, when a class deletes a ctor/cctor, etc., the class wants to say to ALL of its clients that: "Hey, this member is deleted, and you are not allowed to use it". There is no secret about this fact to keep it private.

    – hsalimi
    Mar 18 at 8:18





    @LightnessRacesinOrbit I did the check on VS2013. The error message is different than g++ and it rightly shows the error. In addition, from a conceptual point of view, when a class deletes a ctor/cctor, etc., the class wants to say to ALL of its clients that: "Hey, this member is deleted, and you are not allowed to use it". There is no secret about this fact to keep it private.

    – hsalimi
    Mar 18 at 8:18













    Agreed; that is einpoklum's reasoning that I find excellent ;)

    – Lightness Races in Orbit
    Mar 18 at 11:25





    Agreed; that is einpoklum's reasoning that I find excellent ;)

    – Lightness Races in Orbit
    Mar 18 at 11:25











    3














    delete works just as well with private access.



    The effect of delete is to cause an error if the function is chosen by overload resolution.



    The effect of private is to cause an error if the function is chosen by overload resolution from outside the class or its friends.



    If both errors apply, the ultimate outcome is the same either way, but public might help avoid compiler messages about access privileges, which could cause confusion.






    share|improve this answer


















    • 1





      It is recomended to make deleted functions public. See stackoverflow.com/a/18931192/108238. Also Clang-Tidy suggests this.

      – schoetbi
      Feb 6 '18 at 12:03















    3














    delete works just as well with private access.



    The effect of delete is to cause an error if the function is chosen by overload resolution.



    The effect of private is to cause an error if the function is chosen by overload resolution from outside the class or its friends.



    If both errors apply, the ultimate outcome is the same either way, but public might help avoid compiler messages about access privileges, which could cause confusion.






    share|improve this answer


















    • 1





      It is recomended to make deleted functions public. See stackoverflow.com/a/18931192/108238. Also Clang-Tidy suggests this.

      – schoetbi
      Feb 6 '18 at 12:03













    3












    3








    3







    delete works just as well with private access.



    The effect of delete is to cause an error if the function is chosen by overload resolution.



    The effect of private is to cause an error if the function is chosen by overload resolution from outside the class or its friends.



    If both errors apply, the ultimate outcome is the same either way, but public might help avoid compiler messages about access privileges, which could cause confusion.






    share|improve this answer













    delete works just as well with private access.



    The effect of delete is to cause an error if the function is chosen by overload resolution.



    The effect of private is to cause an error if the function is chosen by overload resolution from outside the class or its friends.



    If both errors apply, the ultimate outcome is the same either way, but public might help avoid compiler messages about access privileges, which could cause confusion.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jan 30 '17 at 17:21









    PotatoswatterPotatoswatter

    111k15213367




    111k15213367







    • 1





      It is recomended to make deleted functions public. See stackoverflow.com/a/18931192/108238. Also Clang-Tidy suggests this.

      – schoetbi
      Feb 6 '18 at 12:03












    • 1





      It is recomended to make deleted functions public. See stackoverflow.com/a/18931192/108238. Also Clang-Tidy suggests this.

      – schoetbi
      Feb 6 '18 at 12:03







    1




    1





    It is recomended to make deleted functions public. See stackoverflow.com/a/18931192/108238. Also Clang-Tidy suggests this.

    – schoetbi
    Feb 6 '18 at 12:03





    It is recomended to make deleted functions public. See stackoverflow.com/a/18931192/108238. Also Clang-Tidy suggests this.

    – schoetbi
    Feb 6 '18 at 12:03











    1














    The access of a deleted function is irrelevant. In fact, for class members, it would have made more sense to add an additional access specifier (delete:). I suspect the reason they didn't do that, was that it wouldn't work for non-member functions.



    For things like the copy constructor, it makes more sense stylistically to put it in the public section. The fact that a class doesn't have a copy constructor is a pretty major fact to know about the interface to the class.



    For internal functions where you are declaring a particular overload as deleted in order to get compiler-time detection of an error, it makes sense to declare the function in the same section as all the other overloads.






    share|improve this answer



























      1














      The access of a deleted function is irrelevant. In fact, for class members, it would have made more sense to add an additional access specifier (delete:). I suspect the reason they didn't do that, was that it wouldn't work for non-member functions.



      For things like the copy constructor, it makes more sense stylistically to put it in the public section. The fact that a class doesn't have a copy constructor is a pretty major fact to know about the interface to the class.



      For internal functions where you are declaring a particular overload as deleted in order to get compiler-time detection of an error, it makes sense to declare the function in the same section as all the other overloads.






      share|improve this answer

























        1












        1








        1







        The access of a deleted function is irrelevant. In fact, for class members, it would have made more sense to add an additional access specifier (delete:). I suspect the reason they didn't do that, was that it wouldn't work for non-member functions.



        For things like the copy constructor, it makes more sense stylistically to put it in the public section. The fact that a class doesn't have a copy constructor is a pretty major fact to know about the interface to the class.



        For internal functions where you are declaring a particular overload as deleted in order to get compiler-time detection of an error, it makes sense to declare the function in the same section as all the other overloads.






        share|improve this answer













        The access of a deleted function is irrelevant. In fact, for class members, it would have made more sense to add an additional access specifier (delete:). I suspect the reason they didn't do that, was that it wouldn't work for non-member functions.



        For things like the copy constructor, it makes more sense stylistically to put it in the public section. The fact that a class doesn't have a copy constructor is a pretty major fact to know about the interface to the class.



        For internal functions where you are declaring a particular overload as deleted in order to get compiler-time detection of an error, it makes sense to declare the function in the same section as all the other overloads.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 30 '17 at 17:20









        Martin BonnerMartin Bonner

        23.7k33267




        23.7k33267



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55205874%2fdeletion-of-copy-ctor-copy-assignment-public-private-or-protected%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            How should I support this large drywall patch? Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?How do I cover large gaps in drywall?How do I keep drywall around a patch from crumbling?Can I glue a second layer of drywall?How to patch long strip on drywall?Large drywall patch: how to avoid bulging seams?Drywall Mesh Patch vs. Bulge? To remove or not to remove?How to fix this drywall job?Prep drywall before backsplashWhat's the best way to fix this horrible drywall patch job?Drywall patching using 3M Patch Plus Primer

            random experiment with two different functions on unit interval Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern)Random variable and probability space notionsRandom Walk with EdgesFinding functions where the increase over a random interval is Poisson distributedNumber of days until dayCan an observed event in fact be of zero probability?Unit random processmodels of coins and uniform distributionHow to get the number of successes given $n$ trials , probability $P$ and a random variable $X$Absorbing Markov chain in a computer. Is “almost every” turned into always convergence in computer executions?Stopped random walk is not uniformly integrable

            Lowndes Grove History Architecture References Navigation menu32°48′6″N 79°57′58″W / 32.80167°N 79.96611°W / 32.80167; -79.9661132°48′6″N 79°57′58″W / 32.80167°N 79.96611°W / 32.80167; -79.9661178002500"National Register Information System"Historic houses of South Carolina"Lowndes Grove""+32° 48' 6.00", −79° 57' 58.00""Lowndes Grove, Charleston County (260 St. Margaret St., Charleston)""Lowndes Grove"The Charleston ExpositionIt Happened in South Carolina"Lowndes Grove (House), Saint Margaret Street & Sixth Avenue, Charleston, Charleston County, SC(Photographs)"Plantations of the Carolina Low Countrye