分享一個前幾天幫忙排除問題的趣事，事後看覺得再明顯不過，發生當時卻讓人困惑了一下。前幾天要下班時，發現同事還在奮戰，所以就過去湊一下熱鬧。原來是他正在為某個平台建立 cross-compile 環境時碰到麻煩。
這裡說明一下，我們團隊的「cross-compile 環境」其實就是一個個 chroot，預先裝好了目標平台的 cross-toolchain、程式庫，並設定好環境變數。通常這些 cross-compile 都是由熟悉 Linux 環境的人事先打包好，新加入者只要按照產品型號下載對應的編譯環境，就可以立即上手建置專案。當硬體廠商更新驅動程式、或者程式庫 推出安全性修正時，負責的同事必須要更新編譯環境，有時候重大的調整會需要整個砍掉重頭建起。
在程式中通常有若干種方法將資訊串成字串，一些可能的寫法如：
msg = format("Do you want to delete %s from %s?", user.name, group.name);
msg = "Do you want to delete {1} from {2}?".format(user.name, group.name);
msg = "Do you want to delete " + user.name + " from " + group.name + "?";
msg << "Do you want to delete " << user.name << " from " << group.name << "?";對於多數應用來說，以上並沒有其中一個做法比其他具備壓倒性優勢，所以在使用上有很大程度取決於個人喜好。有些比較具有經驗的人可能會覺得 formatter 風格比較容易閱讀，不過當插入的資料太多時一樣會造成畫面破碎，而且資料和插入位置不容易對起來。
前陣子在程式人雜誌參與了關於編譯器書籍的討論，我想說自己都打了一堆字，不如整理一下放上來。
講到編譯器書籍，很多人都會想起 Aho、Sethi、Ullman 和 Lam 的勇者鬥惡龍，這本書深度和廣度兼俱，所以被許多課程採用為教科書。但本書二版在 amazon 評價偏低，可見不符合許多人的期待。我認為每個人取向不同，不必妄想一本傳說中的經典就可以涵蓋理論與實務全面知識，而且對於學習者來說容不容易吸收也很重要。
程式碼用什麼格式儲存？還用問，當然是「純文字」囉。其實這個問題並不簡單，所謂的「純文字」可能是眾多編碼當中的一種：
對於只用 ASCII 字集寫程式的人來說，用什麼編碼儲存程式碼應該都沒有差別。但有很多人會在註解和 string literal 裡面放其他語言的字集，這就是個問題。別誤會，我並不是說原始碼當中不能出現非 ASCII 字符，而是說很多人是在欠缺考慮的情形下寫出這種程式碼。
(未定稿，近期仍可能頻繁修改，歡迎提出各種建議，不論是技術方面或是文章描述方面)
在即將邁入 2013 年的今日、Unicode 已推出 6.2 版，Unicode 好像已經屬於沒什麼好介紹的基本常識了吧？其實，這篇文章某種程度上是為了「訂正」而寫的。如果我沒記錯的話，嗯，本文的第一個版本是在七年前寫的。說來挺不好意思的是，之前的版本在技術上從來就沒有完全正確過，雖然都不是很嚴重的錯誤。還好早期版本所發表的地方都相對短命，應該沒有誤導到太多人。
「C++ 是 context-free 嗎？」這是我在很長一段時間裡，分別在 stackoverflow.com 等許多地方都看過的問題。類似的問題還有其他變形，有時主角換成別的程式語言，或者變成「...是否為 context-sensitive」等等。
我發覺這類問題似乎具有某種雞同鴨講和鬼打牆的傾向，有些參與者沒有先釐清概念、用詞也不統一，以致於耗費大量篇幅卻難以觸及重點，反而顯示出許多人對於形式語言充滿誤解。我甚至看過一些人拿某某程式語言不是 context-free 做為不喜歡某某語言的理由，但是他很明顯沒有搞懂 context-free 的意義。
最近一直沒時間寫新文章，所以貼篇舊聞。
Donald E. Knuth 是在大學時期打工才接觸到電腦，那個時候他剛好也在學校籃球隊幫忙。他紀錄了每位球員在不同位置的表現，並且在 IBM 650 主機上設計程式進行統計分析，以這些資料作為球員調度的依據。原本 Case Institute of Technology 在上年度只有贏得 6/16 場球賽，使用 Knuth 的方法後至少已經贏得 11/14 場球賽，後來成為聯賽冠軍。
最近在 trace 的程式碼當中讀到類似下列這樣的片段
TCHAR name[MAX_NAME];
...
::GetWindowText(hwnd, name, sizeof(name));
對我來說這是一個明顯到不行的錯誤，就算混雜在一大堆別人寫的程式碼中，被我認出來的機會也很高（這不就被我抓到了嗎？）。我大概可以想像這個程式過去不太用 UNICODE 編譯，因此這樣的錯誤有時會存在很長一段時間沒發現。由於這是個使用者眾多的軟體，所以我查了一下，這個錯誤在原軟體中好幾年前就已經被修正了，但是一些第三方提供的 plugin 至今仍然引用到早期版本的原始碼。
Computer (6)