Copy Constructors , Assignment Operator & Derived Classes - Copying parent class members

Copy Constructors and Derived Classes - Copying parent class members



The default constructor for a derived class calls the base class default constructor implicitly, without an explicit call. However, the copy constructor for a derived class does not call the copy constructor of the base class --- it calls the default zero-argument constructor for the base class.



class Base

{

public:

Base() { cout << "Base constructor\n"; } Base(Base &b) { cout << "Base COPY constructor\n"; } }; class Derived : public Base { public: Derived(Derived &b) { cout << "Derived COPY constructor\n"; } }; main() { Derived d1; Derived d2(d1); // copy constructor } This is not what we usually require; more typically a derived class copy constructor will explicitly invoke the base class copy constructor using the special syntax for passing arguments to a base class. class Base { public: Base(Base &b) { cout << "Base COPY constructor\n"; } }; class Derived : public Base { Derived(Derived &b) : Base(b) { cout << "Derived COPY constructor\n"; } }; The Derived object ``b" is passed to the Base class copy constructor. Note that this involves converting the Derived& reference to a Base& reference --- recall that conversion of a pointer/reference is allowed from Derived down to base, but not the reverse.





Assignment Operators and Derived Classes - Copying parent class members



Similarly to the problem with copy constructors in derived classes, the assignment operator in derived classes does not implicitly call the base class assignment operator. In fact, by default, the private data of the base class will not be modified by the derived class assignment operator.



The solution is an explicit call to the Base class assignment operator which can be achieved via the ``this" special pointer, and a type cast to a reference to a reference to the Base class.



void operator=(Derived &d)

{

(Base&)*this = d; // EXPLICIT CALL // The above copies the Base class data

// Now copy the derived class data ....

}



There are a few other alternative methods of explicit calls, such as:



void operator=(Derived &d)

{

(*this).Base::operator=(d); // EXPLICIT CALL

}



(or)



If there is a parent (base) class, those fields must also be copied.

You can accomplish this with the following cryptic statement,



this->Parent::operator=(source); //where Parent is the name of the base class.



//--- file Parent.h

class Parent {...}; // declaration of base class



//--- file Child.h

#include "Parent.h"

class Child : public Parent { // declaration of derived class

public:

Child& Child::operator=(const Child& source);

};//end class Child



//--- file Child.cpp

#include "Child.h"

Child& Child::operator=(const Child& source) {

if (this != &source) {

this->Parent::operator=(source);

. . . // copy all our own fields here.

}

return *this;

}//end operator=





Methods that are implicitly generated by the compiler if they are not explicitly defined are:



a. Default constructor (C::C())



b. Copy constructor (C::C (const C& rhs))



c. Destructor (C::~C())



d. Assignment operator (C& C::operator= (const C& rhs))



e. Address-of operator (C* C::operator&())



f. Address-of operator (const C* C::operator&() const;)





Private Copy Constructor:



1. Use private copy constructor and assignment operator to avoid object copyingIf you don't want users of your class to be able to assign objects of its type (password string objects are a good example), you can declare a private assignment operator and copy constructor.



Please note that the compiler-synthesized copy constructor and assignment operator are public, therefore, you have to define them explicitly as private members in this case.



2. To make sure we can not pass objects by value only by reference.



Links:



http://www.cs.jcu.edu.au/Subjects/cp3120/1996/Lectures/c++/node92.html



C/C++ Memory Corruption And Memory Leaks - http://www.yolinux.com/TUTORIALS/C++MemoryCorruptionAndMemoryLeaks.html

JAVA CODE REVIEW CHECKLIST

JAVA Code Review CheckList

Error Handling

1. Does the code comply with the accepted Exception Handling Conventions.

a. We need to expand our notion of Exception Handling Conventions.

b. Some method in the call stack needs to handle the exception, so that we don’t display that exception stacktrace to the end user.

2. Does the code make use of exception handling?

a. Exception handling should be consistent throughout the system.

3.Does the code simply catch exceptions and log them?

a. Code should handle exceptions, not just log them.

4.Does the code catch general exception (java.lang.Exception)?

a. Catching general exceptions is commonly regarded as “bad practice”.

5.Does the code correctly impose conditions for “expected” values?

a.For instance, if a method returns null, does the code check for null?

The following code should check for null

Person person = Context.getPersonService().getPerson(personId);

person.getAddress().getStreet();

What should be our policy for detecting null references?

6.Does the code test all error conditions of a method call?

a. Make sure all possible values are tested.

b.Make sure the JUnit test covers all possible values.

Security

1. Does the code appear to pose a security concern?

a. Passwords should not be stored in the code. In fact, we have adopted a policy in which we store passwords in runtime properties files.

b.Connect to other systems securely – i.e. use HTTPS instead of HTTP where possible.

Thread Safeness

1. Does the code practice thread safeness?

a. If objects can be accessed by multiple threads at one time, code altering global variables (static variables) should be enclosed using a synchronization mechanism (synchronized).

b. In general, controllers / servlets should not use static variables.

c. Use synchronization on the smallest unit of code possible. Using synchronization can cause a huge performance penalty, so you should limit its scope by synchronizing only the code that needs to be thread safe.

d. Write access to static variable should be synchronized, but not read access.

e. Even if servlets/controllers are thread-safe, multiple threads can access HttpSession attributes at the same time, so be careful when writing to the session.

f. Use the volatile keyword to warn that compiler that threads may change an instance or class variable – tells compiler not to cache values in register.

g. Release locks in the order they were obtained to avoid deadlock scenarios.

2. Does the code avoid deadlocks?

a. I’m not entirely sure how to detect a deadlock, but we need to make sure we acquire/release locks in a manner that does not cause contention between threads. For instance, if Thread A acquires Lock #1, then Lock #2, then Thread B should not acquire Lock #2, then Lock #1.

b.Avoid calling synchronized methods within synchronized methods.

Resource Leaks

1. Does the code release resources?

a. Close files, database connections, HTTP connections, etc.

2. Does the code release resources more than once?

a. This will sometimes cause an exception to be thrown.

3. Does the code use the most efficient class when dealing with certain resources?

a. For instance, buffered input / output classes.

Miscellaneous:

1.Make sure that we are using StringBuffer if we want to change the contents of a String

2.Always use “.equals” instead of “==” during Object Comparision

3.Use wait()/notify() instead of sleep()

Links:

Checklist: Java Code Review - http://snap.uci.edu/viewXmlFile.jsp?resourceID=1529

http://www.javaworld.com/javaworld/javatips/jw-javatip88.html

http://undergraduate.csse.uwa.edu.au/units/CITS2220/assign2/JavaInspectionCheckList.pdf

http://www.cs.toronto.edu/~sme/CSC444F/handouts/java_checklist.pdf

http://www.deaded.com/staticpages/index.php/codereviewprocess