不是李白也能 C++
Posted on April 13th, 2008 at 3:16 by fr3@K

除了語法上的困難, 另一個 C++ 常被人嫌的特性就是不如 C#(.Net)/Java/Python 之流般擁有大量標準的 library 或針對特定功能的準標準 library. 寫上一篇 (五種寫 For Loop 的方法) 時, 突然體會到這樣的現象似乎是源自 C++ 的設計與演化, 很可能是難以避免的結果.
(more…)

del.icio.us:不是李白也能 C++ digg:不是李白也能 C++ spurl:不是李白也能 C++ newsvine:不是李白也能 C++ furl:不是李白也能 C++ Y!:不是李白也能 C++ 黑米共享書籤:不是李白也能 C++ 推推王:不是李白也能 C++
WIN32 的 _TCHAR 與 std::wstring 的問題
Posted on November 20th, 2007 at 3:28 by fr3@K

我知道很多人一直是這樣做的, 可是我從沒搞懂為什麼在 windows 平台上, 用上了 _TCHAR, _TEXT 再 define 個 _UNICODE. 或是用上了 whar_t 與 std::wstring. 就能算是 Unicode 化的程式?
(more…)

del.icio.us:WIN32 的 _TCHAR 與 std::wstring 的問題 digg:WIN32 的 _TCHAR 與 std::wstring 的問題 spurl:WIN32 的 _TCHAR 與 std::wstring 的問題 newsvine:WIN32 的 _TCHAR 與 std::wstring 的問題 furl:WIN32 的 _TCHAR 與 std::wstring 的問題 Y!:WIN32 的 _TCHAR 與 std::wstring 的問題 黑米共享書籤:WIN32 的 _TCHAR 與 std::wstring 的問題 推推王:WIN32 的 _TCHAR 與 std::wstring 的問題
變更原代碼授權
Posted on September 20th, 2007 at 5:06 by fr3@K

`除了原作者之外的第二人, 在未經原作者同意之下, 是否可以把以 BSD License 授權發行的 source code 改為以 GPL 授權來發行‘. 可說是近期 FOSS 社群討論得最熱烈 (也可說是吵得最兇) 的話題之一.

前幾天, Tetralet 在他的部落格上 介紹了這個事件. 只可惜有些我認為很重要的細節沒照顧到. 而部份的後續討論 (就我看來) 似乎也有偏離重點的跡象. 我想藉由這個機會把 BSD License 弄得更清楚, 也盡我的能力把這事件做個補充, 希望能互補為一個較完整的說明.
(more…)

del.icio.us:變更原代碼授權 digg:變更原代碼授權 spurl:變更原代碼授權 newsvine:變更原代碼授權 furl:變更原代碼授權 Y!:變更原代碼授權 黑米共享書籤:變更原代碼授權 推推王:變更原代碼授權
Bye, Google Apps
Posted on May 2nd, 2007 at 22:39 by fr3@K

AACS Processing Key 被網民公開 事件裡, 除了把 key 貼出來的個人以及 AACS 兩造之外, 相關第三者至少還有 Digg 與 Google (and Wordpress?).

一開始, Digg 與 Google 都採取配合 AACS 要求的方式來處理這次事件. 事情被鬧大了幾天後, Digg 從善如流卯起來跟廣大 Digger 一起幹. 但 Google 似乎還沒有打算跟進的跡象.
(more…)

del.icio.us:Bye, Google Apps digg:Bye, Google Apps spurl:Bye, Google Apps newsvine:Bye, Google Apps furl:Bye, Google Apps Y!:Bye, Google Apps 黑米共享書籤:Bye, Google Apps 推推王:Bye, Google Apps
荒誕進行式
Posted on October 21st, 2006 at 21:05 by fr3@K

假設有本雜誌叫芭樂週刊, 沒事就喜歡到人家門口東張西望翻這翻那的, 尋找下幾期的材料, 碰碰運氣也許會發現些什麼八卦可以寫在雜誌上. 又假設小明這陣子在他自家的大門掛一塊 `下流骯髒’ 的牌子, 然後在牌子的背面寫小強的名字以及小強上班的地址 (大家都知道是廚房啦~). 結果被芭樂週刊發現了, 並且把這個故事放在封面. 買這本雜誌的人都看到了這則報導. 現在媒體報導說 `小明利用了芭樂週刊的行為模式, 欺騙芭樂的狗仔, 小強正在考慮提出對小明的控告’.

小明掛牌子有罪? 他掛什麼牌子在他家門上關誰 X 事? 何況他也只有在客人來玩耍的時候才把那牌子掀起來跟人客現寶.

還是這件事被搞大, 大家都知道了, 所以才有罪? 雖然大家都知道芭樂週刊就喜歡幹這無聊事, 但狗仔不請自來, 也是小明的錯?

是不是很荒誕? 別懷疑, 只要把上面故事裡面的名字等換掉, 你就會發現這是現在進行式.

有個搜尋引擎叫 google, 沒事就喜歡到人家網頁爬文, 尋找放進資料庫的材料, 碰碰運氣也許會發現些什麼能被搜尋的東西給使用者查詢. 這陣子我們在自家的部落格放幾個 `無能無恥‘ 的連結, 然後連結的位址寫總統府的陳總統傳略網址. 結果被 google 發現了, 並且把這連結放到搜尋結果的第一位. 用 `無能無恥‘ 去搜尋的人都看到了這個連結. 現在媒體報導說 `林姓男子 (嫌犯是 ) 利用了搜尋引擎的行為模式, 欺騙了電腦, 總統府正在研究考慮對嫌犯提出控告’.

以上不可思議的故事取材自 中時電子報 以及 東森新聞報.

[相關報導]
[澄清] 還好我有個部落格 by 山丘.
東ㄙㄣ愚蠢新聞:鍵入「無能無恥」連結總統府 府:研究是否提告 by SLZZP.

del.icio.us:荒誕進行式 digg:荒誕進行式 spurl:荒誕進行式 newsvine:荒誕進行式 furl:荒誕進行式 Y!:荒誕進行式 黑米共享書籤:荒誕進行式 推推王:荒誕進行式
我的政治妥協
Posted on October 16th, 2006 at 18:59 by fr3@K

週末的政論節目 (應該是重播), 聽到 KMT 的立委要 DPP 黨團保證, 若倒閣成功一定強力要求總統解散國會. 如此 KMT 倒閣的決心才不會有後顧之憂的說法. 不管從我左耳, 右耳甚至是兩耳同時聽, 都很難聽下這鬼扯蛋.

是的, 若倒閣成功之後總統宣佈解散國會, 的確是能夠立下一個好的憲政慣例, 也能透過立委重選為罷免案在國會通過的機會大為增加, 至少會為現在怎麼都過不了的狀況, 添加許多變數. 很明顯的, 就 個人立場, 我是很歡迎能看到這樣的發展.

問題是 KMT 與 DPP 雙方的關係或許用決戰的兩軍來形容有點怪, 但怎麼說都是立場決然不同, 不互相信任也沒有合作關係 (至少檯面上) 的兩個黨. 要求 DPP 給對手在上戰場前鼓舞士氣的保證實在是很不倫不類.

或許這說法也只是一個委員的個人意見. 可是 (我聽到的) 馬主席的發言總是說尊重黨團決議, 就我而言, 完全聽不出 KMT 針對這個議題的具體策略與立場.

政治就是妥協. 總以為這句話對小老百姓如我, 是八竿子打不著關係. 那個候選人的訴求/特色最接近我的價值觀, 我的選票就往哪去, 對候選人沒特別喜好就選黨. 這次最大反對黨 KMT 的表現太讓我失望, 很難讓我寄望 2008 換馬英九上去會有太大作為.

山丘說得很好, 阿扁的確 無能無恥, DPP 天王們對他的保護也顯得他們自己無恥. 而馬主席呢? 好像還沒無恥那麼糟糕, 但無所作為卻似乎愈來愈是個大問題. 如果明天就選下一屆總統, 候選人有血統正確但無恥的 DPP 天王, 守法但無所作為的小馬, 能力受肯定但滑不溜兜 (假設脫黨參選, 台聯?) 的王金平. 我想我會妥協, 把我的票投給後者.

[相關觀點]

ijliao - 罷免 ? 倒閣 ?
山丘 - [觀察] 做個稱職的在野黨

del.icio.us:我的政治妥協 digg:我的政治妥協 spurl:我的政治妥協 newsvine:我的政治妥協 furl:我的政治妥協 Y!:我的政治妥協 黑米共享書籤:我的政治妥協 推推王:我的政治妥協
OSX Ditching Microkernel?
Posted on May 30th, 2006 at 14:14 by fr3@K

OSX 為了要讓 M$ Windows 軟體以 native 方式跑在 OSX 的 Intel 版本上 (類似 WINE 的作法?),能在執行速度取得較佳的效能,可能會放棄現行 Microkernel [1] 架構,轉而採用 Monolithic Kernel [1]。

前 一陣子,在網路上看了許多 Microkernel vs. Monolithic Kernel 的文章。Linux 可說是 Monolithic Kernel 的代表陣營,而 Andrew S. Tanenbaum 為 Microkernel 扛大旗 [2]。兩種架構互有優劣,Monolithic Kernel 最主要的優勢為執行速度。而 Microkernel 則是 stability 與 security。

典型的 Microkernel 負責的事情很少,只有低階 processe 管理與 scheduling、IPC、interrupt、基本的記憶體管理,以及少數其他東西。其他的 service,如 filesystem、driver 等等,各自跑在不同的 process,透過 message pipe 與kernel 或其他 service 溝通。Monolithic Kernel 的作法完全相反,除了 user application 之外的程式,幾乎都跑在 kernel space (同一個process)。

溝通 (或說訊息分享) 容易以及高效,自然成為跑在同一個 process 的明顯優點 - 一個 module 不需要複製資料,或經過 message pipe,就可以直接把指向資料所在的指標丟給另一個module。但是`容易以及高效’卻不能簡單地與`好’劃上等號。

想像一下兩種 module 互動的狀況。跑在同一個 process 就類似於在一個team中一起工作的兩個人,坐在相鄰的位子做事情。理想狀況 下,甲可以好聲好氣地跟乙說我需要你幫忙弄某某事情,然後乙做完了再回報甲。如果甲今天心情不好 (就像一個寫得不好的 driver),由於沒有保護,他可能也可以把乙痛打一頓。而跑在不同的 process 比較像是去銀行辦事,在顧客跟行員中間有塊防彈玻璃,雖然這樣做事麻煩些,說話也要透過麥克風。但如果某個人走進來要搶劫,卻不是那麼容易得逞。更別提同 一個 process 一旦掛了整個 process 就 全掛了,想要 recover 回來,即使不是不可能也會是非常困難。

如果 OSX 真為了拼效能,選擇從 Microkernel 轉換為 Monolithic Kernel。雖然可能可以在與 Windows 對決速度時,得到較亮眼的數字成績。在今天這個硬體速度被 Moore’s Law 主宰的世界,只怕是往後退了一大步。

ps. 對現行 OSX 核心有興趣可以看看 Operating System Concepts 的這篇附錄 (PDF格式)。

[1] 不同人與組織對 Microkernel 與 Monolithic Kernel 的評價常呈現兩極化,因此故意沒提供連結。強烈建議有興趣請自行 google,多看看不同的觀點。
[2] 其實他真正提倡的是 reliable and secured OS,而 Microkernel 正是他認為有效的手段之一。

del.icio.us:OSX Ditching Microkernel? digg:OSX Ditching Microkernel? spurl:OSX Ditching Microkernel? newsvine:OSX Ditching Microkernel? furl:OSX Ditching Microkernel? Y!:OSX Ditching Microkernel? 黑米共享書籤:OSX Ditching Microkernel? 推推王:OSX Ditching Microkernel?
Free Software vs Open Source
Posted on April 12th, 2006 at 19:18 by fr3@K

Free SoftwareRichard Stallman 於二十多年前離開MIT開始推廣的運動)常被許多人與 Open Source(於1998年由 Free Software 分支出來的運動)混為一談。

Free Software 強調的是行使自由的權利。這裡指的是言論自由(free speech)的自由,而非免費喝到飽(free beer)的自由。 (more…)

del.icio.us:Free Software vs Open Source digg:Free Software vs Open Source spurl:Free Software vs Open Source newsvine:Free Software vs Open Source furl:Free Software vs Open Source Y!:Free Software vs Open Source 黑米共享書籤:Free Software vs Open Source 推推王:Free Software vs Open Source
The Hungarian Notation
Posted on January 22nd, 2006 at 3:46 by fr3@K

在 open source 的世界也好, 在公司內部也好, 任何像樣的 project, 大都免不了採用或自訂一套 coding convention. 不同 coding convention 所要達成的目標並不盡相同, 但都有個共同點 - 讓你寫的 code 看起來像是別人寫的. 主要原因是 - 這樣做應該可以讓他人容易閱讀/理解/修改你寫的 code.

Coding convention 主要分為兩個部份:

  • Naming notation (命名法)
  • Formatting (程式格式/排版)

以我個人經驗以及從朋友處得到的消息來看, 公司內部最常採用的 naming notation 是 Hungarian Notation (匈牙利命名法). 把 Hungarian notation 傳播到世界各地, 甚至錯誤地使用在例如 C++ 之類的 strong-typed (或是接近 strong-typed) 語言上, M$ 功不可沒, Win32 SDK 與 MFC 是其中經典之作. 時至今日, 就連 M$ 內部也已展開了反撲, 最好的例子就是 .NET 丟開 M$ 過去採用 hungarian notation 的包袱.

痛恨 hungarian notation, 但這通常不會造成我在工作上的困擾. 我總是能幸運地說服同事與上司放棄它, 或至少不強迫我採用它. 不過還是常會有朋友跟我抱怨公司強迫他們採用 hungarian notation, 他們多是無奈接受. 這帖 blog, 就是為了這些朋友寫的, 如果你剛好在這些公司工作, 不妨把這帖 blog 的 link 轉給你的同事或上司.

Annoyances of the Hungarian Notation:

  • 視你為弱智. 認為你替變數取的名字大都不好, 很難從名字辨認大約的型別
  • 視你為白痴. 認為你有可能會 - 把一個叫做 size 的變數 (不是 integral type 還能是什麼?) 誤判為一個 ifstream 的 instance
  • 視 strong-typed compiler (如 C++ 編譯器) 為低能. 認為 compiler 有可能會 - 在你把一個叫 name 的變數 (不是某種字串還能是什麼?) 當作 ComboBox 來操作時, 不產生 compile error

我常用的命名法則是盡量口語化, 並試著恰如其分地命名. 舉例說明較快:

  • Instance of integral type
    • unsigned long user_count;
      int offset;
      size_t index, received_bytes;
  • User-defined type
    • class Contact;
      class FastString;
      typedef list<Contact> Contacts; // or ContactList
  • Instance of user-defined type
    • string english_name;
      Contacts kens_contacts; // or contacts_of_ken
      Window main_window;

誤判以上所舉例子型別的人, 或許該考慮換個工作 :(.

當然, 上例都是淺顯的例子, 從我個人經驗來說, 應用這原則倒也沒遇過特別困難的狀況. 我想說的並不是我用的方法多好, 而是希望別再有更多人強迫他人或被他人強迫用什麼彆腳的 dwData, wndMain, ctrlBrowser, nCount, szName 來寫 C++.

del.icio.us:The Hungarian Notation digg:The Hungarian Notation spurl:The Hungarian Notation newsvine:The Hungarian Notation furl:The Hungarian Notation Y!:The Hungarian Notation 黑米共享書籤:The Hungarian Notation 推推王:The Hungarian Notation