-
Make sure operator= is well-behaved when an object is assigned to itself. Techniques include comparing addresses of source and target objects, careful statement ordering, and copy-and-swap.
-
Make sure that any function operating on more than one object behaves correctly if two or more of the objects are the same.
]]>
]]>
base class constructors execute before derived class constructors, derived class data members have not been initialized when base class constructors run. If virtual functions called during base class construction went down to derived classes, the derived class functions would almost certainly refer to local data members, but those data members would not yet have been initialized.Calling down to parts of an object that have not yet been initialized is inherently dangerous, so C++ gives you no way to do it.
#include <iostream>
#include <iostream>
#include <string>
#include <cstdlib>
void print(std::string str){std::cout << str<< std::endl;}
class Transaction {
public:
Transaction()
{
print("Transaction Constructor");
logTransaction();
}
virtual void logTransaction() const // =0;
{
print("Transaction Log");
}
};
class BuyTransaction: public Transaction
{
public:
BuyTransaction(){ print("BuyTransaction Constructor");}
virtual void logTransaction() const
{
print("BuyTransaction Log");
}
};
int main()
{
BuyTransaction dbc;
//dbc.logTransaction();
}
pure virtual functions cannot link.
[shangtang@BTSOM-1 study]$ g++ TestT.cpp
TestT.cpp: In constructor 'Transaction::Transaction()':
TestT.cpp:14: warning: abstract virtual 'virtual void Transaction::logTransaction() const' called from constructor
/tmp/ccXFzaHv.o: In function `Transaction::Transaction()':
TestT.cpp:(.text._ZN11TransactionC2Ev[Transaction::Transaction()]+0x7f): undefined reference to `Transaction::logTransaction() const'
collect2: ld returned 1 exit status
virtual function can compile, run, but with surprise result
[shangtang@BTSOM-1 study]$ ./a.out
Transaction Constructor
Transaction Log
BuyTransaction Constructor
The only way to avoid this problem is to make sure that none of your constructors or destructors call virtual functions on the object being created or destroyed and that all the functions they call obey the same constraint.
]]>
Depending on the precise conditions under which such pairs of simultaneously active exceptions arise, program execution either terminates or yields undefined behavior. In this example, it yields undefined behavior.
C++ does not like destructors that emit exceptions!
#include <iostream>C++ does not like destructors that emit exceptions!
#include <vector>
struct Exception
{
Exception(){std::cout << "Exception Constructor" << std::endl;}
~Exception(){std::cout << "Exception Destructor" << std::endl;}
};
class Widget {
public:
~Widget() {std::cout << "Widget Destructor" << std::endl; throw Exception();
} //this might emit an exception
void print(){std::cout << "print" << std::endl;}
};
void doSomething();
int main()
{
doSomething();
}
void doSomething()
{
std::vector<Widget> v;
v.push_back(Widget());
v.push_back(Widget());
v.push_back(Widget());
v.push_back(Widget());
std::vector<Widget>::iterator it = v.begin();
while(it != v.end())
{
std::cout << "end" << std::endl;
(*it).print();
it++;
}
}
complie with g++
complie with g++
[shangtang@BTSOM-1 study]$ ./a.out
Widget Destructor
Exception Constructor
terminate called after throwing an instance of 'Exception'
Aborted (core dumped)
There are two primary ways to avoid the trouble.
1, Terminate the program if catch a exception, typically by calling std::abort (cstdlib)
2, Swallow the exception if catch a exception, print a log
1, Terminate the program if catch a exception, typically by calling std::abort (cstdlib)
2, Swallow the exception if catch a exception, print a log
]]>
2, if a class is not intended to be a base class, making the destructor virtual is usually a bad idea.
why? if a class have virtual functions, it has extra overhead(vptr).
3, In fact, many people summarize the situation this way: declare a virtual destructor in a class if and only if that class contains at least one virtual function
4,Sometimes, however, you have a class that you'd like to be abstract, but you don't have any pure virtual functions.
solution: declare pure virtual destructor.
There is one twist, however you must provide a definition for the pure virtual destructor, or linker will complain.
5, Not all base classes are designed to be used polymorphically. Neither the standard string type, for example, nor the STL container typesare designed to be base classes at all, much less polymorphic ones.
]]>
// A simple, compile-time assertion facility
#define STATIC_ASSERT(x) \
do { typedef int a[(x) ? 1 : -1]; } while(0)
int main()
{
STATIC_ASSERT(sizeof(int) <= sizeof(long)); // Passes
STATIC_ASSERT(sizeof(double) <= sizeof(int)); // Fails
return 0;
}
]]>
]]>
Perform every resource allocation (e.g., new) in its own code statement which immediately gives the new resource to a manager object (e.g., auto_ptr).
This guideline is easy to understand and remember, it neatly avoids all of the exception safety problems in the original problem, and by mandating the use of manager objects it helps to avoid many other exception safety problems as well. This guideline is a good candidate for inclusion in your team's coding standards
link http://www.gotw.ca/gotw/056.htm
file I/O http://www.zwqxin.com/archives/cpp/use-sstream.html
]]>