青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 9, comments - 0, trackbacks - 0, articles - 0
  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

2013年5月17日

  • 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.

posted @ 2013-05-17 15:00 魏尚堂 閱讀(156) | 評論 (0)編輯 收藏

This is only a convention; code that doesn't follow it will compile. However, the convention is followed by all the built-in types as well as by all the types in  the standard library (e.g., string, vector, complex, tr1::shared_ptr, etc.). Unless you have a good reason for doing things differently, don't.

posted @ 2013-05-17 12:06 魏尚堂 閱讀(157) | 評論 (0)編輯 收藏

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 <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.

posted @ 2013-05-17 11:27 魏尚堂 閱讀(221) | 評論 (0)編輯 收藏

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>
#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++
[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

posted @ 2013-05-17 10:56 魏尚堂 閱讀(158) | 評論 (0)編輯 收藏

2013年5月13日

1, Declare destructors virtual in polymorphic base classes
why ? because C++ specifies that when a derived class object is deleted through a pointer to a base class with a non-virtual destructor, results are undefined.What typically happens at runtime is that the derived part of the object is never destroyed

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.


 
 

posted @ 2013-05-13 14:45 魏尚堂 閱讀(230) | 評論 (0)編輯 收藏

2013年1月24日

thinking in c++ 有下面的例子,不太理解為什么這個宏中的條件表達式在編譯時就執(zhí)行了,在此作個記號

// 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;
}

posted @ 2013-01-24 10:26 魏尚堂 閱讀(681) | 評論 (0)編輯 收藏

2013年1月21日

template <typename T> class dataList
{
   public:
      friend ostream& operator<<(ostream& outStream, const dataList <T> &outList);
}
template <typename T> ostream& operator<<(ostream& outStream, const dataList <T> &outList)
{
   //....
   return outStream;
}
int main(int argc, char* argv[])
{
   dataList <int> testList;
   cout << testList;
}
這個程序員是鏈接不過,
錯誤信息:
 warning: friend declaration âstd::ostream& operator<<(std::ostream&, const dataList<T>&)â declares a non-template function
 note: (if this is not what you intended, make sure the function template has already been declared and add <> after the function name here)
/tmp/cc9DSuka.o: In function `main':
undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, dataList<int> const&)'
collect2: ld returned 1 exit status
錯誤原因解釋

The problem is that the compiler is not trying to use the templated operator<< you provided, but rather a non-templated version.

When you declare a friend inside a class you are injecting the declaration of that function in the enclosing scope. The following code has the effect of declaring (and not defining) a free function that takes a non_template_test argument by constant reference:

class non_template_test { friend void f( non_template_test const & ); }; // declares here: // void f( non_template_test const & );

The same happens with template classes, even if in this case it is a little less intuitive. When you declare (and not define) a friend function within the template class body, you are declaring a free function with that exact arguments. Note that you are declaring a function, not a template function:

template<typename T> class template_test { friend void f( template_test<T> const & t ); }; // for each instantiating type T (int, double...) declares: // void f( template_test<int> const & ); // void f( template_test<double> const & );  int main() {     template_test<int> t1;     template_test<double> t2; }

Those free functions are declared but not defined. The tricky part here is that those free functions are not a template, but regular free functions being declared. When you add the template function into the mix you get:

template<typename T> class template_test { friend void f( template_test<T> const & ); }; // when instantiated with int, implicitly declares: // void f( template_test<int> const & );  template <typename T> void f( template_test<T> const & x ) {} // 1  int main() {    template_test<int> t1;    f( t1 ); }

When the compiler hits the main function it instantiates the template template_test with type intand that declares the free function void f( template_test<int> const & ) that is not templated. When it finds the call f( t1 ) there are two f symbols that match: the non-template f( template_test<int> const & ) declared (and not defined) when template_test was instantiated and the templated version that is both declared and defined at 1. The non-templated version takes precedence and the compiler matches it.

When the linker tries to resolve the non-templated version of f it cannot find the symbol and it thus fails.

What can we do? There are two different solutions. In the first case we make the compiler provide non-templated functions for each instantiating type. In the second case we declare the templated version as a friend. They are subtly different, but in most cases equivalent.

Having the compiler generate the non-templated functions for us:

template <typename T> class test  { friend void f( test<T> const & ) {} }; // implicitly

This has the effect of creating as many non-templated free functions as needed. When the compiler finds the friend declaration within the template test it not only finds the declaration but also the implementation and adds both to the enclosing scope.

Making the templated version a friend

To make the template a friend we must have it already declared and tell the compiler that the friend we want is actually a template and not a non-templated free function:

template <typename T> class test; // forward declare the template class template <typename T> void f( test<T> const& ); // forward declare the template template <typename T> class test { friend void f<>( test<T> const& ); // declare f<T>( test<T> const &) a friend }; template <typename T> void f( test<T> const & ) {}

In this case, prior to declaring f as a template we must forward declare the template. To declare the ftemplate we must first forward declare the test template. The friend declaration is modified to include the angle brackets that identify that the element we are making a friend is actually a template and not a free function.
引用自 http://stackoverflow.com/questions/1810753/overloading-operator-for-a-templated-class
從上面我可以學到一點:
1, 編譯器匹配方法時非模板函數(shù)優(yōu)先模板函數(shù)
2, 友元函數(shù)模板必須提前聲明

posted @ 2013-01-21 10:48 魏尚堂 閱讀(604) | 評論 (0)編輯 收藏

2013年1月17日

Linux Shell的通配符與正則表達式 http://blog.csdn.net/chen_dx/article/details/2463495

posted @ 2013-01-17 14:01 魏尚堂 閱讀(162) | 評論 (0)編輯 收藏

2012年11月27日

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

posted @ 2012-11-27 10:03 魏尚堂 閱讀(150) | 評論 (0)編輯 收藏

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲精选在线观看| 欧美精品一区二区三区蜜臀| 久久精品男女| 亚洲新中文字幕| 夜夜嗨av色综合久久久综合网| 136国产福利精品导航网址应用 | 亚洲人成77777在线观看网| 国产精品五区| 国产精品成人在线观看| 国产精品va在线播放| 欧美色图天堂网| 欧美日韩精品一区二区三区四区| 欧美日韩一区二区三区在线| 欧美日韩免费观看一区三区| 欧美视频一区二区三区在线观看| 欧美三级黄美女| 久久久亚洲高清| 久久久蜜桃一区二区人| 欧美刺激午夜性久久久久久久| 欧美国产日本韩| 欧美体内she精视频在线观看| 国产精品99一区二区| 国产欧美精品一区二区色综合| 国产一区香蕉久久| 亚洲国产精品成人va在线观看| 亚洲精品乱码| 亚洲专区一区| 久久青青草原一区二区| 亚洲欧洲精品一区二区| 在线观看视频一区二区| 亚洲国产成人精品女人久久久| 伊人成综合网伊人222| 亚洲老司机av| 欧美一区二区三区男人的天堂| 久久综合激情| 亚洲免费精品| 久久久久88色偷偷免费| 欧美精品麻豆| 国内精品一区二区三区| 一本久道久久久| 久久久久网站| 一区二区三区免费观看| 久久综合一区| 国产香蕉97碰碰久久人人| 亚洲每日在线| 麻豆精品视频在线观看| 国产精品99久久99久久久二8| 老司机凹凸av亚洲导航| 国产精品一区二区三区观看| 亚洲欧洲精品成人久久奇米网 | 欧美紧缚bdsm在线视频| 国产视频不卡| 亚洲一区在线播放| 亚洲第一精品夜夜躁人人躁 | 欧美成年人视频网站| 国产精品一区二区三区四区| 99亚洲精品| 亚洲欧美在线免费观看| 亚洲裸体俱乐部裸体舞表演av| 久久黄金**| 亚洲精品美女91| 欧美福利视频在线观看| 国内视频精品| 久久久青草婷婷精品综合日韩| 亚洲一区三区电影在线观看| 欧美精品v日韩精品v韩国精品v| 黄色成人在线| 久久综合电影| 久久成人免费日本黄色| 国产日本欧美视频| 久久免费视频观看| 久久久久国内| 在线成人www免费观看视频| 久久婷婷国产综合精品青草| 亚洲欧美一区二区三区在线| 国产精品久久久久久av福利软件 | 欧美伊人久久久久久久久影院| 国产伦精品一区二区| 亚洲欧美在线另类| 午夜精品在线视频| 久久久久久91香蕉国产| 久久精品国产免费观看| 国产亚洲激情在线| 久久综合免费视频影院| 久久久91精品| 亚洲激情视频网| 欧美激情在线播放| 欧美日本在线一区| 亚洲欧美日韩国产综合在线| 亚洲新中文字幕| 国产亚洲精品久久久久久| 久久久精品国产一区二区三区 | 午夜在线观看免费一区| 国产女精品视频网站免费| 久久久99久久精品女同性| 久久精品欧美| 亚洲精品之草原avav久久| 一本色道久久精品| 国产欧美一区二区在线观看| 国产日产欧美a一级在线| 久久精品女人| 欧美精品播放| 久久久噜噜噜久久| 欧美大片免费久久精品三p | 亚洲国内欧美| 国产精品久久网| 久久久最新网址| 欧美成人免费在线观看| 亚洲欧美一区二区三区在线 | 久久久青草婷婷精品综合日韩| 亚洲电影有码| 亚洲性线免费观看视频成熟| 一色屋精品视频在线看| 亚洲精品综合精品自拍| 国产一区二区三区丝袜| 亚洲精品在线观看视频| 国产一区二区三区自拍| 亚洲精品欧美日韩| 狠狠色综合色综合网络| av成人手机在线| 亚洲国产免费看| 性一交一乱一区二区洋洋av| 夜夜嗨一区二区三区| 久久九九99视频| 欧美一区二区三区四区在线观看地址 | 国产一区二区久久精品| 99精品热视频| 亚洲精品少妇| 久久综合一区| 欧美成人免费在线| 黑丝一区二区三区| 午夜视频精品| 午夜在线不卡| 欧美性开放视频| 亚洲精品欧美一区二区三区| 亚洲国产专区| 国产精品最新自拍| 在线性视频日韩欧美| 日韩亚洲欧美成人一区| 老色鬼精品视频在线观看播放| 性做久久久久久| 国产精品久久97| 亚洲作爱视频| 午夜精品偷拍| 国产免费观看久久黄| 亚洲亚洲精品在线观看| 午夜精品视频在线观看| 欧美日韩中文在线观看| 亚洲人妖在线| 99精品视频免费全部在线| 亚洲欧美清纯在线制服| 久久精品成人欧美大片古装| 国产精品高潮呻吟久久av无限| 亚洲成色www8888| 欧美成人综合一区| 亚洲精品护士| 久久精品中文| 久久动漫亚洲| 国产精品无码专区在线观看| 性做久久久久久免费观看欧美| 亚洲一区影音先锋| 国产精品va在线| 亚洲一区二区精品在线观看| 一本色道久久加勒比88综合| 欧美成人亚洲成人| 欧美激情在线狂野欧美精品| 亚洲色图自拍| 国产精品美女黄网| 亚洲一区区二区| 久久精品视频导航| 亚洲电影免费在线观看| 美国十次成人| 亚洲国产欧美日韩精品| 亚洲国产精品va在线观看黑人| 欧美精品在线观看91| 亚洲激情视频网站| 亚洲六月丁香色婷婷综合久久| 久久中文字幕一区二区三区| 美女在线一区二区| 亚洲视屏在线播放| 国产精品入口日韩视频大尺度| 在线视频日韩| 久久精品视频在线观看| 日韩视频永久免费| 欧美日韩国产专区| 亚洲免费在线播放| 久久亚洲高清| 欧美一区二区在线播放| 在线成人黄色| 欧美精品一区二| 亚洲小说区图片区| 亚洲国产三级网| 亚洲欧美美女| 国模套图日韩精品一区二区| 久久久久五月天| 亚洲国产精品t66y| 亚洲欧美日韩另类精品一区二区三区| 国产精品国产三级国产普通话三级 | 久久精品99国产精品酒店日本| 经典三级久久|