現(xiàn)在主流的開發(fā)語言就是C++語言了，但是不過感覺沒有C語言實現(xiàn)的那么靈活，現(xiàn)介紹一下代碼實現(xiàn) ControlTemplate的方法，希望大家學習探討，好了下面就是C++代碼舉例說明：

FrameworkElementFactory fe = new FrameworkElementFactory(typeof(Image), "Image");   
 
           BitmapImage bi = new BitmapImage();   
           bi.BeginInit();   
           bi.UriSource = new Uri(@"E:ChartControlHanYangChartControlImageMainBackground.jpg");   
           bi.EndInit();   
 
           fe.SetValue(Image.SourceProperty, bi);   
 
           //控件呈現(xiàn)的顯示內(nèi)容2（這里為TextBox）   
           FrameworkElementFactory fe2 = new FrameworkElementFactory(typeof(TextBox), "TextBox");   
           fe2.SetValue(TextBox.WidthProperty,100.0);   
           fe2.SetValue(TextBox.HeightProperty, 100.0);   
 
           //把要呈現(xiàn)的顯示內(nèi)容封裝起來   
           FrameworkElementFactory f = new FrameworkElementFactory(typeof(Grid), "Grid");   
           f.AppendChild(fe);   
           f.AppendChild(fe2);  

從上表可以看出，int與long相同。那么，為什么C++代碼還要區(qū)分這兩種數(shù)據(jù)類型呢?實際上這是個遺留問題。在16位編程環(huán)境中，int要求2個字節(jié)而long要求4個字節(jié)。而在32位編程環(huán)境中，這兩種數(shù)據(jù)都用4個字節(jié)存放。

C++Builder只生成32位程序，所以int與long相同。說明 在C++ Builder和BorLand C++ 5.0中，Bool是個真正的數(shù)據(jù)類型。有些C++編譯器有Bool關(guān)鍵字，則Bool不是個真正的數(shù)據(jù)類型。

有時Bool只是個typedef，使Bool等價于int。typedef實際上建立別名，使編譯器在一個符號與另一符號間劃上等號。typedef的語法如下：typedef int Bool;這就告訴編譯器:Bool是int的別名。說明 只有double和float數(shù)據(jù)類型使用浮點數(shù)（帶小數(shù)點的數(shù)）。

其它數(shù)據(jù)類型只涉及整數(shù)值。盡管integer數(shù)據(jù)類型也可以指定帶小數(shù)點的數(shù)值，但小數(shù)部分會舍棄，只將整數(shù)部分賦予整型變量。例如：int x=3.75;得到的x取值為3。注意，這個整數(shù)值并不是四舍五入，而是放棄小數(shù)部分。順便說一句，大多數(shù)Windows程序很少用到浮點數(shù)。

C++代碼可以在必要時進行不同數(shù)據(jù)類型間的換算。例如：short result;long num1 = 200;long num2 = 200;result = num1 * num2;這里我想將兩個長整型的積賦予一個短整型。盡管這個公式混用了兩種數(shù)據(jù)類型，但C++能夠進行換算。計算結(jié)果會怎樣呢?結(jié)果會讓你大吃一驚，是25536，這是繞接(wrop)的結(jié)果。

從表1.1可以看出，短整型的***取值為32767，在***值之上加1會怎么樣呢?得到的是32768。這實際上與汽車里程計從99999回到00000的道理一樣。為了說明這點，請輸入并運行下列清單1.3中包含的程序。

為了避開C++的復雜性而干脆不用C++（Linus的做法），無異于因噎廢食。”在所有可用C和C++的領(lǐng)域，C++都是比C更好的語言。當我說“更好的”時候，我說的是C++擁有比C更安全的類型檢查、更好的抽象機制、更優(yōu)秀的庫。

當然，凡事都有例外，如果你做的項目1）不大。2）編碼中用不到什么抽象機制，甚至ADT（抽象數(shù)據(jù)類型，例如std::complex這種不含多態(tài)和繼承的）也用不到，RAII也用不到，異常也用不到。

3）你連基礎庫（如，簡化資源管理的智能指針、智能容器）都用不著。那么也許你用C的確沒問題；所以如果你的情況如此，不用和我爭論，因為我無法反駁你。我們這里說的領(lǐng)域大致是Bjarne在“C++應用列表”里面列出來的那些地方。 #t#

即便是C++的反對者也許也很難找到理由說“我還是不用C++代碼”。在我看來，一個真正從實踐意義上理性反對使用C++的人只有一個理由：C++的復雜性帶來的混亂抵消乃至超過了C++的抽象機制和庫（在他的特定項目中）帶來的好處。

值得注意的是，這里需要避免一個陷阱，就是一旦人們認定了“C++代碼不好”，那么這個理由就會“長出自己的腳來”，即，就算我們拿掉C++的復雜性，他們可能也會堅持還是不用C++，并為之找一堆理由。

我假定你不是這樣的人。不過，也許最可能的是他會說：“問題是我們今天用的C++并非如此（簡潔），你的假設不成立。”是的，我的假設不成立。但雖然我們無法消除復雜性，我們實際上是可以容易地避開復雜性，避短揚長的。這也是本文的要點，容我后面再詳述。