novus log

最近有點想將一些未發表或者發表在別處的文章整理到這裡來，不過想歸想，我的行動力一向很低，所以做多少算多少吧。目前只完成了《淺釋 Unicode》那篇，結果重寫了八成以上...
其中一部分是之前發表在「超自然揭祕」的文章，因為該社團被關掉，我想把自己寫的東西放在這裡也好。另外有一些是自己做的筆記，內容比較雜亂，這類文章通常要花上一番功夫才比較好意思放上來。我總覺得要放在網路上分享就應該要維持一定的品質，否則還是放在自己硬碟做為備忘就好了。我大概看了一下，手邊比較完整的是關於 smart pointers 的系列。不過我之前是針對 Boost 而寫，現在想改為 C++11，如此一來就必須重新確認相關細節。C++11 未收錄的 intrusive_ptr 反而比較沒有顧忌，或許會列為優先整理的對象吧。
還有一件事情，我發現以前寫的機率相關文章相當不嚴謹，特別是專有名詞亂用一通，有點意外沒人吐槽這點（對了，本部落格歡迎找碴）。這裡牽拖一下，和很多人一樣，我最後一次在課堂上學機率是在高中時代，後來許多常識是從普及性讀物獲得，更進階的知識則是直接讀英文文章，因此我常常沒注意到很多概念所對應的中文譯詞。希望有空能改寫，但是好懶啊。

---

反射式 LCD 改為黑底白字
連結：http://tw.myblog.yahoo.com/ncc1701-x/article?mid=217&prev=-1&next=212
網友 NCC-1701Z 提供的 一個有趣小技巧，雖然說看到就大概猜到原理，但平常很少拆解這些東西，所以就沒想到這一招。

我是星期天才讀到這個消息的，本來想寫點什麼，但卻又不知道要寫些什麼。洪老師長期關注這類議題，我想他的文章對這件事的分析比較深入。
http://ckhung0.blogspot.tw/2013/01/aaron-swartz.html
http://www.inside.com.tw/2013/01/15/aaron-swartz
不過一條人命又如何呢？在智財權被濫用的今天，一首歌甚至比三條人命值錢。

（這只是一篇個人記事，並非影評，也不會洩漏劇情。）
我不能算是真正的托爾金迷，但對於魔戒系列電影有種特殊感覺。其實《哈比人歷險記》是我唯一讀過的托爾金小說，當年在《魔戒I》上映的前夕，一位死黨塞了本《哈比人歷險記》給我，基本上我對小說來者不拒，所以一口氣整本看完。
以現在的後見之明來看，這位死黨的推薦可謂深謀遠慮，讓我在事先不知道《魔戒I》劇情的情況下先對故事背景有所了解，所以看電影的時候很快就能進入狀況；等十年後忘得差不多的再看《哈比人》電影，又可以獲得同樣的新鮮感。總之，我對魔戒的感受不只是電影本身，有部分出自於懷念那個有人會塞小說給你、拖你去戲院的年紀。
因為有這層特殊的因緣，所以《哈比人：意外的旅程》被我列為今年必看的電影，照慣例這類電影我事先盡可能 不 蒐集任何資訊，連預告片都不會看，避免破壞那種新鮮感（你們可以笑我，但我有慘痛經驗）。憑著對小說模糊的印象，當電影進行到差不多 60% 的時候，我忽然領悟到一件事：照這個劇情進展速度來看，這部電影鐵定演不完所有的故事，除非結尾非常草率。但光從比爾博家磨掉的時間看來，這部電影沒道理胡亂收掉，所以唯一的可能就是還有續集。（華生，你終於突破盲點了）

程式碼用什麼格式儲存？還用問，當然是「純文字」囉。其實這個問題並不簡單，所謂的「純文字」可能是眾多編碼當中的一種：

「本地」使用的編碼：例如 Big5、GBK、Shift-JIS、ISO-8859-1,2,... 等等。Windows 下的編輯器常以此為預設。
UTF-8：一些 Linux 的編輯器可能以此為預設。
UTF-16、UTF32：這類編碼方式非常不適合用來儲存程式碼，這裡不討論。

前言
(未定稿，近期仍可能頻繁修改，歡迎提出各種建議，不論是技術方面或是文章描述方面)
在即將邁入 2013 年的今日、Unicode 已推出 6.2 版，Unicode 好像已經屬於沒什麼好介紹的基本常識了吧？其實，這篇文章某種程度上是為了「訂正」而寫的。如果我沒記錯的話，嗯，本文的第一個版本是在七年前寫的。說來挺不好意思的是，之前的版本在技術上從來就沒有完全正確過，雖然都不是很嚴重的錯誤。還好早期版本所發表的地方都相對短命，應該沒有誤導到太多人。
本文的目標很單純，只希望以後讀者遇到與文字編碼有關的選擇時，能夠清楚地知道自己在做什麼。因此我會從比較偏向實用的角度整理相關知識，而非專注於編碼的技術細節，畢竟大部分的人都沒有必要挽起袖子親手處理底層格式。

剛剛忽然察覺今天是  Ada Byron 的生日。Happy birthday to Ada！
說起這個，前陣子一時興起想研究一下 Jacquard loom 的運作原理，畢竟沒有 Jacquard loom 就沒有後來可程式化的的分析機。結果在網路上找到一些古書，發現實在不太好懂，所以就算了。

「C++ 是 context-free 嗎？」這是我在很長一段時間裡，分別在 stackoverflow.com 等許多地方都看過的問題。類似的問題還有其他變形，有時主角換成別的程式語言，或者變成「...是否為 context-sensitive」等等。
我發覺這類問題似乎具有某種雞同鴨講和鬼打牆的傾向，有些參與者沒有先釐清概念、用詞也不統一，以致於耗費大量篇幅卻難以觸及重點，反而顯示出許多人對於形式語言充滿誤解。我甚至看過一些人拿某某程式語言不是 context-free 做為不喜歡某某語言的理由，但是他很明顯沒有搞懂 context-free 的意義。
攤開 C++ 的規格書，裡面有一份詳盡的文法，其中每條 production rule 左邊都只有一個 non-terminal，所以是 context-free grammar (CFG)。這裡要注意的是「ISO C++ 規格書附的文法」並不是形式語言意義上「C++ 語言的生成文法」，因為「ISO 規格書附的文法」所生成的字串不保證滿足所有 C++ 語言規範。

這是一位網友的問題，原問題見http://www.ptt.cc/bbs/C_and_CPP/M.1351841869.A.BAF.html。本部落格之前也稍微碰過這個主題，不過之前的重點在於腦筋急轉彎式的模擬 __VA_ARGS__ 功能，實用性是另一回事。
在開始討論各種作法可行性之前，這裡先宣導一項原則：應該要讓正常輸出與非常態輸出分流，更精確的說，給使用者看的輸出應該要和給開發者看的輸出分流。例如使用 stdout 作為正常輸出時，就不應該也用 stdout 作為非常態輸出，而是改用 stderr 或檔案。實戰中非常態輸出的 sink 很多樣，這裡就不多說了。即使不想多花心力去設計非常態輸出機制，使用基本的 stderr 並不會比用 stdout 多費功夫，好處卻是立即可見，可謂有利而無害。

最近看到有人出了一個考初學者的問題，於是我改了一個複雜化的版本，應該蠻適合拿來鑑別初學者的程度。假設使用的語言為 C++，下面這個 expression 有幾種可能性？
(f(a) && f(b))

任何一個有把教科書第一章念完的人差不多都會回答，執行順序類似於：