Normally we tend to admire those who can spot the small details that others will not even bother to notice. But sometimes it can be a different situation:
A: So to prevent the copy, here I define a copy constructor but I place it in the private section of the class.
B: (after carefully analyzing the implementation line by line) But you don't implement this copy constructor at all. It's in your class declaration but I can't find it in your .cpp file.
A: No need to do that. I don't want to implement it. I just want to ensure that it won't be called because it's private.
B: (again reading the implementation code) Is there a reason why you won't implement it?
A: (already slightly upset) No specific reason. You can implement an empty construct for that copy constructor in the .cpp file, if you want.
B: Then you'd better write that empty construct. What's so difficult about it? It's better to do that rather than taking the easy way out not to implement the copy constructor.
A: (decides that it is useless to argue) OK.
A ends up being annoyed for the whole day. Not only he wastes his time with this unnecessary hyped drama, he is accused of taking "the easy way out".
This case could also possibly explains why some untrained eyes file a compliant because you did optimize part X of the program but simply skipped part Y. The same eyes did not watch you as you spent few sleepless nights with the profiler.
7 comments:
Some time later:
C: WTF is the point of this copy constructor? I can't see what it's doing that the default copy constructor wouldn't.... 'A's code is rubbish!
Actually not implementing the cctor is an additional safeguard against unwanted object copying (which is still allowed from withing the class). So in case you did do something like
void A::func(A& foo, A& bar)
{
if(foo = bar)
func2();
}
it would result in a linker error. Now it will work, but not as expected.
Anonymous: likely to happen, yes.
Matthias Kretz: very true, fortunately won't occur in the case A and B were discussing. Beside, your explanation will be too complicated for B.
B's inability to understand C++ is not an acceptable excuse for writing bad C++. (A cannot explain C++ either, but that is a different problem, and one that he shared with most programmers)
There actually is a quite neat functionality built in c++ to avoid such confusion and arguments (or at least to try to prevent them).
It's nothing new, but seems not very well known by most progamers (I've met) : it's called "comments".
It allows to attach notes in human readeable format to explain decisions made while writing the code. It could have avoided A and B's argument, or C's if the constructor had been implemented.
/sarcasm (or maybe not ?)
It is _intentional_ to not implement cctors declared private, so that an attempt to copy an object of a thusly built class can be catched at compile time.
Aye, I'd agree that B is missing an important point of C++. User A knows it, but can't explain it.
Classes which should not be copied should declare a copy c'tor and assignment operator, but not implement them. If you don't declare them, you get C++'s default version, which is often a quite surprising (and wrong) one. My solution is to either derive from a base "noncopyable" (which makes the intent clear) or declare them as follows:
B & B(const B &); // not implemented -- do not copy this object!
B & operator==(const B &); // not implemented -- do not copy this object!
Post a Comment