#
.net開源項目
http://www.cnblogs.com/apollo086574/archive/2007/10/06/915298.html
列數.NET開源項目 paint
http://www.getpaint.net/index.htmlAbout Apache log4net
log4net is a tool to help the programmer output log statements to a variety of output targets. log4net is a port of the excellent log4j framework to the .NET runtime. We have kept the framework similar in spirit to the original log4j while taking advantage of new features in the .NET runtime. For more information on log4net see the features document.
log4net is part of the Apache Logging Services project. The Logging Services project is intended to provide cross-language logging services for purposes of application debugging and auditing.
http://logging.apache.org/log4net/download.htmlNunit
對應Java中的Junit，非常著名的單元測試工具。
鏈接：http://www.nunit.org/Nlog
一個日志管理庫，類似于Log4Net。
鏈接：http://www.nlog-project.org/
class test
{
public:
void (test::*p)();
void Print(){cout<<"Test"<<endl;}
test(){p = &test::Print;}
};
void (test::*q)();
標準C++編程：虛函數與內聯
Josée Lajoie and Stanley Lippman
------------------------------------------------------------------------------
----
[This is the last installment of a column that was being published in C++ Repo
rt magazine. Since the magazine ceased publication before this installment cou
ld be published, Josée Lajoie and Stan Lippman were gracious enough to let us
publish it on the CUJ website. — mb]
曾經，我們常常在談及C++時聽到一個問題：“虛函數真的應該被申明為內聯嗎？”現在，
我們很少再聽到這個問題了。反過來，我們現在聽到的是“你不應該將print()函數內聯。
將虛函數申明為內聯是錯誤的。”
這么說有兩個主要理由：(1)虛函數是在運行期判決的，而內聯是編譯期行為，所以不能從
這個（內聯）申明上得到任何好處；(2)將虛函數申明為內聯將造成此函數在可執行文件中
有多份拷貝，因此我們為一個無論如何都不能內聯的函數付出了在空間上的處罰（WQ注，
所謂的內聯函數非內聯問題）。顯然沒腦子。
只是它并不真的正確。反思一下理由(1)：在很多情況下，虛函數是靜態判決的－－尤其是
派生類的虛函數調用它的基類版本時。為什么會那么做？封裝。一個很好的例子是析構函
數的靜態調用鏈：基類的析構函數被派生類的析構函數觸發。除了最初的一個外，所有的
析構函數的調用都是被靜態判決的。不讓基類的虛析構函數內聯，就不能從中獲益。這會
造成很大的差別嗎？如果繼承層次很深，而又有大量的對象需要析構，（答案是）“是的
”。
另外一個例子不涉及析構函數。想像我們正在設計一個圖書館出借管理程序。我們已經將
“位置”放入抽象類LibraryMaterial。當申明print()函數為純虛函數時，我們也提供其
定義：打印出對象的位置。
class LibraryMaterial {
private:
MaterialLocation _loc; // shared data
// ...
public:
// declares pure virtual function
inline virtual void print( ostream& = cout ) = 0;
};
// we actually want to encapsulate the handling of the
// location of the material within a base class
// LibraryMaterial print() method - we just don’t want it
// invoked through the virtual interface. That is, it is
// only to be invoked within a derived class print() method
inline void
LibraryMaterial::
print( ostream &os ) { os << _loc; }
接著引入Book類；它的print()函數會輸出書名、作者等等。在此之前，它先調用基類的L
ibraryMaterial::print()函數以顯示位置信息。例如：
inline void
Book::
print( ostream &os )
{
// ok, this is resolved statically,
// and therefore is inline expanded ...
LibraryMaterial::print();
os << "title:" << _title
<< "author" << _author << endl;
}
AudioBook類從Book派生，引入了一個二選一的借出策略，并且加入了一些附加信息，比如
講解員、格式等等。這些都將在它的print()函數中顯示出來。在顯示這些以前，它先調用
Book::print()：
inline void
AudioBook::
print( ostream &os )
{
// ok, this is resolved statically,
// and therefore is inline expanded ...
Book::print();
os << "narrator:" << _narrator << endl;
}
在這個例子和析構函數的例子中，派生類的虛方法遞增式地擴展其基類版本的功能，并以
調用鏈的方式被調用，只有最初一次調用是由虛體系決定的。這個沒有被命名的繼承樹設
計模式，如果從不將虛函數申明為內聯的話，顯然會有些低效。
關于理由(2)的代碼膨脹問題怎么說？好吧，思考一下。如果寫出，
LibraryMaterial *p =
new AudioBook( "Mason & Dixon",
"Thomas Pynchon", "Johnny Depp" );
// ...
p->print();
此處的print()會內聯嗎？不，當然不會。這必須在運行期經過虛體系的判決。Okay。它會
導致此處的print()函數有它自己的定義體嗎？也不會。調用被編譯為類似于這種形式：
// Pseudo C++ Code
// Possible transformation of p->print()
( *p->_vptr[ 2 ] )( p );
那個2是print()函數在相應的虛函數表中的位置。因為這個對print()的調用是通過函數指
針_vptr[2]進行的，編譯器不能靜態決定被調用函數的位置，并且函數不能被內聯。
當然，內聯的虛函數print()的定義必須出現在可執行文件中的某處，代碼才能正確執行。
也就是說，至少需要一個定義體，以便將它的地址放入虛函數表。編譯器如何決定何時產
生那一個定義體的呢？一個實現策略是在產生那類的虛函數表時同時產生那個定義體。這
意味著針對為一個類所生成的每個虛函數表實例，每個內聯的虛函數的一個實例也被產生
。
在可執行文件中，為一個類產生的虛函數表，實際上有多少個？啊，很好，問得好。C++標
準規定了虛函數在行為上的要求；但它沒有規定實現虛函數上的要求。既然虛函數表的存
在不是C++標準所要求的，明顯標準也沒有進一步要求如何處理虛函數表以及生成多少次。
最佳的數目當然是“一次”。例如，Stroustrup的原始cfront實現版本，在大部份情況下
聰明地達成了這一點。 (Stan和Andy Koenig描述了其算法，發表于1990年3月，C++ Repo
rt，“Optimizing Virtual Tables in C++ Release 2.0.”)
此外，C++標準現在要求內聯函數的行為要滿足好象程序中只存在一個定義體，即使這個函
數可能被定義在不同的文件中。新的規則是說滿足規定的實現版本，行為上應該好象只生
成了一個實例。一旦標準的這一點被廣泛采用，對內聯函數潛在的代碼膨脹問題的關注應
該消失了。
C++社群中存在著一個沖突：教學上需要規則表現為簡單的檢查表vs實踐中需要明智地依據
環境而運用規則。前者是對語言的復雜度的回應；后者，是對我們構造的解決方案的復雜
度的回應。何時將虛函數申明為內聯的問題，是這種沖突的一個很好的例證。
About the Authors
Stanley Lippman was the software Technical Director for the Firebird segment o
f Disney's Fantasia 2000. He was recently technical lead on the ToonShooter im
age capture and playback system under Linux for DreamWorks Feature Animation a
nd consulted with the Jet Propulsion Laboratory. He is currently IT Training P
rogram Chair for You-niversity.com, an e-learning training company. He can be
reached at stanleyl@you-niversity, www.you-niversity.com, and www.objectwrite.
com.
Josée Lajoie is currently doing her Master's degree in Computer Graphics at t
he University Waterloo. Previously, she was a member of the C/C++ compiler dev
elopment team at the IBM Canada Laboratory and was the chair of the core langu
age working group for the ANSI/ISO C++ Standard Committee. She can be reached
at jlajoie@cgl.uwaterloo.ca.
類的成員函數分為兩種，一種是靜態函數，另外一種是非靜態函數。例如：
class X
{
public:
static void display();
bool getValue();
}
display()為靜態函數，getValue即為非靜態函數。兩種函數在使用的時候是不一樣的。靜態函數
可以直接由類名來調用，而非靜態函數則必須通過某一個對象來調用，例如：
X::display();
X x;
x.getValue();
為什么會出現這樣的情況了？這是由于編譯器在處理這兩種函數的方式不同造成的。靜態函數在
運行期只有一份拷貝，所有該類生成的對象共享該函數以及該函數的內部變量。而對于非靜態函數，
不同的對象擁有自己的內部變量。
靜態成員函數與普通成員函數的差別就在于缺少this指針，沒有這個this指針自然也就無從知道name是哪一個對象的成員了。
根據類靜態成員的特性我們可以簡單歸納出幾點，靜態成員的使用范圍：
1.用來保存對象的個數。
2.作為一個標記，標記一些動作是否發生，比如：文件的打開狀態，打印機的使用狀態，等等。
3.存儲鏈表的第一個或者最后一個成員的內存地址。
為了做一些必要的練習，深入的掌握靜態對象的存在的意義，我們以前面的結構體的教程為基礎，用類的方式描述一個線性鏈表，用于存儲若干學生的姓名，代碼如下：
對于靜態成員函數的一些限制
1.靜態成員函數只能引用這個類的其他靜態成員（當然也可以訪問全局函數和數據）。
2.靜態成員函數沒有this指針。
3.同一個函數不能有靜態和非靜態兩種版本，靜態成員函數不可以是虛函數。
4.它們不能被聲明為const或volatile。
靜態成員函數也屬于整個類，所以可以通過使用類名和作用域分辨符被其本身調用（獨立于對象），也可以和對象聯系起來調用。
實際上，靜態成員函數的應用是有限的，使用它的好處是在實際創建任何對象之前可以“預初始化”私有的靜態數據。
在函數調用過程中，會使用堆棧，這三個表示不同的堆棧調用方式和釋放方式。
比如說__cdecl，它是標準的c方法的堆棧調用方式，就是在函數調用時的參數壓入堆棧是與函數的聲明順序相反的，其它兩個可以看MSDN，不過這個對我們編程沒有太大的作用
調用約定
調用約定(Calling convention)決定以下內容：函數參數的壓棧順序，由調用者還是被調用者把參數彈出棧，以及產生函數修飾名的方法。MFC支持以下調用約定：
_cdecl
按從右至左的順序壓參數入棧，由調用者把參數彈出棧。對于"C"函數或者變量，修飾名是在函數名前加下劃線。對于"C++"函數，有所不同。
如函數void test(void)的修飾名是_test；對于不屬于一個類的"C++"全局函數，修飾名是?test@@ZAXXZ。
這是MFC缺省調用約定。由于是調用者負責把參數彈出棧，所以可以給函數定義個數不定的參數，如printf函數。
_stdcall
按從右至左的順序壓參數入棧，由被調用者把參數彈出棧。對于"C"函數或者變量，修飾名以下劃線為前綴，然后是函數名，然后是符號"@"及參數的字節數，如函數int func(int a, double b)的修飾名是_func@12。對于"C++"函數，則有所不同。
所有的Win32 API函數都遵循該約定。
_fastcall
頭兩個DWORD類型或者占更少字節的參數被放入ECX和EDX寄存器，其他剩下的參數按從右到左的順序壓入棧。由被調用者把參數彈出棧，對于"C"函數或者變量，修飾名以"@"為前綴，然后是函數名，接著是符號"@"及參數的字節數，如函數int func(int a, double b)的修飾名是@func@12。對于"C++"函數，有所不同。
未來的編譯器可能使用不同的寄存器來存放參數。
關鍵字 調用規則 參數傳遞方向 返回 參數寄存器 堆棧的清除
__cdecl C調用規則 從右向左 EAX 無 調用者
__fastcall 寄存器 從左向右 EAX EAX、EBX、ECX 被調用者
__stdcall Win32標準 從右向左 EAX 無 被調用者
__pascal Pascal 從左向右 EAX 無 被調用者
__msfastcall Ms寄存器 從右向左 EAX/EDX ECX、EDX 被調用者
C++ Builder中幾種調用規則的比較
1. 名字分解：
沒有名字分解的函數
TestFunction1 // __cdecl calling convention
@TestFunction2 // __fastcall calling convention
TESTFUNCTION3 // __pascal calling convention
TestFunction4 // __stdcall calling convention
有名字分解的函數
@TestFunction1$QV // __cdecl calling convention
@TestFunction2$qv // __fastcall calling convention
TESTFUNCTION3$qqrv // __apscal calling convention
@TestFunction4$qqrv // __stdcall calling convention
使用 extern "C" 不會分解函數名
使用 Impdef MyLib.def MyLib.dll 生成 def 文件查看是否使用了名字分解
2. 調用約定：
__cdecl 缺省
是 Borland C++ 的缺省的 C 格式命名約定，它在標識符前加一下劃線，以保留
它原來所有的全程標識符。參數按最右邊參數優先的原則傳遞給棧，然后清棧。
extaern "C" bool __cdecl TestFunction();
在 def 文件中顯示為
TestFunction @1
注釋： @1 表示函數的順序數，將在“使用別名”時使用。
__pascal Pascal格式
這時函數名全部變成大寫，第一個參數先壓棧，然后清棧。
TESTFUNCTION @1 //def file
__stdcall 標準調用
最后一個參數先壓棧，然后清棧。
TestFunction @1 //def file
__fastcall 把參數傳遞給寄存器
第一個參數先壓棧，然后清棧。
@TestFunction @1 //def file
3. 解決調用約定：
Microsoft 與 Borland 的 __stdcall 之間的區別是命名方式。 Borland 采用
__stdcall 的方式去掉了名字起前的下劃線。 Microsoft 則是在前加上下劃線，在
后加上 @ ，再后跟為棧保留的字節數。字節數取決于參數在棧所占的空間。每一個
參數都舍入為 4 的倍數加起來。這種 Miocrosoft 的 Dll 與系統的 Dll 不一樣。
4. 使用別名：
使用別名的目的是使調用文件 .OBJ 與 DLL 的 .DEF 文件相匹配。如果還沒有
.DEF 文件，就應該先建一個。然后把 DEF 文件加入 Project。使用別名應不斷
修改外部錯誤，如果沒有，還需要將 IMPORTS 部分加入 DEF 文件。
IMPORTS
TESTFUNCTIOM4 = dllprj.TestFunction4
TESTFUNCTIOM5 = dllprj.WEP @500
TESTFUNCTIOM6 = dllprj.GETHOSTBYADDR @51
這里需要說明的是，調用應用程序的 .OBJ 名與 DLL 的 .DEF 文件名是等價的，
而且總是這樣。甚至不用考慮調用約定，它會自動匹配。在前面的例子中，函數被
說明為 __pascal，因此產生了大寫函數名。這樣鏈接程序不會出錯。
其他連接
http://blog.csdn.net/lotomer/archive/2006/06/28/844658.aspx
C++編程規范
利器在手,不要再徒手為之
C++語言所強制施行的構造函數/析構函數對稱反映了資源獲取/釋放函數對,比如fopen/fclose, lock/unlock, new/delete, malloc/free的本質的對稱性,這使得具有資源獲取的構造函數和具有資源釋放的析構函數的基于棧(或引用計數)的對象成為了自動化資源管理和清除的極佳工具
auto_ptr 實現代碼
auto_ptr實現代碼 (摘自<<More Effective c++>> Page 293)2006年09月11日 星期一 20:24template <class T>
class auto_ptr
{
public:
explicit auto_ptr(T*p = 0) : pointee(p){}
template<class U> auto_ptr(auto_ptr<U>& r);
~auto_ptr(){delete pointee;}
template<class U> auto_ptr<T>& operator=(auto_ptr<U>& r);
T& operator*() const {return *pointee;}
T* operator->() const {return pointee;}
T* get() const {return pointee;}
T* release(){
T* old = pointee;
pointee = 0;
return old;
}
void reset(T*p = 0){
if(pointee != p) {
delete pointee;
pointee = p;
}
}
private:
T* pointee;
template<class U> friend class auto_ptr<U>;
};
template<class T>
template<class U>
inline auto_ptr<T>::auto_ptr(auto_ptr<U>& r)
: pointee(r.release()) {}
template<class T>
template<class U>
inline auto_ptr<T>& operator=(auto_ptr<U>& r){
if(this != &r) reset(r.release());
return *this;
}
另外 SGI C++中的auto_ptr
/*
* Copyright (c) 1997
* Silicon Graphics Computer Systems, Inc.
*
* Permission to use, copy, modify, distribute and sell this software
* and its documentation for any purpose is hereby granted without fee,
* provided that the above copyright notice appear in all copies and
* that both that copyright notice and this permission notice appear
* in supporting documentation. Silicon Graphics makes no
* representations about the suitability of this software for any
* purpose. It is provided "as is" without express or implied warranty.
*
*/
#ifndef __SGI_STL_MEMORY
#define __SGI_STL_MEMORY
#include <stl_algobase.h>
#include <stl_alloc.h>
#include <stl_construct.h>
#include <stl_tempbuf.h>
#include <stl_uninitialized.h>
#include <stl_raw_storage_iter.h>
#if defined(__STL_MEMBER_TEMPLATES)
__STL_BEGIN_NAMESPACE
template <class _Tp> class auto_ptr {
private:
_Tp* _M_ptr;
public:
typedef _Tp element_type;
explicit auto_ptr(_Tp* __p = 0) __STL_NOTHROW : _M_ptr(__p) {}
auto_ptr(auto_ptr& __a) __STL_NOTHROW : _M_ptr(__a.release()) {}
template <class _Tp1> auto_ptr(auto_ptr<_Tp1>& __a) __STL_NOTHROW
: _M_ptr(__a.release()) {}
auto_ptr& operator=(auto_ptr& __a) __STL_NOTHROW {
if (&__a != this) {
delete _M_ptr;
_M_ptr = __a.release();
}
return *this;
}
template <class _Tp1>
auto_ptr& operator=(auto_ptr<_Tp1>& __a) __STL_NOTHROW {
if (__a.get() != this->get()) {
delete _M_ptr;
_M_ptr = __a.release();
}
return *this;
}
~auto_ptr() __STL_NOTHROW { delete _M_ptr; }
_Tp& operator*() const __STL_NOTHROW {
return *_M_ptr;
}
_Tp* operator->() const __STL_NOTHROW {
return _M_ptr;
}
_Tp* get() const __STL_NOTHROW {
return _M_ptr;
}
_Tp* release() __STL_NOTHROW {
_Tp* __tmp = _M_ptr;
_M_ptr = 0;
return __tmp;
}
void reset(_Tp* __p = 0) __STL_NOTHROW {
delete _M_ptr;
_M_ptr = __p;
}
// According to the C++ standard, these conversions are required. Most
// present-day compilers, however, do not enforce that requirement---and,
// in fact, most present-day compilers do not support the language
// features that these conversions rely on.
#ifdef __SGI_STL_USE_AUTO_PTR_CONVERSIONS
private:
template<class _Tp1> struct auto_ptr_ref {
_Tp1* _M_ptr;
auto_ptr_ref(_Tp1* __p) : _M_ptr(__p) {}
};
public:
auto_ptr(auto_ptr_ref<_Tp> __ref) __STL_NOTHROW
: _M_ptr(__ref._M_ptr) {}
template <class _Tp1> operator auto_ptr_ref<_Tp1>() __STL_NOTHROW
{ return auto_ptr_ref<_Tp>(this->release()); }
template <class _Tp1> operator auto_ptr<_Tp1>() __STL_NOTHROW
{ return auto_ptr<_Tp1>(this->release()); }
#endif /* __SGI_STL_USE_AUTO_PTR_CONVERSIONS */
};
__STL_END_NAMESPACE
#endif /* member templates */
#endif /* __SGI_STL_MEMORY */
// Local Variables:
// mode:C++
// End:
auto_ptr 注意事項
1.auto_ptr不能共享管理的指針的所有權，并且指針是從堆上分配的
2.不能用于管理指針數組，因為它在析構的時候調用的是delete而不是delete[]；并且c++類庫中還沒有具有auto_ptr語意學的指針數組。
3.auto_ptr是解決特殊問題的智能指針的一種，它和引入了引用記數的是智能指針是不一樣的，一般來講，根據auto_ptr的特性，應用unconstant是一種不安全的做法。
4.它不能應用容器中，因為這會涉及到copy以及assignment，這是不安全的，在語言以及庫中已經做了預防，會在編譯時報錯。
總體來說如果把auto_ptr作為函數自變量或者返回值來用的話，就好像把函數內棧上分配的空間地址返回，很不安全。