最近忙著看書，但發覺記憶不是很好。看時明明白白的東西，一會就忘了。覺得還是記錄下來，好記性不如爛筆頭，減慢閱讀的速度，增加思考的時間。

More Effective C++之一 基礎議題

條款1：區分指針和引用
這個可以理解為：指針和引用有什么區別。
一是指針可以為空，而引用不能為空。
引用必須要指代某個對象。由于引用總是要指代一個對象，C++要求引用必須初始化。不存在空引用，則意味著引用比使用指針更高效。因為使用引用之前不需要測試它是否有效，而指針通常需要檢查其是否為空。
二是指針可以被重新賦值用以指向另外一個不同的對象，而引用總是指向初始化時它所指代的對象。

條款2：優先考慮C++風格的類型轉換
這個可以有兩個問題需要明白：一是C風格的類型轉換有什么缺點；二是C++風格的類型轉換的優點。
首先我們來看C風格類型轉換的缺點：
其一是可以通過它們在任意類型之間進行轉換。有些轉換差別很大，但C風格的類型沒有做區分，行為有些粗魯。
其二是C風格的類型轉換很難進行查找。

c++風格的類型轉換：有4種類型轉換，分別是static_cast, const_cast, dynamic_cast和reinterpret_cast。
使用時應寫成
static_cast<typde> (expression)，其他同理。

static_cast 針對一種不涉及繼承的類型實施轉換，也不涉及const轉換的時候，就可以使用static_cast轉換。
const_cast用來去除掉一個表達式的const屬性或volatile屬性。強調的是通過這個轉換你要做的唯一一件事情就是改變某些東西的const屬性或者volatile屬性。目前為止，最通常的用法是去除掉一個對象的const屬性。
dynamic_cast，用來針對一個繼承體系做向下或者橫向的安全轉換。用dynamic_cast 把指向基類的指針（或引用）轉換成指向派生類或者基類的兄弟類的指針（或引用），而且同時可以知道轉換是否成功。空指針或者異常意味著失敗。
reinterpret_cast最常見的用法是用來在函數指針之間進行類型轉換。這種轉換常常是由（編譯器的）實現所定義的，致使reinterpret_cast幾乎不可移植。對函數指針實施類型轉換是不可移植的，而且在某些情況下會產生不正確的。

C++風格的類型轉換的優點：有確切的含義并容易識別，他們允許編譯器診斷類型轉換所產生的錯誤，不會使這些錯誤就在不知不覺的情況下被漏掉。

該上班了，其他待續。。。

今天遇到了很詭異的問題，最后把癥結歸到了StretchBlt這里。
嘗試了很多方法，最后發現，是圖片的大小問題。原圖片的大小比較小，而設定圖片的寬度和高度時用了很大的值，結果導致StretchBlt失敗，從而界面刷新失效。改成較小的值則沒有這樣的問題。對于這個原因，沒有想明白為什么？因為有兩個緊挨著的語句都這么調用，在很多機型中都沒有問題。但是在特定的機型中就會發生。一次調用成功，兩次調用失敗。這讓人很惱火。

在調試的過程中，設備很容易死機。這么嘗試幾十次之后，真的有點發瘋了。

還好，問題解決了。自己的理由找的也很充分。

但是這對么？
在SDK中，看到有這么一句：
If the source transformation has a rotation or shear, an error occurs. 原圖片與設備不相符時，是否會發生剪切的行為呢？我這里只是猜測。

我們都知道，在設置中有連接選項，我們可以選擇指定的接入點連入網絡。但是其原理又是怎樣的。這個在我最近的學習中一直找不到很好的解決方案。
人們比較熟悉GPRS連接，中國移動的GPRS接入也不外乎分為兩種，cmnet和cmwap。通過枚舉接入點，獲取接入點名稱，然后建立連接。看似還是挺簡單的。
但是我們也注意到，在網絡中還存在撥號，這個連接是怎么進行的。我這里還沒有想明白。
還有如何利用程序自動的選擇網絡，使其出現在連接設置界面中。好像也還沒有人給出答案。為此我還專門跑到MSDN上面去問，不過有人說還沒有方法實現。不過我見過一款軟件是可以的，但是怎么實現的也不得而知。
所以剩下的工作只能自己努力發現了，還有借助這里的力量了。

如果您有什么建議的話，不妨告訴我。

遇到問題的時候，要變換角度看問題，不能只盯著一處。

事情是這樣的：我們新發布出去的產品發現了一個BUG，這個問題在測試階段也遇到過，當時以手機的原因沒有理會。但發出去后，發現很多用戶使用中也用到了相同的問題。其中也有一款機型我見過。這讓我很郁悶。什么原因呢？嘗試了用戶的操作發現，的確存在這樣的問題。

原因還在查找中。所以在遇到問題的時候，一定要多方面的排查問題，不要輕易的將問題放過去。有可能會是一個痛。

生活中也有許多這樣的例子吧。所以我們有時沒有必要鉆牛角尖。

最近遇到了一些問題，都是關于Connection Manager的，它的一些API的運用方面的問題。主要糾結在了ConnMgrQueryDetailedStatus函數的使用上。不是很清楚這個已經存在的網絡的枚舉標準是什么？我應該怎么過濾掉一些無關的連接網絡。

網上查閱了一些資料
1、Windows CE Networking Team WebLog 這是網絡組的一個博客
ttp://blogs.msdn.com/cenet/archive/tags/Author_3A00_+Adam+Dyba/default.aspx

 2、How Connection Manager Connects
http://msdn.microsoft.com/en-us/magazine/dd263096.aspx

他們都對Connection Manager熟悉，但是相關的文章中并沒有提及這些。

所以還在尋找中。。。

曾記得我記錄下來了，現在又找不到了，所以還是記錄在博客中，作為我的備份檔案。

“沒有找到 MSVCR80D.dll,因此這個程序未能啟動，重新安裝應用程序，可能會修復此問題。”
在VS2005中，經常碰到這個問題，怎么辦呢？是去網上下載一個dll么？我沒有嘗試過。但是網上提供的一種方法是這樣的，我覺得挺簡便的。

如圖：
               
  

將"Use FAT32 Work-around" 設為yes就可以了。

今天在windows mobile的博客中，看到一篇文章名為“Widget Anatomy- The Manifest”。對于widget是第二次聽到，第一次是在一個招聘的要求里看到的。
那么什么是Widget呢？
google了一下，其實還是很糊涂。
在《Widget是什么？》中，作者說“widget"”(和RSS一樣，沒有中文名的Web 2.0產物）：可以是一個圖像圖像的部件（小插件），也可以是圖形背后的一段程序，可以嵌在手機、網頁和其他人機交互的界面(例如電腦桌面）上，其目的是：1）幫助用戶享用各種應用程序和網絡服務（Internet services），2）方便快捷；3）好玩，速度快。
在《什么是widget？widget是什么意思？》文中，  Widget-名詞—①一個小機械設備，如球形柄或者開關裝置，特別是一些沒有或者想不起具體名稱的物品。Gadget（新奇的小玩意）：在儀器板上一排的widgets。②在用戶的圖形界面上，為了實現一個具體的功能（例如卷軸或者按鈕）而使用的系列圖形符號和程序代碼。③為某項任務特定的設備或者操縱裝置--通常提供包含設定模式而行為一致的常用的widgets的widget庫。

感覺widget是一個很個性化的東西，或者很小，但是很方便，很好玩。可以好好學習一下。

引用：
1、Widget是什么？
http://blog.vsharing.com/Grigo/A572418.html
2、什么是widget？widget是什么意思？
http://info.codepub.com/2008/06/info-19918.html
3、Widget Anatomy-The Manifest
http://windowsteamblog.com/blogs/windowsphone/archive/2009/08/12/widget-anatomy-the-manifest.aspx
4、Mobile Widget 是什么？
http://www.mtrend.net.cn/bbs/viewthread.php?tid=3351

今天看的調試的這一章主要是針對多線程程序的調試。多線程程序運行的不確定性，使其調試起來就像抓蝴蝶一樣，你捉摸不透它駐足的位置。

書中給了一些建議和方法：

一是有計劃地對付錯誤。

對應用程序展開適當的調試，應該是遠在你使用調試器之前就開始了。多多使用ASSERT調試措施。（ASSERT背后的概念是安全和速度之間的交換。程序運行因此運行得比較慢，但是Debug Build的制造就是為了調試，所以可以理解）在每一個你的假設之處做檢驗工作。進入一個函數時，確認所有狀態。不要只是檢查指針是否合法；如果可能，檢查一下指針所指的結構中的數據是否一致。

二是Bench Testing

其實這種方法就是先撇開多線程的環境，測試程序邏輯的正確性。如果OK了，然后再考慮與線程相關的東西。

三是線程對話框

這里主要討論了對一個特定的線程如何調試，方法是掛起所有的線程——除了我們關注的那個。書中介紹的方法在vs 2005我沒有找到。

四是日志記錄

這里主要是在控制臺窗口顯示一些運行信息，我們可以使用printf等函數在控制臺輸出一些信息來查看線程的運行次序。

五是內存記號

使用內存記號的好處就是降低彼此干擾的可能性。但是也要注意它不是同步操作，可能會因為兩個線程的同時寫入引來問題。

六是硬件調試寄存器

 

前面的這六種方法我也只用過三種，有一些還真是第一次見到。不過不怕下次搞不定問題的時候可以拿來進行嘗試，來抓一抓隱藏在程序中的“臭蟲們”。

 

成功消除多線程程序的“臭蟲”，作者說需要具備三種素養：決心、耐心、創造力。同時也不要蠻干，要采用科學的方法：觀察、預測、測試。

 

總結一下：借助方法，觀察現象，大膽預測，勇敢嘗試，完備測試。

 

項目中也碰到了多線程的使用。未來可能多線程的使用會越來越多，不能停留在完成功能和任務上，應該多思考多測試。避免多線程的不可確定性帶來的一些困擾。

 

學習書籍：《Win32 多線程程序設計》侯捷譯

項目要結項了，自然要進行一些審查的工作。不過我是那個被審查的。審查出的一些問題，還是值得反思的。

一是注釋：雖然注釋可有可無，但是良好的注釋有助于提高代碼的可讀性。我們寫代碼的時候，有時候就比較懶，不寫注釋，或者寫大多的注釋。有的注釋沒有及時更新。這些都需要注意。

二是注釋掉的代碼沒有刪除。如果少量還好，但是在代碼中存在這個問題。可能當時只是在修改BUG時的一個改動，但是修改成功后，應該及時刪除這些代碼。否則代碼不是很美觀。

三是一些測試代碼依然存在代碼中，雖然沒有用到，但是讓人多了很多迷惑。

四是名字起的不是很規范。

這是審查的那位大師簡單一看就提出來的問題。有則改之，無則加勉。多多努力，讓自己的代碼更加漂亮起來。

最近在做項目總結，其中網絡部分的處理比較麻煩，以后交接工作也牽涉很多。于是在下了很大決心之下，決定畫一些圖來理理網絡協議的處理。呵呵，主要是對UML畫圖不是很熟。

最熟悉的UML畫圖工具是Microsoft Office Visio工具，以前嘗試過，但是總覺得不方便。呵呵，沒有用慣，自然就抱怨起來了。于是良方吧。

同事有推薦使用Rational的，不過可惜的是沒有裝成功。

恰逢公司有培訓UML使用的，培訓的是一位架構師，還好原來跟他溝通過。他給我了一個小工具，名叫Enterprise.Architect.7.0，這是一個輕便的UML畫圖工具。剛開始使用的時候真還找不到門路。慢慢摸索發現還是挺好用的。

如果你也跟我有同樣的煩惱，不如嘗試一下這個小工具。