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












18















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




















  • 1





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

    – Klaus
    2 days ago






  • 12





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

    – einpoklum
    2 days ago
















18















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




















  • 1





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

    – Klaus
    2 days ago






  • 12





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

    – einpoklum
    2 days ago














18












18








18


2






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 2 days ago









StoryTeller

102k12215279




102k12215279










asked 2 days ago









SajalSajal

640515




640515








  • 1





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

    – Klaus
    2 days ago






  • 12





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

    – einpoklum
    2 days ago














  • 1





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

    – Klaus
    2 days ago






  • 12





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

    – einpoklum
    2 days ago








1




1





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

– Klaus
2 days ago





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

– Klaus
2 days ago




12




12





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

– einpoklum
2 days ago





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

– einpoklum
2 days ago












3 Answers
3






active

oldest

votes


















25















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. 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





















  • 7





    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
    2 days ago











  • @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
    2 days ago











  • @aschepler Fair does

    – Lightness Races in Orbit
    2 days ago











  • @aschepler: Examples?

    – einpoklum
    2 days ago











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

    – aschepler
    2 days ago



















15















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
    2 days ago






  • 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
    yesterday











  • @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
    yesterday













  • @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
    yesterday



















6














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





















  • 1





    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
    2 days ago













  • @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
    yesterday











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

    – Lightness Races in Orbit
    yesterday











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

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









25















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. 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





















  • 7





    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
    2 days ago











  • @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
    2 days ago











  • @aschepler Fair does

    – Lightness Races in Orbit
    2 days ago











  • @aschepler: Examples?

    – einpoklum
    2 days ago











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

    – aschepler
    2 days ago
















25















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. 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





















  • 7





    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
    2 days ago











  • @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
    2 days ago











  • @aschepler Fair does

    – Lightness Races in Orbit
    2 days ago











  • @aschepler: Examples?

    – einpoklum
    2 days ago











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

    – aschepler
    2 days ago














25












25








25








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. 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. 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 2 days ago

























answered 2 days ago









einpoklumeinpoklum

35.9k27132257




35.9k27132257








  • 7





    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
    2 days ago











  • @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
    2 days ago











  • @aschepler Fair does

    – Lightness Races in Orbit
    2 days ago











  • @aschepler: Examples?

    – einpoklum
    2 days ago











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

    – aschepler
    2 days ago














  • 7





    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
    2 days ago











  • @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
    2 days ago











  • @aschepler Fair does

    – Lightness Races in Orbit
    2 days ago











  • @aschepler: Examples?

    – einpoklum
    2 days ago











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

    – aschepler
    2 days ago








7




7





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
2 days ago





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
2 days ago













@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
2 days ago





@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
2 days ago













@aschepler Fair does

– Lightness Races in Orbit
2 days ago





@aschepler Fair does

– Lightness Races in Orbit
2 days ago













@aschepler: Examples?

– einpoklum
2 days ago





@aschepler: Examples?

– einpoklum
2 days ago













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

– aschepler
2 days ago





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

– aschepler
2 days ago













15















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
    2 days ago






  • 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
    yesterday











  • @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
    yesterday













  • @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
    yesterday
















15















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
    2 days ago






  • 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
    yesterday











  • @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
    yesterday













  • @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
    yesterday














15












15








15








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 2 days ago

























answered 2 days ago









StoryTellerStoryTeller

102k12215279




102k12215279













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

    – Lightness Races in Orbit
    2 days ago






  • 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
    yesterday











  • @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
    yesterday













  • @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
    yesterday



















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

    – Lightness Races in Orbit
    2 days ago






  • 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
    yesterday











  • @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
    yesterday













  • @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
    yesterday

















If you want backwards compatibility then this is a must.

– Lightness Races in Orbit
2 days ago





If you want backwards compatibility then this is a must.

– Lightness Races in Orbit
2 days ago




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
yesterday





@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
yesterday













@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
yesterday







@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
yesterday















@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
yesterday





@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
yesterday











6














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





















  • 1





    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
    2 days ago













  • @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
    yesterday











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

    – Lightness Races in Orbit
    yesterday
















6














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





















  • 1





    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
    2 days ago













  • @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
    yesterday











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

    – Lightness Races in Orbit
    yesterday














6












6








6







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 yesterday

























answered 2 days ago









hsalimihsalimi

4,67022350




4,67022350








  • 1





    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
    2 days ago













  • @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
    yesterday











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

    – Lightness Races in Orbit
    yesterday














  • 1





    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
    2 days ago













  • @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
    yesterday











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

    – Lightness Races in Orbit
    yesterday








1




1





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
2 days ago







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
2 days ago















@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
yesterday





@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
yesterday













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

– Lightness Races in Orbit
yesterday





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

– Lightness Races in Orbit
yesterday


















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

"Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

Alcedinidae

RAC Tourist Trophy