1 使用RCW和CCW來訪問
是否可以在 .NET 框架程序中使用 COM 對象？
是。您現在部署的任何 COM 組件都可以在托管代碼中使用。通常情況下，所需的調整是完全自動進行的。

特別是，可以使用運行時可調用包裝 (RCW) 從 .NET 框架訪問 COM 組件。此包裝將 COM 組件提供的 COM 接口轉換為與 .NET 框架兼容的接口。對于 OLE 自動化接口，RCW 可以從類型庫中自動生成；對于非 OLE 自動化接口，開發人員可以編寫自定義 RCW，手動將 COM 接口提供的類型映射為與 .NET 框架兼容的類型。

是否可以在 COM 程序中使用 .NET 框架組件？
是。您現在創建的托管類型都可以通過 COM 訪問。通常情況下，所需的配置是完全自動進行的。托管開發環境的某些新特性不能在 COM 中訪問。例如，不能在 COM 中使用靜態方法和參數化構造函數。一般，提前確定給定類型所針對的用戶是一種較好的辦法。如果類型需要在 COM 中使用，您將被限制在使用 COM 可訪問的特性。

默認情況下，托管類型可能是可見的，也可能是不可見的，這由用于編寫托管類型的語言決定。

特別是，可以使用 COM 可調用包裝 (CCW) 從 COM 訪問 .NET 框架組件。這與 RCW（請參閱上一個問題）相似，但它們的方向相反。同樣，如果 .NET 框架開發工具不能自動生成包裝，或者如果自動方式不是您所需要的，則可以開發自定義的 CCW。

msdn enlish:http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/default.aspx#S1

使用ildasm 和ilasm反編譯之后,去掉publickey 和.permissionset linkcheck
就可以正常引用了.
聽說VS有自帶的簡單的混淆器咋個啟用方法呀？
這個方法很容易破
用ildasm反編譯后把頭部的強名稱刪掉再用ilasm編譯回去就能用了
方法不錯，值得鼓勵。MS的ReportingService里面就是這么干的，盡管可以用ILDasm來破解掉單個Assembly，但是當整個系統都采用這個策略的時候，全部破解很費精力。

恩,是有警告,說不能返回局部指針,也就是棧上的指針

直接編譯:需要
#include <stdio.h>
#include <tchar.h>

也可以看看這個:也許說的更明白點:
http://www.sozz.cn/00136/40946.htm

http://www.xoreax.com/main.htm

c++的能夠縮短編譯時間.好工具

謝謝樓上的!

死循環????為什么不執行循環里的輸入語句cin >> a;和cin >> b;???

輸入字符或字符串的時候會.................

GetTickCount()和GetCurrentTime()都只精確到55ms(1個tick就是55ms)。如果要精確到毫秒，應該使用timeGetTime函數或QueryPerformanceCounter函數。
雖然timeGetTime返回值的單位是1ms，但實際上它的精度只有10ms左右。
如果想提高精度，可以使用QueryPerformanceCounter和QueryPerformanceFrequency。這兩個函數不是在每個系統中都支持。對于支持它們的系統中，可以獲得低于1ms的精度。Windows 內部有一個精度非常高的定時器, 精度在微秒級, 但不同的系統這個定時器的頻率不同, 這個頻率與硬件和操作系統都可能有關。利用 API 函數 QueryPerformanceFrequency 可以得到這個定時器的頻率。利用 API 函數 QueryPerformanceCounter 可以得到定時器的當前值。根據要延時的時間和定時器的頻率, 可以算出要延時的時間定時器經過的周期數。在循環里用 QueryPerformanceCounter 不停的讀出定時器值, 一直到經過了指定周期數再結束循環, 就達到了高精度延時的目的。

原文:http://www.microsoft.com/china/msdn/library/langtool/vsts/sentvstsover.mspx?mfr=true

原文:http://www.microsoft.com/china/msdn/library/langtool/vsts/sentvstsover.mspx?mfr=true

原文:http://www.microsoft.com/china/msdn/library/langtool/vsts/sentvstsover.mspx?mfr=true

vista開發社區: http://devreadiness.org/default.aspx

紋理類
在托管的 Direct3D 中，與紋理相關的類從抽象類 Resource 繼承，并且在極大程度上在與紋理相關的非托管接口上建立層。托管的 Direct3D 有三個紋理類：Texture、CubeTexture 和 VolumeTexture。Texture 類表示可映射到基元上的圖像，用于呈現或用于凹凸貼圖、法線貼圖或其他效果。紋理的基本函數用于將一對紋理坐標映射到某個值（通常是顏色值），但是可以通過其他方式進行解釋。紋理坐標通常是頂點數據的一部分。紋理坐標到顏色或其他值的映射是在呈現管線的像素處理階段完成的。Direct3D 允許一次最多使用八個紋理。CubeTexture 類是用于立方體環境貼圖的特殊種類的紋理，立方體環境貼圖這種技術允許環境（如室內或外景）由反光物體反射出來，這是通過以下方法來實現的：使用紋理來為立方體周圍的六個面各定義一個圖像，并由所呈現的物體來反射。VolumeTexture 類表示存在于三維矩形空間中的顏色或其他值。同樣，它將紋理坐標的三元組映射到顏色或其他值。這些類最重要的方面是，它們都支持一組用于鎖定和取消鎖定紋理的重載方法。

經常用于加載和保存紋理的類是 TextureLoader。TextureLoader 類包含用來從文件或流加載紋理、立方體紋理或體積紋理的方法。TextureLoader 類的其他用法包括填充和篩選紋理以及計算法線貼圖。用來創建紋理的有用的 helper 方法由 GraphicsUtility 類提供：文件的 GraphicsUtility.CreateTexture 方法只是查找指定紋理的路徑，然后調用 TextureLoader.FromFile 方法以加載它。以下代碼說明了 GraphicsUtility 類的用法：

Texture texture = GraphicsUtility.CreateTexture(device,"banana.bmp");

設備類
托管的 Direct3D 提供了基于類的設備抽象，該抽象是通過使用非托管的 IDirect3DDevice9 接口實現的。編寫 Direct3D 托管代碼的程序員使用 Device 類的方法來訪問其他 Direct3D 對象，以便設置各種圖形狀態并呈現幾何形狀。為了執行這些函數，Device 類提供了許多屬性、方法和事件。圖 2 列出了 Device 類最重要的方法，這些方法由 3D 應用程序調用。

談到對象激活，一種觀點認為，非托管的 Direct3D 之所以使用工廠方法，只是因為 COM 不支持新運算符。COM 的標準激活模式是基于工廠的構造。CoCreateInstance 函數模仿 COM 的新運算符，但它只是一個在內部使用 COM 工廠的包裝。使用工廠（相對于新運算符）的另一個原理就是，在使用新運算符時，需要將對象的特定實現綁定到客戶端的代碼中；因此，如果大量使用新運算符，可能會導致版本控制問題。工廠方法通常用于將代碼的客戶端或用戶與代碼的創建者去耦。非托管的 COM IDirect3DDevice9 接口提供 14 種顯式工廠方法，以便創建在使用 Direct3D 時需要的對象（如像素和頂點 Shader 以及頂點和索引緩沖區）。

目前，托管的 Direct3D 在很大程度上依賴于使用新運算符來構造類。盡管 Device 托管類只提供三種工廠方法，但是，一個值得注意的有趣現象是，非托管的 IDirect3DDevice9 工廠方法和由 Device 類公開的公共屬性之間存在一對一關聯。以下代碼行說明了由 Device 托管類公開的三種工廠方法，每種方法都使用多個參數：

public Surface CreateRenderTarget(...);
public Surface CreateDepthStencilSurface(...);
public Surface CreateOffscreenPlainSurface(...);

在托管的 Direct3D 中大量使用方法重載。下面的代碼示例說明了非托管的 Device.ColorFill 方法及其托管的重載包裝：

typedef DWORD D3DCOLOR;

// Methods from the unmanaged IDirect3DDevice9 interface.
HRESULT ColorFill(IDirect3DSurface9 *pSurface, CONST RECT *pRect,
D3DCOLOR color);

// Methods from the managed Device class.
public void ColorFill(Surface surface, Rectangle rect, Color color);
public void ColorFill(Surface surface, Rectangle rect, int color);

與傳統的圖形系統一樣，非托管的 Direct3D 需要將顏色值作為 32 位整數值在內部傳遞。另一方面，Microsoft .NET Framework 顯式提供用來處理 ARGB 顏色值的 System.Drawing.Color 類，其中包含幾種用來在不同表示形式之間進行轉換的方法。為方便那些已習慣于使用整數值來表示顏色的程序員，托管的 Direct3D 在需要顏色參數時使用這兩種表示形式來提供方法重載。

非托管的 IDirect3DDevice9 接口既公開只讀屬性，又公開讀寫屬性，這兩種屬性都可以帶參數，也可以不帶參數。在最新版本的 .NET Framework 中，屬性不帶參數。因此，在將非托管的 Direct3D 映射到托管的 Direct3D 時，不使用參數的屬性可以很好地映射到 C# 屬性，而使用參數的 Direct3D 非托管屬性只作為 Get 和 Set 方法公開。圖 3 列出了 Device 類的一些最重要的屬性。

最后，Direct3D Device 托管類提供了五個用來與設備進行交互的顯式事件。基于 Direct3D 的應用程序可以通過以下方法來將事件作為 Device 的來源：啟動應用程序、調整窗口的大小、從窗口模式更改到全屏模式或者退出應用程序。一個有趣的發現是由 Direct3D 使用的基于 .NET 委托的事件模式。對于 Device 類的每個事件聲明，提供了添加、刪除和引發方法，以及用來存儲事件處理程序的私有實例變量。在 C# 中，客戶端事件注冊和注銷的語法形式分別是通過 += 和 -= 運算符來提供的（請參閱圖 4）。

圖形狀態類
如前所述，非托管代碼的圖形狀態是通過 IDirect3DDevice9 接口的方法來配置的。例如，在非托管代碼中，變換狀態可通過 GetTransform 和 SetTransform 方法直接訪問，這兩種方法都使用 D3DTRANSFORMTYPE 類型的枚舉值。

// From unmanaged IDirect3DDevice9 interface:
HRESULT GetTransform(D3DTRANSFORMSTATETYPE State, D3DMATRIX *pMatrix);
HRESULT SetTransform(D3DTRANSFORMSTATETYPE State,
CONST D3DMATRIX *pMatrix);

托管的 Direct3D 為非托管層提供一些抽象，這會使客戶端代碼變得更簡潔。下面顯示的 Device 類說明了一組只讀屬性：

public class Device : MarshalByRefObject, IDisposable
{
// Additional properties, methods and events.
public Transforms Transform { get; }
public RenderStates RenderState { get; }
public SamplerStates SamplerState { get; }
public TextureStates TextureState { get; }
}

這些屬性返回 Transforms、RenderStates、SamplerStates 和 TextureStates 類的實例。這些實例隨后用于配置托管 Direct3D 的圖形狀態。例如，Device 類不直接公開使用枚舉值的 Transform 屬性。Device 托管類提供可返回 Transforms 對象的屬性。Transforms 對象隨后公開一組可用來訪問當前世界、視圖和投影矩陣的屬性，這些屬性本身是 TransformType 托管枚舉的元素。

RenderStates 類提供了大量的屬性來配置為光柵化階段選擇的特定算法。下面的客戶端代碼顯示了如何設置 Direct3D 托管管線的狀態。

// cull, spec, dither states.
device.RenderState.CullMode = Cull.None;
device.RenderState.SpecularEnable = false;
device.RenderState.DitherEnable = false;
// Filter states.
device.SamplerState[0].MagFilter = TextureFilter.Linear;
device.SamplerState[0].MinFilter = TextureFilter.Linear;

請注意，使用索引器來訪問取樣器狀態的多紋理層疊所在的階段。

取樣器狀態指定用于特定階段的篩選、平鋪和紋理尋址模式，這些模式可通過 Sampler 類的屬性來公開。篩選功能用于指定如何將圖像映射到特定的 Direct3D 基元。根據圖像（紋理）的大小以及它需要映射到的屏上基元的大小，可能需要放大或縮小圖像。Direct3D 提供了三種篩選方法：MipFilter、MinFilter 和 MagFilter，每種方法都具有可由 TextureFilter 枚舉配置的模式。平鋪功能用于將一組單個的紋理匯集成單個紋理并減少切換紋理的需要。平鋪功能是通過 Sampler 類的一組屬性獲得支持的。最后，紋理尋址模式通過 TextureAddress 枚舉的元素為 [0,1] 邊界外部的紋理坐標定義操作：

public class SamplerStates
{
private Sampler[] m_lpTex;
private bool pureDevice;
public Sampler get_SamplerState(int index);
internal SamplerStates(Device dev, bool pure);
public Sampler this[int index] { get; }
}

TextureStates 和 SamplerStates 類提供只讀索引器，該索引器可返回特定階段的 TextureState 實例。TextureState 類定義的屬性可獲得或指定特定紋理階段狀態的元素。諸如 ColorArgumentn 或 AlphaArgumentn（其中 n 可以是 0、1 或 2）屬性可以是 TextureArgument 枚舉的元素，而 ColorOperation 或 AlphaOperation 可以屬于 TextureOperation 枚舉，如下所示：

// color = tex mod diffuse.
device.TextureState[0].ColorArgument1 = TextureArgument.TextureColor;
device.TextureState[0].ColorOperation = TextureOperation.Modulate;
device.TextureState[0].ColorArgument2 = TextureArgument.Diffuse;
// alpha = select texture alpha.
device.TextureState[0].AlphaArgument1 = TextureArgument.TextureColor;
device.TextureState[0].AlphaOperation = TextureOperation.SelectArg1;
device.TextureState[0].AlphaArgument1 = TextureArgument.Diffuse;

與幾何形狀相關的類
Direct3D 中的幾何形狀被定義為頂點定義的數組。不同的圖形算法需要存儲在每個頂點的不同信息，了解這一點很重要。這些頂點組分需要由應用程序進行聲明，具體情況取決于程序員希望實現的效果。例如，如果程序員希望將紋理映射到 Direct3D 將呈現的幾何形狀，則程序員必須進行如下聲明：在每個頂點，都將有 tu 和 tv 值（紋理坐標）。托管的 Direct3D 提供了兩種頂點定義機制：VertexFormats 和 VertexDeclarations。使用這些機制，可以在每個頂點定義其他數據，如顏色、混合權重、紋理坐標或應用程序定義的任何用法。作為一種方便的方法，為經常使用的頂點格式定義提供了 CustomVertex helper 類。CustomVertex 類提供 11 種不同的頂點定義，這些定義經常用于 Direct3D 應用程序中。

在托管的 Direct3D 中，應用程序用來定義其頂點布局的頂點格式由 Device 類的讀和寫 VertexFormat 屬性來訪問。VertexFormat 屬性訪問 VertexFormats 枚舉的元素，并且只需通過以下方法來實現：針對 IDirect3DDevice9 接口使用 GetFVF 和 SetFVF 方法，調用內部的非托管 Direct3D Device COM 對象。托管的 VertexFormats 枚舉映射到在 d3dtypes.h 中定義的 VertexFormat 常量位，如下所示：

public struct Vertex
{
public Vector3 position;
public float tu, tv;
public static readonly VertexFormats Format =
VertexFormats.Position | VertexFormats.Texture1;
};
// From a typical managed Direct3D applications Render() method.
device.VertexFormat = Vertex.Format;

在使用可編程的管線時，需要自定義的頂點聲明。與使用靈活的頂點格式定義的頂點緩沖區不同，自定義頂點聲明可以通過使用多個流來定義，從而可節省帶寬：

VertexElement[] declaration = new VertexElement[]
{
new VertexElement(
0, // short stream
0, // short offset
DeclarationType.Float2, // DeclarationType declType
DeclarationMethod.Default, // DeclarationMethod declMethod
DeclarationUsage.Position, // DeclarationUsage declUsage
0 // byte usageIndex
),
VertexElement.VertexDeclarationEnd
};
VertexDeclaration declaration = new VertexDeclaration(device,
declaration);

托管 Direct3D 中的幾何形狀通常是通過處理 VertexBuffer.Created 事件來創建的。圖 5 顯示了從 SDK 中的 Tutorial2 示例提取的簡單三角形形狀，并說明了預定義的自定義頂點 (CustomVertex.TransformedColored) 的用法。

托管的 D3DX 庫
托管的 D3DX 實用工具庫具有用來處理網格、紋理、Shader、效果、文本和動畫的類。但是，與非托管的 D3DX 庫不同的是，它沒有數學類，如矩陣、矢量和四元組類。在托管 DirectX 中，數學類是 DirectX 庫的一部分。

用來處理網格的類包括 Mesh、SimplificationMesh、ProgressiveMesh、SkinMesh 和 PatchMesh。Mesh 和 ProgressiveMesh 從 BaseMesh 類繼承。BaseMesh 管理內存（包括頂點和索引緩沖區）中的網格表示形式，并提供用來呈現網格的 DrawSubset 方法。其他方法包括用來復制網格的 Clone 方法，以及用來計算頂點法線并獲取相鄰項信息的方法。

Mesh 類使用可將網格保存到 .X 文件（標準的 DirectX 文件類型）或二進制流中并從中加載網格的方法來擴展 BaseMesh。還提供了用來生成表示以下圖形的網格的方法：n 邊形、圓柱、球形、圓環、給定字體的 3D 文本或者甚至是茶壺。用戶可以網格化網格以獲得更光滑的對象（通過將每個三角形解釋為 N-patch），簡化網格（通過減少三角形的數量）、優化網格（通過對三角形重新排序，以便利用硬件中的頂點緩存并提高性能）或者執行與網格的光交叉。

SimplificationMesh 對象是從 Mesh 構造的，它具有可減少表面（三角形）或頂點數量的方法，從而可產生比初始網格簡單但是質量更低的網格形式。ProgressiveMesh 對象是從 Mesh 構造的。它允許實時簡化網格，以便在網格對象和照相機之間的距離增大時，最小化所呈現三角形的數量。SkinMesh 類（由主干制作動畫的網格）提供的方法可用來從 .X 文件數據對象加載外觀網格。包含了用來公開基礎網格和外觀的信息（如每根骨頭對結構的影響）的屬性。

PatchMesh 類表示更高階的表面，如 N-Patch、Triangle Patch 或 Rectangle Patch 表面。PatchMesh 包括用來執行如下操作的方法：從 Mesh 對象創建 N-Patch 網格、從 .X 文件加載 PatchMesh、網格化 PatchMesh 等。用來處理紋理的類主要包括：前面介紹的 TextureLoader 類、RenderToEnvironmentMap 類和 RenderToSurface 類。RenderToEnvironmentMap 和 RenderToSurface 類用來在運行時創建立方體環境貼圖和紋理。如果在運行時呈現到紋理中，則允許您獲得特殊效果，如讓類似于鏡面的物體反射布景中的其他物體，或者制造雙窗格呈現效果。用來處理文本的類主要包括 Font 類，Font 類可以從 System.Drawing.Font 對象實例化，并且具有可以在支持 Direct3D 的設備上呈現文本的方法。用來處理動畫的類由 KeyFrameInterpolator 類組成，KeyFrameInterpolator 類具有用來以內插值替換對象的縮放、旋轉和/或平移的方法。內插值替換是通過使用一組 3D 矢量（用來縮放和平移）和四元組項（用于旋轉）來執行的。

都有這個device.SetStreamSource(0, vertexBuffer, 0);
她的作用?可以不要嗎?

用處: 在c++中用基類指針的數組,在c#中用arraylist都可以 來表示一個帶有分支的樹結構

用戶感覺不到他在處理結合還是一個單體> 這就是此模式的用處所在

小弟最近在CSDN上找的C#面試題目，自己做了一下把題目和答案附上來，希望對大家有用。如有錯誤的地方還望大家指教！

1、C#中 property 與 attribute的區別，他們各有什么用處，這種機制的好處在哪里？

property和attribute漢語都稱之為屬性。不過property是指類向外提供的數據區域。而attribute則是描述對象在編譯時或運行時屬性的。這兩者是有本質區別的。

2、講一講你理解的web service,在dot net framework中，怎么很好的結合xml?（講概念就行了）

從表面上看，Web Service就是一個應用程序，它向外界暴露出一個能夠通過Web進行調用的API。這就是說，你能夠用編程的方法通過Web調用來實現某個功能的應用程序。從深層次上看，Web Service是一種新的Web應用程序分支，它們是自包含、自描述、模塊化的應用，可以在網絡(通常為Web)中被描述、發布、查找以及通過Web來調用。可擴展的標記語言XML是Web Service平臺中表示數據的基本格式。除了易于建立和易于分析外，XML主要的優點在于它既與平臺無關，又與廠商無關。XML是由萬維網協會(W3C)創建，W3C制定的XML SchemaXSD定義了一套標準的數據類型，并給出了一種語言來擴展這套數據類型。Web Service平臺是用XSD來作為數據類型系統的。當你用某種語言如VB.NET或C#來構造一個Web Service時，為了符合Web Service標準，所有你使用的數據類型都必須被轉換為XSD類型。如想讓它使用在不同平臺和不同軟件的不同組織間傳遞，還需要用某種東西將它包裝起來。這種東西就是一種協議，如 SOAP。

3. C#, Java 和 c++的特點，有什么相同的地方，不同的地方，C#分別從c++和java中吸取了他們那些優點？

C#看起來與Java有著驚人的相似;它包括了諸如單一繼承,界面,與Java幾乎同樣的語法,和編譯成中間代碼再運行的 過程.但是C#與Java有著明顯的不同,它借鑒了Delphi的一個特點,與COM(組件對象模型)是直接集成。
微軟c#語言定義主 要是從C和C++繼承而來的,而且語言中的許多元素也反映了這一點.C#在設計者從C++繼承的可選選項方面比Java要廣泛一些(比如說 structs),它還增加了自己新的特點(比方說源代碼版本定義).

C#從Java繼承而來的特點

類:在C#中類的申明與Java很相似。特點看起來與Java相比沒有變化.布爾運算:條件表達式的結果是布爾數據類型,布爾數據類型是這種語言中獨立的一種數據類型.從布爾類型到其他類型沒有 直接的轉換過程.布爾常量true和false是C#中的關鍵字.錯誤處理:如Java中那樣,通過拋出和捕捉異常對象來管理錯誤處理過程.內存管理:由 底層.NET框架進行自動內存垃圾回收.


C#從C和C++繼承的特點

編譯:程序直接編譯成標準的二進制可執行形式.

結構體:一個C#的結構體與C++的結構體是相似的,因為它能夠包含數據申明和方法.但是,不象C++,C#結構體與類是不同的而且不支持繼承.但是,與Java相同的是,一個結構體可以實現界面.
預編譯:C#中存在預編譯指令支持條件編譯,警告,錯誤報告和編譯行控制. #error

C#獨有的特點
中間代碼:微軟在用戶選擇何時MSIL應該編譯成機器碼的時候是留了很大的余地.微軟公司很小心的聲稱MSIL不是解釋性的,而是被編譯成了機器碼.它也明 白許多--如果不是大多數的話--程序員認為Java程序要不可避免的比C編寫的任何東西都要慢.而這種實現方式決定了基于MSIL的程序(指的是用 C#,Visual Basic,"Managed C++"--C++的一個符合CLS的版本--等語言編寫的程序)將在性能上超過"解釋性的"Java代碼.當然,這一點還需要得到事實證明,因為C#和 其他生成MSIL的編譯器還沒有發布.但是Java JIT編譯器的普遍存在使得Java和C#在性能上相對相同.象"C#是編譯語言而Java是解釋性的,"之類的聲明只是商業技巧.Java的中間代碼和 MSIL都是中間的匯編形式的語言,它們在運行時或其它的時候被編譯成機器代碼.

命名空間中的申明:當你創建一個程序的時候,你在一個命名空間里創建了一個或多個類.同在這個命名空間里(在類的外面)你還有可能聲明界面,枚舉類型和結構體.必須使用using關鍵字來引用其他命名空間的內容.
基本的數據類型:C#擁有比C,C++或者Java更廣泛的數據類型.這些類型是bool, byte, ubyte, short, ushort, int, uint, long, ulong, float, double,和decimal.象Java一樣,所有這些類型都有一個固定的大小.又象C和C++一樣,每個數據類型都有有符號和無符號兩種類型.與 Java相同的是,一個字符變量包含的是一個16位的Unicode字符.C#新的數據類型是decimal數據類型,對于貨幣數據,它能存放28位10 進制數字.

兩個基本類:一個名叫object的類是所有其他類的基類.而一個名叫string的類也象object一樣是這個語言的一部分.作為語言的一部分存在意味著編譯器有可能使用它--無論何時你在程序中寫入一句帶引號的字符串,編譯器會創建一個string對象來保存它.
參數傳遞:方法可以被聲明接受可變數目的參數.缺省的參數傳遞方法是對基本數據類型進行值傳遞.ref關鍵字可以用來強迫一個變量通過引用傳遞,這使得一個變量可以接受一個返回值.out關鍵字也能聲明引用傳遞過程,與ref不同的地方是,它指明這個參數并不需要初始值.
與COM 的集成:C#對Windows程序最大的賣點可能就是它與COM的無縫集成了,COM就是微軟的Win32組件技術.實際上,最終有可能在任何.NET語 言里編寫COM客戶和服務器端.C#編寫的類可以子類化一個以存在的COM組件;生成的類也能被作為一個COM組件使用,然后又能使用,比方說, JScript語言子類化它從而得到第三個COM組件.這種現象的結果是導致了一個運行環境的產生,在這個環境里的組件是網絡服務,可用用任何.NET語 言子類化.
索引下標:一個索引與屬性除了不使用屬性名來引用類成員而是用一個方括號中的數字來匿名引用(就象用數組下標一樣)以外是相似的.
代理和反饋:一個代理對象包括了訪問一個特定對象的特定方法所需的信息.只要把它當成一個聰明的方法指針就行了.代理對象可以被移動到另一個地方,然后可以 通過訪問它來對已存在的方法進行類型安全的調用.一個反饋方法是代理的特例.event關鍵字用在將在事件發生的時候被當成代理調用的方法聲明中.

時間會解決一切,一切都會好起來的啊!

Managed DirectX是對DirectX大部分功能的托管封裝，可以用任何支持.NET的語言開發。MDX只對DirectX做了非常低層次的封裝，因此保持了用COM接口DirectX開發時的大部分原貌。MDX的性能是不用擔心的，因為它還是象COM DirectX一樣提供對硬件層次的訪問，大部分功能都是在你的顯卡/網卡/聲卡上起作用的，托管部分只是它的接口。事實證明MDX在DirectX Graphics中的性能與COM接口的DirectX不相上下。既然MDX的開發方式、API和性能都與COM接口的DirectX差不多，那為什么要用MDX呢？我自己對這個問題的回答是：

1、托管代碼的對象模型更好。MDX基于類庫的組織結構，比用COM接口的處理方式更方便。
2、用MDX，一般不用操心資源釋放的問題。很大一部分資源釋放的操作，都被封裝好了。
3、與更多現代技術結合得更好。我們可以讓DirectX程序使用XML、WebService和智能客戶端等技術。

Direct3D程序最基本的流程是：創建Windows窗口、創建設備、處理消息循環、物體圖形顯示、退出和清理。在MDX的世界里，窗口創建和處理消息循環我們交給Windows Forms模型來做，剩下最主要的任務就是創建設備和物體圖形顯示。Direct3D設備是Direct3D開發最基本的入口，它定義了Direct3D所有的繪圖組件，大部分的操作都需要從Direct3D設備開始。創建設備需要設定幾個參數，包括顯卡序號、設備類型、所屬窗口、3D運算方式等。除了這些信息外，還需要一個PresentParameters類型的參數，其中定義了Direct3D設備所需的相關信息。下面代碼中的InitializeDirect3D函數完整的演示了創建設備的步驟

設備類型：Direct3D支持3種設備，其中HAL和REF最為重要。HAL通過硬件進行光柵化、坐標變換和光照處理等，速度最快。REF則是用軟件實現相關的操作，僅用于硬件不支持某種操作的情況。DeviceType枚舉定義了設備類型可能的選項。

3D運算方式包括一些選項，如HardwareVertexProcessing，PureHardwareVertexProcessing等，用于指定頂點運算由硬件執行還是軟件執行等。

PresentParameters還包括一些設置，如后臺緩沖區的高度、寬度和像素格式，以及從后臺緩沖區復制到前臺緩存屏幕顯示的方式等等。如果Direct3D采用窗口方式運行，像素格式必須查詢當前的顯示模式獲得。

Direct3D設備創建成功以后，就可以進入圖形顯示階段。在下面的代碼中以Render()函數的形式出現。在繪制圖形前，需要調用Device::Clear()函數重制ViewPort的顏色緩沖區。ViewPort就是3D形狀投射到平面顯示器上供我們看到的那個區域。Clear函數的Flag參數指定了對顏色緩沖區、深度緩沖區還是模板緩沖區進行初始化。因為我用ATI顯卡，所以我選擇了將顏色緩沖區初始化為紅色:)。接下來是調用BeginScene()函數和EndScene()函數。實際的繪圖中，所有渲染的代碼都必須放在BeginScene函數和EndScene函數之間，否則就會出錯。最后調用Present()函數，將后臺緩沖區中的數據復制到前臺緩沖區，我們就能看見圖形了。

IT公司類
包括思科、英特爾、IBM、惠普、ACER、索尼、Oracle、聯想、長城、同方、方正、洪恩、微軟、漢王、神州數碼、京東方、維爾軟件、普天、奇碼數字信息有限公司、廣東北電、威盛、高通、揚智、友立資訊、BISC、GOOGLE、SUN、騰訊公司、百度等
通訊/運營類
中國電信、中國移動、中國聯通、中國網通、中國鐵通、華為、中興、大唐、UT斯達康、上海貝爾阿爾卡特、摩托羅拉、諾基亞、愛立信、西門子、朗訊、香港電信、東信、北京信威通信、飛利浦、NEC
電子電氣類
意法半導體、Avant! 微電子、凹凸電子、松下電器、美的集團、創維集團、廈新、TCL、北京松下彩色顯像管有限公司、中星微電子、美國國家儀器有限公司（NI）、士蘭微電子、世芯電子股份有限公司、奧的斯（otis）、青島海信集團技術中心
金融/投資
中國工商銀行、中國建設銀行、中國銀行、中國農業銀行、中國招商銀行、中國國際金融有限公司（CICC）、Hongkong Bank、中軟融鑫、高盛（GS）、博世(BOSCH)、寶潔（Procter&Gamble）、沃爾瑪
http://www.net3721.com/bbs/forumdisplay.php?fid=43

但是 .net 2.0 中不支持用delegate() 來sort().

很好用的啊,但是好像沒有最新的支持.net 2.0的啊!

轉的!

在什么情況下應當使用訪問者模式
有意思的是，在很多情況下不使用設計模式反而會得到一個較好的設計。換言之，每一個設計模式都有其不應當使用的情況。訪問者模式也有其不應當使用的情況，讓我們
先看一看訪問者模式不應當在什么情況下使用。

傾斜的可擴展性

訪問者模式僅應當在被訪問的類結構非常穩定的情況下使用。換言之，系統很少出現需要加入新節點的情況。如果出現需要加入新節點的情況，那么就必須在每一個訪問對象里加入一個對應于這個新節點的訪問操作，而這是對一個系統的大規模修改，因而是違背"開一閉"原則的。

訪問者模式允許在節點中加入新的方法，相應的僅僅需要在一個新的訪問者類中加入此方法，而不需要在每一個訪問者類中都加入此方法。

顯然，訪問者模式提供了傾斜的可擴展性設計：方法集合的可擴展性和類集合的不可擴展性。換言之，如果系統的數據結構是頻繁變化的，則不適合使用訪問者模式。

"開一閉"原則和對變化的封裝

面向對象的設計原則中最重要的便是所謂的"開一閉"原則。一個軟件系統的設計應當盡量做到對擴展開放，對修改關閉。達到這個原則的途徑就是遵循"對變化的封裝"的原則。這個原則講的是在進行軟件系統的設計時，應當設法找出一個軟件系統中會變化的部分，將之封裝起來。

很多系統可以按照算法和數據結構分開，也就是說一些對象含有算法，而另一些對象含有數據，接受算法的操作。如果這樣的系統有比較穩定的數據結構，又有易于變化的算法的話，使用訪問者模式就是比較合適的，因為訪問者模式使得算法操作的增加變得容易。

反過來，如果這樣一個系統的數據結構對象易于變化，經常要有新的數據對象增加進來的話，就不適合使用訪問者模式。因為在訪問者模式中增加新的節點很困難，要涉及到在抽象訪問者和所有的具體訪問者中增加新的方法。


六、 使用訪問者模式的優點和缺點
訪問者模式有如下的優點：

訪問者模式使得增加新的操作變得很容易。如果一些操作依賴于一個復雜的結構對象的話，那么一般而言，增加新的操作會很復雜。而使用訪問者模式，增加新的操作就意味著增加一個新的訪問者類，因此，變得很容易。
訪問者模式將有關的行為集中到一個訪問者對象中，而不是分散到一個個的節點類中。
訪問者模式可以跨過幾個類的等級結構訪問屬于不同的等級結構的成員類。迭代子只能訪問屬于同一個類型等級結構的成員對象，而不能訪問屬于不同等級結構的對象。訪問者模式可以做到這一點。
積累狀態。每一個單獨的訪問者對象都集中了相關的行為，從而也就可以在訪問的過程中將執行操作的狀態積累在自己內部，而不是分散到很多的節點對象中。這是有益于系統維護的優點。
訪問者模式有如下的缺點：

增加新的節點類變得很困難。每增加一個新的節點都意味著要在抽象訪問者角色中增加一個新的抽象操作，并在每一個具體訪問者類中增加相應的具體操作。
破壞封裝。訪問者模式要求訪問者對象訪問并調用每一個節點對象的操作，這隱含了一個對所有節點對象的要求：它們必須暴露一些自己的操作和內部狀態。不然，訪問者的訪問就變得沒有意義。由于訪問者對象自己會積累訪問操作所需的狀態，從而使這些狀態不再存儲在節點對象中，這也是破壞封裝的。

訪問者模式的目的是封裝一些施加于某種數據結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的數據結構則可以保持不變。

問題提出

System.Collection命名空間下提供了大量集合操作對象。但大多數情況下處理的都是同類對象的聚集。換言之，在聚集上采取的操作都是一些針對同類型對象的同類操作。但是如果針對一個保存有不同類型對象的聚集采取某種操作該怎么辦呢？

粗看上去，這似乎不是什么難題。可是如果需要針對一個包含不同類型元素的聚集采取某種操作，而操作的細節根據元素的類型不同而有所不同時，就會出現必須對元素類型做類型判斷的條件轉移語句。這個時候，使用訪問者模式就是一個值得考慮的解決方案。

訪問者模式

訪問者模式適用于數據結構相對未定的系統，它把數據結構和作用于結構上的操作之間的耦合解脫開，使得操作集合可以相對自由地演化。

數據結構的每一個節點都可以接受一個訪問者的調用，此節點向訪問者對象傳入節點對象，而訪問者對象則反過來執行節點對象的操作。這樣的過程叫做"雙重分派"。節點調用訪問者，將它自己傳入，訪問者則將某算法針對此節點執行。

雙重分派意味著施加于節點之上的操作是基于訪問者和節點本身的數據類型，而不僅僅是其中的一者。

State模式與Strategy模式的區別時什么啊?,potian大俠幫忙。
首先，兩者的意圖是不同的。策略用來處理算法變化，而狀態則是透明地處理狀態變化。
造成混淆的原因可能是兩者好像都能成為繼承的替代。
策略主要處理算法變化的意思是算法可能是要變的，但是這種變化卻是由用戶來決定到底采用何種算法。這些算法之間一般來說沒有狀態變遷的問題，并且你總是從幾個算法中間選取一個。策略最經典的用法是和observe一起組成MVC，其中V通過Observe觀察M,而V通過strategy控制C.
策略使用的另一個最頻繁的地方就是消除大量的Case或if else ，但是條件是這些case中每個條件可以歸納為一個算法，最好它們只需要相同的參數。當然，在strategy中,Context可以提供接口讓strategy，但是我一般不太喜歡這么用，因為這樣可能造成一系列的不必要耦合和開銷。
對這些case，if else使得strategy有了一個policy的別名，還有一個常用的地方叫做validator，譬如在輸入框內進行檢查時可以把它實現為Validator。有時候，if else的嵌套層次可能很深，這時候策略可能不能用，那么你可能需要更加復雜或者更加專注的Rule模式。
狀態模式則有所不同，她實現的一個概念可以叫做動態繼承，也就是繼承的子類（每一個狀態）可以發生變化。這些狀態的變化是一個整體，組成了一個狀態變化圖。而一般來說，使用該模式的狀態之間存在著一種線性變化的關系，也就是一個狀態變為另一個，然后是第三個。客戶代碼并不清楚這些狀態在何時發生變化，這樣做的好處是在組成你整個變化過程中某些狀態之間需要插入一個新的狀態，或者狀態的順序之間發生變化，對客戶是不可見。實現模式一方面，修改的也只是相領的狀態。在處于不同的狀態時，客戶代碼可以執行的方法也是不同的。但它的問題就是必須在Context和所有的狀態實現所有狀態可能的方法。
這兩個之間的區別有時候可能沒有，譬如在面向連結的TCPConnection例子中，不同的狀態可能具有不同的方法。但是在我剛剛實現的一個無連結的P2P底層協議中，所有狀態需要處理地就是一個processXML方法，這時候，你可以叫它狀態或者策略都可以。但由于還是又狀態變遷的問題，所以我喜歡把它叫做狀態。

備忘錄模式還好理解拉!哈哈

比較簡單了,在net里太多的集合類拉,哈哈,就是那2個interface.

在什么情況下應當使用命令模式
在下面的情況下應當考慮使用命令模式：

1、使用命令模式作為"CallBack"在面向對象系統中的替代。"CallBack"講的便是先將一個函數登記上，然后在以后調用此函數。

2、需要在不同的時間指定請求、將請求排隊。一個命令對象和原先的請求發出者可以有不同的生命期。換言之，原先的請求發出者可能已經不在了，而命令對象本身仍然是活動的。這時命令的接收者可以是在本地，也可以在網絡的另外一個地址。命令對象可以在串形化之后傳送到另外一臺機器上去。

3、系統需要支持命令的撤消(undo)。命令對象可以把狀態存儲起來，等到客戶端需要撤銷命令所產生的效果時，可以調用undo()方法，把命令所產生的效果撤銷掉。命令對象還可以提供redo()方法，以供客戶端在需要時，再重新實施命令效果。

4、如果一個系統要將系統中所有的數據更新到日志里，以便在系統崩潰時，可以根據日志里讀回所有的數據更新命令，重新調用Execute()方法一條一條執行這些命令，從而恢復系統在崩潰前所做的數據更新。

5、一個系統需要支持交易(Transaction)。一個交易結構封裝了一組數據更新命令。使用命令模式來實現交易結構可以使系統增加新的交易類型。


八、 使用命令模式的優點和缺點
命令允許請求的一方和接收請求的一方能夠獨立演化，從而且有以下的優點：

命令模式使新的命令很容易地被加入到系統里。
允許接收請求的一方決定是否要否決（Veto）請求。
能較容易地設計-個命令隊列。
可以容易地實現對請求的Undo和Redo。
在需要的情況下，可以較容易地將命令記入日志。
命令模式把請求一個操作的對象與知道怎么執行一個操作的對象分割開。
命令類與其他任何別的類一樣，可以修改和推廣。
你可以把命令對象聚合在一起，合成為合成命令。比如宏命令便是合成命令的例子。合成命令是合成模式的應用。
由于加進新的具體命令類不影響其他的類，因此增加新的具體命令類很容易。
命令模式的缺點如下：

使用命令模式會導致某些系統有過多的具體命令類。某些系統可能需要幾十個，幾百個甚至幾千個具體命令類，這會使命令模式在這樣的系統里變得不實際。

職責鏈（Chain of Responsibility）模式
責任鏈模式是一種對象的行為模式【GOF95】。在責任鏈模式里，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任。

我想Proxy與Adapter還是有區別的。因為Proxy中的代理和被代理對象是“同根生”，這樣才可以代理。Adapter中的Adapter與Adaptee不用“同根生”。我把Proxy稱作“票販子的模式”，而Adapter是“倒賣外匯的模式”。票販子販的是票，在販賣的過程中，票沒有變化，只是被代理了。而Adapter模式中，外匯可能由人民幣變做了美元，東西變了（呵呵，換湯不換藥，都是鈔票）。

好像和裝飾（Decorator）模式差不多啊?

到底有什么不同啊?

和代理模式的區別:

在什么情況下使用門面模式
為一個復雜子系統提供一個簡單接口
提高子系統的獨立性
在層次化結構中，可以使用Facade模式定義系統中每一層的入口。

使用裝飾模式的優點和缺點
使用裝飾模式主要有以下的優點：

裝飾模式與繼承關系的目的都是要擴展對象的功能，但是裝飾模式可以提供比繼承更多的靈活性。
通過使用不同的具體裝飾類以及這些裝飾類的排列組合，設計師可以創造出很多不同行為的組合。
這種比繼承更加靈活機動的特性，也同時意味著裝飾模式比繼承更加易于出錯。
使用裝飾模式主要有以下的缺點：

由于使用裝飾模式，可以比使用繼承關系需要較少數目的類。使用較少的類，當然使設計比較易于進行。但是，在另一方面，使用裝飾模式會產生比使用繼承關系更多的對象。更多的對象會使得查錯變得困難，特別是這些對象看上去都很相像。

裝飾模式應當在什么情況下使用
在以下情況下應當使用裝飾模式：

需要擴展一個類的功能，或給一個類增加附加責任。
需要動態地給一個對象增加功能，這些功能可以再動態地撤銷。
需要增加由一些基本功能的排列組合而產生的非常大量的功能，從而使繼承關系變得不現實。

裝飾（Decorator）模式又名包裝（Wrapper）模式[GOF95]。裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關系的一個替代方案。

橋梁模式的用意

【GOF95】在提出橋梁模式的時候指出，橋梁模式的用意是"將抽象化(Abstraction)與實現化(Implementation)脫耦，使得二者可以獨立地變化"。這句話有三個關鍵詞，也就是抽象化、實現化和脫耦。

抽象化

存在于多個實體中的共同的概念性聯系，就是抽象化。作為一個過程，抽象化就是忽略一些信息，從而把不同的實體當做同樣的實體對待【LISKOV94】。

實現化

抽象化給出的具體實現，就是實現化。

脫耦

所謂耦合，就是兩個實體的行為的某種強關聯。而將它們的強關聯去掉，就是耦合的解脫，或稱脫耦。在這里，脫耦是指將抽象化和實現化之間的耦合解脫開，或者說是將它們之間的強關聯改換成弱關聯。

將兩個角色之間的繼承關系改為聚合關系，就是將它們之間的強關聯改換成為弱關聯。因此，橋梁模式中的所謂脫耦，就是指在一個軟件系統的抽象化和實現化之間使用組合/聚合關系而不是繼承關系，從而使兩者可以相對獨立地變化。這就是橋梁模式的用意。

在什么情況下應當使用橋梁模式
根據上面的分析，在以下的情況下應當使用橋梁模式：

如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的聯系。
設計要求實現化角色的任何改變不應當影響客戶端，或者說實現化角色的改變對客戶端是完全透明的。
一個構件有多于一個的抽象化角色和實現化角色，系統需要它們之間進行動態耦合。
雖然在系統中使用繼承是沒有問題的，但是由于抽象化角色和具體化角色需要獨立變化，設計要求需要獨立管理這兩者。

Adapter模式在實現時有以下這些值得注意的地方：

1、 目標接口可以省略，模式發生退化。但這種做法看似平庸而并不平庸，它可以使Adaptee不必實現不需要的方法（可以參考Default Adapter模式）。其表現形式就是父類實現缺省方法，而子類只需實現自己獨特的方法。這有些像模板（Template）模式。
2、 適配器類可以是抽象類。
3、 帶參數的適配器模式。使用這種辦法，適配器類可以根據參數返還一個合適的實例給客戶端。

在以下各種情況下使用適配器模式：

1、 系統需要使用現有的類，而此類的接口不符合系統的需要。
2、 想要建立一個可以重復使用的類，用于與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作。這些源類不一定有很復雜的接口。
3、 （對對象適配器而言）在設計里，需要改變多個已有子類的接口，如果使用類的適配器模式，就要針對每一個子類做一個適配器，而這不太實際。

原型模式的用意是：通過給出一個原型對象來指明所要創建的對象類型，然后用復制這個原型對象的辦法創建出更多的同類型對象。

Prototype模式的優點與缺點
Prototype模式的優點包括

1、Prototype模式允許動態增加或減少產品類。由于創建產品類實例的方法是產批類內部具有的，因此增加新產品對整個結構沒有影響。

2、Prototype模式提供了簡化的創建結構。工廠方法模式常常需要有一個與產品類等級結構相同的等級結構，而Prototype模式就不需要這樣。

3、Portotype模式具有給一個應用軟件動態加載新功能的能力。由于Prototype的獨立性較高，可以很容易動態加載新功能而不影響老系統。

4、產品類不需要非得有任何事先確定的等級結構，因為Prototype模式適用于任何的等級結構。




Prototype模式的缺點：

Prototype模式的最主要缺點就是每一個類必須配備一個克隆方法。而且這個克隆方法需要對類的功能進行通盤考慮，這對全新的類來說不是很難，但對已有的類進行改造時，不一定是件容易的事