Avoiding default copy constructor and assignment operator..
Recently i got an article somewhere on web about forgetting declaring a parameter type as a pointer while making a function call, then the compiler gladly copies the object onto the stack and calls the function. For a class with a lot of member variable storage, this can be costly in execution time and In stack space.
to avoid this...
In C++ to be able to pass a parameter by value the compiler needs what is called a copy constructor. If your application performs some operation that needs a copy constructor, the compiler will write one for you and call it unless you provide your own. You can prevent the compiler from writing the copy constructor by declaring the copy constructor in the private area of your class, and then not provide an implementation. It is private so that no one can call it (except the class itself), and it is not implemented to make sure it uses no space and cannot even be called by the containing class.
The same problem exists for returning an object by value. The compiler will then need a copy constructor and an assignment operator. You can use the same technique above to declare a private undefined assignment operator and prevent the whole problem.
Every time I create a class in C++ I always start with a class that looks like this:
ClassName(); //the default constructor
//Degenerate copy and assignment
ClassName& operator=(const ClassName&)
Following this simple technique prevents the compiler from writing this code for you and prevents calling the code as well.
what i am not able to understand is...
In the case, when we pass the object by value and also in the case when the object is returned by value and using the above trick, how things work then, i mean how complier will treat these objects which are passed or returned by value, will then there be no copies created and pointers will be used by compiler. how the complier react when it cant make its own versions of copy constructor or assignment operator nor it can use any other, as in above piece of code both are in private and UNimplemented...??? :confused:
First of all, declaring the copy ctor, assignment op etc. means that these member functions are probably defined elsewhere. In other words, they do exist and are called when you copy or pass an object by value. If you really want to "degenerate" these member functions, leave them undeclared. This still doesn't guarantee efficient copying, becuase even if there is no explicit initailization isnide the constructor, C++ still has to copy a large chunk of memory for the data members:
When you can f, there's no user-defined constructor that gets called but the compiler still must ensure that the data members of the argument are copied to the function's stack memory:
void f(S); //pass by value
So the best solution is to pass the objects by reference.
f(s); //create an excat copy of s, pass the copy to f
BTW, could it be that the article you mentioned was this ?
Re: Danny..degenerated copy constructor and assignment operator!
Hi Danny, I have read many articles of urs on www.informit.com, but the one i asked my doubt was from http://www.embedded.com/shared/print...icleID=9901135
Originally Posted by Danny
anyway, when i tried to use the degeration mechanism as mentioned in this artcle in my code, i got a compilation error whenever my code was passing object as value to the function, saying that "there is no copy constructor defined". Infact the degeration mechanism was meant so that it prevents the compiler from writing copy constructor and assignment operator code for you and prevents calling the code as well if any defined by the programer from within the class, so as to ensure WHILE PROGRAMING YOU NEVER PASS OR RETURN THE OBJECT BY VALUE, EVEN BY MISTAKE AND HENCE SAVE EXECUTION TIME AND STACK SPACE!!! :)
Last edited by premartha; 10-21-2005 at 12:35 AM.
Degenerating the constructor/copy ector etc. is a very bad idea. In some cases, you do need to pass or return objects by value, e.g., when overloading the + operator. Besides, blocking the copy ctor and assignment operator disables the use of STL containers and algorithms. There are some programming idioms that rely on degenrating these functions, the Singleton Pattern for instance, but as a general technique that is only meant to disable inadevrtent pass by value, this is a bad idea. Besides, when you declare these member functions and not define them, you are likley to get linkage errors (not compilation errors), unless your code elbaorately and cleverly delegates the construction, destruction and copying operations to other member functions, which is sometimes done under very special circumstances, but it's a huge pain and ceryainly not a general design technique that everyone should use.
Last edited by Danny; 10-21-2005 at 10:27 AM.
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL