發表文章

目前顯示的是 2月, 2009的文章

VirtualBox昇級

自從使用VirtualBox後,先後安裝了兩個作業系統,一個是Linux Mandriva 2009,另一個是Vista。Mandriva是用來學Linux用的。而Vista呢,則是用來進行一些測試用的。 最近,每次使用VirtualBox時,它總是會提醒說有新的版本可以下載來進行更新。可是,我上網站看了一下,結果都沒有提到如何昇級的部份。在網路上又搜尋不到其它的說明,就這樣一直使用舊的版本。 今天,終於是忍不住了,就下載新的版本下來。想說如果沒有特別說明的話,那應該就是先解除舊版的安裝,再安裝新版的吧。其它部份的設定,大不了就重新設定好了。於是就進行這樣的昇級。 結果,一切正常。而且新版本還可以沿用舊的設定值,我想應該是解除前一版本時沒有將設定值給清除吧。而且,舊的作業系統檔也都自動被轉換成新版本了。

const_cast的應用

話說我正在處理一個小程式時,需要用CListCtrl來顯示資料。此時我有一個函式: void ShowOnListCtrl( const cLocation a_Location ) {       ...       LVITEM Item;       ...       Item.pszText = a_Location.m_Name; // m_Name的型別為CString } 很直覺的,我就寫出了上面的程式碼。結果,一編譯就錯了。 我的專案使用的是UNICODE,所以Item.pszText的型別為LPWSTR。於是我想說那改成這樣應該可以吧: Item.pszText = (TCHAR *)a_Location.m_Name.GetBuffer(); 結果還是錯。來來回回試了好幾次,最後才發現,原來a_Location是個const修飾的變數,所以無法直接將它的內容指派給一個非const的變數。而且,我本來是想說用static_cast()會reinterpret_cast()的方式來處理,不過都還是錯誤。因為前提就是a_Location就是個const的變數。 最後還是得解決const這個問題。所以就找到const_cast()這個巨集。有了const_cast(),我又改為下面的寫法:   Item.pszText = const_cast<cLocation>( a_Location ).m_Name; 還是錯!原來const_cast沒辦法轉換非指標的變數,所以只能以如下的方式來寫了:  Item.pszText = (const_cast<cLocation *>( &a_Location))->m_Name; 終於可以編譯成功了。 這次用到了我以前都沒有用過的const_cast巨集,而且它竟然只能針對指標來運作,而無法套用於非指標變數中。真是又學了一招。

UNICODE環境下使用STL

最近在處理一個小程式時,發現以往寫的小工具類別程式碼,因為都是基於多位元組字組的方式開發的,所以在使用STL時,也都直接使用多字元組字集(MBCS)的函式。 這些程式碼在引用到用新的V S2008(或VS2005)上面時,因為新專案一開始就預設是使用UNICODE了,所以一編譯起來就出現一堆的錯誤。 為了改正這些錯誤,並且讓舊程式碼也能在舊程式中正常編譯,就必須使用一些小技巧。 目前己知的錯誤大都是: string在UNICODE環境中,要改為wstring ifstream 在UNICODE環境中,要改為wifstream 為了能通用於所有環境,我是寫了一個小的標頭檔,在這個標頭檔中會依目前是否有定義巨集UNICODE 或 _UNICODE來決定要使用string / wstring 大致上的內容如下: #pragma once #include <string> using namespace std; #if defined( _UNICODE )  || defined( UNICODE ) typedef wstring STLString; typedef wifstream tifstream; #else typedef string STLString; typedef ifstream tifstream; #endif   不過,使用這個標頭檔的話,還是得要將舊程式碼中的string改為STLString才行。大部份舊程式就不用改了,那新的程式可能就是要養成習慣都使用通用的類別名稱STLString(之類的) 在CodeProject中也有找到類似的資料, 可參考一下 。

製作自已的徽章

無聊在網路上看文章,發現竟然有個網站可以該你 製作自己的徽章 。還蠻好玩的。

MFC Button使用PNG圖示

最近在寫個小程式時,突然想要在MFC的CButton按鈕物件中顯示一個PNG圖示。所以就在網路上搜尋了一下,發現有 篇文章 有提供一個已開發好的新類別來完成這項功能。

C# 非同步函式呼叫

最近在CodeProject看到一篇文章,在討論C#中的非同步函式呼叫( Asynchrous Method Invoke )。這篇文章中對BeginInvoke()/EndInvoke()的非同步呼叫說明的非常詳細,而且也用了很多程式碼範例來輔助說明。 其中它有證明說在使用BeginInvoke()這種非同步函式呼叫方式時,它當然會需要使用到執行緖,所以它會用到的就是C#中的ThreadPool。要確認目前執行的程式碼是否在ThreadPool的執行緒中執行的話,可以用: Thread.CurrentThread.IsThreadPoolThread 這個屬性來確認。 使用ThreadPool當然有它的好處,因為它可以限制同一時間最多只會使用到某一定量的執行緒。這樣就不會因為同時間有太多的執行緒在執行,造成CPU秏費過多的時間在執行緒間進行切換(ContextSwitch)。 不過,使用ThreadPool的執行緒時,要小心一點,就是不要一直佔用執行緒不放。例如有一項工作會等到預訂的時間才開始進行的話,那一般就會用Thread.Sleep()一段時間後,再接續執行。而在Thread.Sleep()時,CPU的執行時間雖然會被切換給其它執行緒來執行。可是您用來Sleep()等待的執行緒此時也被您給佔住了。造成ThreadPool中可用的執行緒就會少一個。 這種情形一多的話,說不定就會用光ThreadPool中的執行緒,而造成後續的工作都無法處理。

雲端運算-將控制權交給別人

雲端運算原來就是將一些原本要在個人主機上運算的工作,透過網路交由廠商的伺服器來進行運算。這些廠商可能是像Google、微軟等大型廠商,可提供大量的運算能力。 可是這樣一來就表示您必須將資料交給別人來進行處理,而且運算上也都是「看別人」的臉色。等於將控制權也交給了別人。這樣看來,好像也不太好。哈。 參考資料: http://www.zdnet.com.tw/news/software/0,2000085678,20132147,00.htm

雲端運算跟Azure

自從Google提出「雲端運算」的概念後,這個名詞就一路流行了起來。其實本質上來看,雲端運算就像是以前提過的一個概念:「分散式運算」一樣。應該是將工作折解成數項工作,再分散給不同的伺服器來進行運算。 微軟最近也開始提出一套類似雲端運算的架構供程式開發人員使用。名稱叫作Azure。以下是 一篇不錯的介紹 ,如果有需要SDK的話,可到這 下載 。不過,感覺上好像使用Azure SDK開發的應用程式要在執行Azure作業系統上執行。當然目前微軟是提供免費的Azure平台給大家使用。不過等到技術成熟時就要開始收費了。 說到分散式運算,其實應該也可以用其它方式來達成吧。看網路上有人說 BOINC 是目前最好用的一套分散式運算作業系統。有興趣的人可以去玩看看囉。另外,分散式運算也有 討論區 喔。 如果你想要使用BOINC參加柏克萊大學無線電波望遠鏡的訊號處理計畫,提供您的電腦運算能力幫他們計算的話,可參考 這篇文章 。

便宜的防毒軟體-avast 三年版,二人授權

最近在Mobile01看到有人分享說最近 avast! Profession Edition,3年版、2人授權只要NT3704元 。算算每人/每年只要617元。 avast!算是一套不錯的防毒軟體。以前使用Norton時,有一陣子有個些毒都無法掃出。後來,看到有人說avast!有免費版,就去申請了一年的授權。安裝後,它第一次會在開機時進行掃毒。這時就會將一些毒給掃出來。這是Norton無法做到的。所以後來有一陣子就都用avast!而不用Norton了。 現在avast!有便宜的版本了,有興趣的人可以去試試。至於我,因為前陣子有人說7-11在買的PCDIY有搭售Norton 2009,只要一本雜誌的費用。等於Norton 2009是免費的,所以現在就先用Norton一年再說囉。

PHP之父談網站程式開發

最近在iTHome上看到一篇專欄,在介紹PHP之父Rasmus Lerdorf談論他的 開發秘訣 。雖然他主要談論的都是有關網站應用程式的開發,不過,從這篇文章中大致上也可以學到一些一般應用程式開發的概念。 不要使用開發框架 他提到一點就是開發時不要套用開發框架。因為一般的開發框架大多會有一些限制存在。當然如果你要開發應用程式的原型的話,那倒是可以套用開發框架,因為這樣開發的速度比較快。當您要正式開發時,這時就只要擷取開發框架中的優點來套用,再加上自己針對本身要開發之應用程式的需求規劃出來的架構來開發,會比完全套用開發框架來得好。 規劃未來的擴充性不要超過半年 「當你無法預測未來,你就無法幫未來作決定。」這段是文章中Rasmus Lerdorf所提到的。我本身也有同感。因為未來的需求實在太不確定了。變化一直在發生,再如何詳儘的規劃都趕不上變化的。所以預先規劃是要,但是只要預想半年後的需要就好了。