Avoiding default copy constructor and assignment operator..


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 4 of 4

Thread: Avoiding default copy constructor and assignment operator..

  1. #1
    Join Date
    Oct 2005
    Posts
    22

    Question 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:
    class ClassName
    {
    public:
    ClassName(); //the default constructor
    private:
    //Degenerate copy and assignment
    ClassName(const Classname&);
    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:

  2. #2
    Join Date
    Nov 2003
    Posts
    4,118
    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:

    Code:
    struct S
    {
    int x;
    double array[4];
    };
    
    void f(S); //pass by value
    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:

    Code:
    S s;
    f(s); //create an excat copy of s, pass the copy to f
    So the best solution is to pass the objects by reference.
    BTW, could it be that the article you mentioned was this ?
    Danny Kalev

  3. #3
    Join Date
    Oct 2005
    Posts
    22

    Smile Re: Danny..degenerated copy constructor and assignment operator!

    Quote Originally Posted by Danny
    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:

    Code:
    struct S
    {
    int x;
    double array[4];
    };
    
    void f(S); //pass by value
    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:

    Code:
    S s;
    f(s); //create an excat copy of s, pass the copy to f
    So the best solution is to pass the objects by reference.
    BTW, could it be that the article you mentioned was this ?
    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

    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.

  4. #4
    Join Date
    Nov 2003
    Posts
    4,118
    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.
    Danny Kalev

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center