c++ self testing

在網路上看到的幾個c++問題，個人覺得有一些還有點難，不過多懂點總是好的。

1. 什麼是virtual inheritance? 請舉例說明。
2. 什麼是virtual function? 什麼是pure virtual function?
3. pointer與reference的差別?
4. 什麼是static_cast, dynamic_cast, reinterpret_cast, const_cast? 他們之間的差異是?
5. run-time polymorphism與compile-time polymorphism的差異? 分別要如何達成?
6. 什麼是explicit constructor?
7. 什麼是template disambiguator? 請舉出例子。
8. 有沒有聽過boost or loki? 有沒有用過boost or loki? 請舉出例子。
9. 有沒有聽過CRTP (Curiously Recurring Template Pattern)與PBCP (Parametric Base Class Pattern)? 請寫出兩者的sample code並比較它們的差異。
10. 請問在C++中, struct與class最大的差異是?
11. 請問什麼是template partial specialization?
12. 什麼是type traits? 什麼是tag dispatch? 請以簡單的程式碼說明之。
13. 有聽過template metaprogramming嗎? 請舉例解釋之。
14. 什麼是SFINAE? 請解釋之。
15. 為什麼常常看到template的程式碼寫在hpp裡，而不是放在cpp檔中?
16. 什麼是functor? 用過(或寫過)任何的functor library嗎? 例如boost function/bind或是fast delegate?
17. std::list與std::vector的差異是什麼? std::map裡的資料結構是如何實作的?
18. 何謂copy constructor? 如何阻止一個class被copy?
19. virtual function是如何實作的? 什麼是vtbl?
20. 在template的宣告裡，typename與class的差異是? 為什麼有typename這個keyword?
21. 什麼是forward declaration?
22. 如何解決header file mutual inclusion的問題?
23. 什麼是templated class? 什麼是class template?
24. 什麼是wchar_t? 有沒有用過std::locale跟std::codecvt?
25. 用過那些c++ compiler? 有沒有聽過c++0x? 試舉出c++0x的新功能。

看完韓劇貝多芬病毒了

其實我是到最近電視又在重播時才看到，以前聽過有這個電視但是因為是韓劇，我心裡有刻版印象，不怎麼喜歡韓劇，所以沒想要看。但這次看到重播時，不知怎的，竟然想看看好了，現在回想那時開始看的時候可能是太閒了。

貝多芬病毒讓我第一個連想到的是日劇的交響情人夢。同樣是以古典音樂為連接劇情的要素，略有不同的是交響情人夢的角色群是一群將畢業的音樂系學生，而貝多芬病毒是一群業餘的音樂愛好者。

前半還不錯，劇情在大家的音樂路上打轉，也為後面的劇情鋪陳，但是過了前半之後劇情的重心開始轉向韓劇經典的三角戀和人生重變上，這我就開始有點看不下去，因為開始變成愛情劇，音樂的劇情變成是連接事件的跑龍套，讓我滿失望的。我一邊看一邊開始想到之前陪老婆看的另一個韓劇"On Air"，裡面描述的連續劇製作方式要每天看每個分鐘的收視率來決定後面的劇情要怎麼修改(或是說由收視率而產生的改劇情壓力)，還要因應不同的主角受歡迎的程度改劇情，讓收視好的人出現多一點，收視率才能高一點，那劇情怎麼辦呢？只好叫編劇去坳囉。這就像我們常聽到的台灣本士劇的拍法，從一開始的劇情主題到後面都不一樣，中間可能還換了好幾個不同的主題，還能對時間快速做出回應。如果劇情是一篇文章，應該會被國文老師從窗戶丟出去吧。我嚴重懷疑貝多芬病毒也是這樣拍的。拍到後面發現還是要回到三角戀啊，得什麼重病、生父大逆轉啊這種灑狗血收視率才會好。所以後半部分我有點看不下去。到後面的音樂成分都快變成只是角色設定，連串場龍套都稱不上了。所以說，雖然我無法確定他是看收視率而改劇本變成狗血劇還是鋪陳的比較好的狗血劇，對我來說都差不多了。話又說回來，如果一開始就是要做狗血劇還能讓前半部保持不灑狗血的劇本應該也不多吧。都決定要灑狗血還有什麼好客氣的。

和交響情人夢比起來，交響情人夢很清楚的刻畫音樂系學生的徬徨和憂心。不過本質上來說交響情人夢的原著是少女漫畫，重點不在於深入的刻畫或真實的呈現，但是搞笑的方式也表達到了一部分苦澀的現實。

貝多芬病毒也試圖表達學音樂的人在現實生活和在對音樂的熱情的衝突。像劇中戲份也滿多的一個double base手，在太太很支持他的音樂熱情下，他還是要為了現實生活降低對音樂的投入。還有一個這應該就是拉cello的大嬸，以前先生就是愛看他拉cello，但在婚後為了家庭，一直壓抑自己，包括對音樂的夢想。這大概就是交響情人夢的角色再過十年後的劇情了吧。

整個劇情中最能打動我的一句話就是女主角說"為什麼有人這麼有才華卻二十幾年都沒感覺，有的人這麼的有熱情卻沒有才華"(大意如此，記不得原台詞)。這不只可用在音樂上，簡直就道盡了人生的苦楚。很清楚的知道自己的夢想自己的熱情是自己所無法達成的，認清事實那瞬間的心碎真是無法形容。

所以像我這種隨便玩玩隨便合奏就能得到快樂的人，應該也是一種幸福吧。

整體而言，我覺得前半比後半好看，金明敏演的毒舌指揮家演的很不錯，很多小地方都能表達出那種感覺。所以真正的結論是，李智雅很正。:D

電影 美味關係

今天跑去看了美味關係這電影。看完之後第一個感覺還是中文片名實在取的不怎麼樣。雖然我是被中文片名吸引到才注意到這部電影。但是他讓我聯想到另一個偶像劇，事實上，這兩個是完全沒關係的。就事論事來說，這個片名的意義其實在某種程度上有表達出電影的主線，但是我猜應該也是台灣片商刻意選這個己經有偶像劇用過的片名想要引吸人的好奇。否則絕對可以有比"美味"這兩個字更好的詞。畢竟這個片子說的並不是美食本身，而是製作美食的過程。但是話說回頭，我還是被這個名字給引吸了，片商也算是成功了。對片商來說最重要就是引吸人進電影院去看嘛。

烹飪真的是滿好玩的一件事，除了在烹飪的過程中期待美食以外，看著自己完成的成品也是非常的有成就感和滿足感。雖然我不像電影裡拿著半正式的食譜(照道理說，電影裡所用的食譜是給非專業廚師，應該也有某種程度的簡化，尤其是技術上的簡化)，最常玩的還是懶人食譜之類連味道都會簡化的食譜，但是還是能享受到烹飪的樂趣。當然還有體重的增加。

另外一提，之所以常用懶人食譜其實倒不是怕麻煩不動手，烹飪最大的樂趣可是在過程不在結果，然而每次買一堆食材，特別是調味料，買了一整瓶永遠用不完，最後的下場常是過期出清。浪費錢也浪費食物。就只好老是找食材多重複的笨蛋食譜了。

電影裡還表現到了一件事，不過我覺得我應該是職業病才會注意到這種事。電影裡Julie把挑戰大師食譜(至少也能算是正式的廚師，畢竟從藍帶烹飪藝術學院專業廚師的課程畢業了)的過程寫在blog上，在網路上受到歡迎，進而有出版社願意幫他出書，tv show想邀請他，最後還拍成了這部電影。這都是現在成功的部落客的成功模式。事實上這個電影也是從真人真事改編，也真的有(Mastering the Art of French Cooking)這本書唷。但這種成功的背後是要有專注的主題，頻繁且持續的更新，才能引吸網友的注意，而且現在可能還要再加上跟網友的互動，這部分電影倒是沒特別著墨，但是看到不停的數有幾個comment，這還滿寫實的:) 。片中要在365天做過524道菜，平均每天要做一至二道菜。每次都有更新的話，最慢二天就會有一次的更新。並不是一時興起開一個blog，零零星星的放幾個文章就想要成名出書。這部分和網路的現實十分接近，我不知道是是真人真事所反應的事實還是編劇有注意到這種小地方，絕對是值得稱許。

而且頻繁並不是最難的部分，每個人都會突然對什麼東西有興趣，這時有大量的熱情就能頻繁的更新，但是最難的是要持續這樣的熱情持續頻繁更新，所以電影裡也有說到這部分，梅格萊恩一開始也很沒信心，說自己老是半途而廢，說的不只是他，也是所有人。所以也許我們也要學學電影裡，給自己期限，給自己壓力。

附帶一提，電影裡的blog用的也是blogspot，notebook用vaio，片中有不少置入性行銷，不過這在近年的好萊屋己經不算什麼了。

原來git可以直接從subversion check out/commit

之前玩了一下下git後，一直沒用就停下了。本來還想查一下mantis對git的支援如何，但是發現不如想像中的多，一開始還有點納悶。後來又繼續讀document發現，git可以直接對subversion裡的repository check out及commit，但是在使用上有些小地方要注意，畢竟這是兩種不同基本思維的工具。

在這樣的支援下，我就可以直接使用subversion當集中式的VCS，讓各個RD使用git在local盡情的使用branch做測試，在溝通時，以subversion為標準溝通版本，己有的issue tracer像mantis,bugzilla之類的，就以subversion的版本發ticket，ticket的討論和fix也以subversion為標準版本，十分一致也能維持原有的使用習慣。
RD之間也可以使用git互相同步，再加上個人覺得git最萬惡的功能-修改己commit的log，可以讓你刪除某些commit log-RD就可以只將他想留下的change log再commit回subversion。當然進了subversion就不能再動了。

其實這樣的使用方式就像是svk。或者應該說做用svk應該合適。svk本身就是類似這樣的使用方式，不過我還沒實際使用過svk。額外一提的是svk是使用perl寫的，perl的CPAN在windows下對我來說一直都不是很好使用，雖然CPAN真的很強大。

"珍愛杜普蕾"意外入手

今天到光南去逛逛，本來沒打算要買什麼東西，但是又不小心看到cd "珍愛杜普蕾"。上一次在二手cd店看到另一個杜普蕾的英國版大部頭因為太貴買不下手，這次可是低價版，很不小心就結了帳帶回家。:D 雖說如此，但是迷之音老是告訴我，那個英國版應該也會是我的。XD

這個"珍愛杜普蕾"看他的錄音版本好像也是很經典版本，但是這麼低價的版本，我想不應該太期待錄音品質，但是絕不影響音樂性就是了。在博客來上，大部分的杜普蕾的cd都買不到了，之前的大特價好像有看到一次，但是來不及搶到，這算是少數還買的到的幾片杜普蕾錄音之一吧。

話說回頭，加上上次為了要湊運費所買的另一片馬友友的essential，最近好像買太多cello的cd了。

Irish whistle 到手

最近發現Irish whistle (或叫tin whistle 臺灣翻成錫口笛)這種愛爾蘭傳統樂器好像很好玩又簡單易學。最重要的是他的入門級價格非常的便宜，馬上從網路上買回來玩。 本來想從國外買，後來發現網路上有人賣的價格還滿合理的就在國內買。

就是被The Corrs這段吸引到的

這段可以讓我練小提琴還有Irish whistle真是太有趣了，不過這沒辦法自己同時玩，要再騙一個人來玩Irish whistle。 :)

c macro tip

雖然我不喜歡用c的macro，往往在程式碼的閱讀和除錯上增加很多困難。但不可否認的有時在c裡(單純在c裡，在c++裡你還有其他的選擇) macro還是有使用的必要，可以減少很多不必要的copy/paste 讓程式比較精簡，增加易讀性，增加performance。當然這些優點要付出前述的代價。

C 的 macro at Gea-Suan Lin’s BLOG

這篇提到了三種c marcro的技巧，個人認為對大部分的人來說這三種是最常遇到的技巧。再更深奧的也很少遇到了。使用c的人都應該要懂，你不寫macro總也要會看得懂別人寫的macro吧。

git初步心得

最近了點時間一邊讀doc一邊操作終於比較了解git一點了。git這種分散式的版本控制系統果然是為社群開發方式的研發出來了。使用方式和邏輯很適合社群的開發模式。不過還真的不怎麼容易學。我自信對傳統集中式的版本控制己相當了解，也使用好多年，但還讀git的manual時還是常有一頭霧水的感覺。也許和我一直想用subversion而增加自己的困擾有關吧。

比較了解git一點後，覺得git比較像是版本的管理而不是版本的控制。當然這也是git對分散式版本控制系統的看法，應該是"檔案工具"而不是"控制工具"。所以要你手動作pack object、連提交過的版本都可以從歷史記錄裡抹除。-_-|||。這在社群使用上沒問題，但是公司團隊裡可能就會不一定合適了。當然這對git來說並不是無解。可以另外由一個管理者保有一份類似"權威版"的的方式來模擬像subversion這種集中式的管理方式。

不過git鼓勵多使用branch和merge的方式倒是滿好用的。當local branch不會影響任何人時，開發者更能盡情的做各種實驗，這當然也是受社群開發方式的影響，這種開發心態在一般的公司團隊裡也很有幫助。

就目前的試用心得來說覺得git有兩個部分還是不太習慣。

第一是使用hash當版本號碼讓版本號碼非常長，大部分的狀況下我都不看版本號碼而看commit log。也因為這樣的版本號碼不容易一眼就看出版本之間的前後關係。在一個開發速定穩定的團隊裡我甚至可以從號碼的差距猜出大約的時間差距。有時間一眼就看出前後關係還是很方便的。

另一個問題是和bug tracing system或ticket system的配合。因為大部分的bug tracing system都還是集中式的要和分散式的version control合作還是有些問題。我還沒試過，我想可能會有一些solution。但應該都還不完美。至少我看到我最愛的mantis好像有一些git的hooking，試過之後再說。

把putty+screenc換成mrxvt

今天把平常工作用的putty+screen給換成mrxvt了。雖然用putty+screen可以補足putty不支援tab的小缺點，但是在兩個地方我還是不滿意，一個是tab的切換上還是有一點不方便，一個是要把scroll回頭拉看之前的message時也有一點點不方便。雖說這兩個缺點在我把screen用到變無意識操作下，影響小了很多。但還是終究還是有點不方法，有時就會要想要再找找有什麼solution。

支援ssh的windows  免費client總體來說還是putty最完整好用(設定介面例外)，所以就改找x windows上的terminal。平常看了一堆lightweight的terminal軟體，但是大部分都架構在gnome的vte上，這對我來說就等於無法用，因為我用的還是Redhat AS3的版本，公司的server當然也不能讓我亂升級。如果要我為一個lightweight的軟體，build一個不同的版本的vte那也太本末倒置了。所以就一直用著putty+screen，當所有的操作變成成下意識動作時，將就著用也就不那麼難過了。(還有一點是我稍微改了一下設定讓我少按幾次ctrl,使用screen的預設meta key總讓我手指受不了)

今天又回頭去看到了mrxvt，突然發現，mrxvt就很符合我的需要，我最需要就是要tab功能，支援256色和自訂字型，至於多國語系和unicode在我coding的過程中是不需要的。而且mrxvt承自rxvt，非常的輕量，只要 x11 library就好了。這一切的一切都是最適合我的嘛。以前怎麼都沒注意到呢。

把mrxvt設定好之後更確定mrxvt對現在的我來說是最適合的，不到2MB的空間滿足了我對tab,256色和字型的要求，和vim配合使用又沒什麼問題。所以就從putty+screen轉到mrxvt啦。

好用的putty我當然不會就這樣拋棄你啦，不過我想我和mrxvt在一起的時間會多很多很多了。

話說回頭, putty+screen在我現在環境還是有一點優勢，最大的優勢就是設定字型方便多了。在工作站上我沒辦法更改任何設定，也不能加自己想用的字型。在windows上不是admin我也能加字型，設定給putty用。為什麼我這麼想用自己的字型呢？好的coding字型對你的眼睛和腦袋都有很大的幫助。但是公司的exceed版本太舊，使用truetype後的refresh就很慢，看著畫面一個字一個字慢慢refresh才能再key in，那我就不需要tab了嘛。幸好我還能接受Fixed字型，就將就用吧。還有screen有他自己強大的功能，其實還是很有用的。

不過用了好久的putty+screen，一堆指令都變下意識動作，換成mrxvt後一下改不過來，頭腦還沒反應過來就發現手指己經打完，畫面出現一堆字。特別是在tab的切換功能還真不習慣。

另外rxvt的另外一個分支rxvt-unicode也可以有簡單的tab支援，不過真的是很簡單，最大的問題是不能用alt+number快速切換tab，在網路上有看到有patch不過我沒試用就是了。但是因為他支援unicode可能對一般使用來說還是比較方便。

PS.最後在設定的時候才不小心發現了screen也可以設hotkey，使用alt-1快速切換tab，那這樣tab切換就跟一般支援tab的terminal沒兩樣了嘛。但是卷軸的部分還是mrxvt比較方便一點點，所以我還是改用mrxvt了

What pity!! I can't use termit in my job

I found a good and lite terminal software called termit today. It seems good and support the all features I want ex: small size, tab support, and 256 colors. It need cmake and libvte and I found it does be small after download source code.

At first, I think I can compile in my local dir. cmake is quite simple to compile in my local dir and the linux server have libvte too. Then I found the libvte in AS3 is too old to termit and I though I can compile a static libvte for termit too. That's should not be a problem.

Then I check the depency of libvte from web. I must be crazy to compile a different version libvte and gtk+ in a machine which I am just a normal user. It's not only libvte too old but also all gtk+ library. I want a lite terminal tool and rebuild a gtk+ library. So I give up. Maybe another ssh client in windows is more suitable for me. It's so pity.

ssh tunnel

SSH support tunnel in three type:
1.dymanic
2.forward local port to remote address
3.forward remoteport to localhost address

1.dymanic tunnel just like kind of socket proxy.


一開始覺得2和3好像就是把話反過來說，有什麼不一樣，看了好一下子才懂不同之處。那是因為我一直以port mapping的想法去看他，你map給我跟我map給你最後還不是一樣通。不過真的了解之後，那還真的就是不一樣。

forward local port to remote address
=>簡單的想法是把你local的某一個port的request forward到另一個address (不必然是 ssh server,可能是任一台 ssh server能連上的address)，所以你在ssh client上連到client的local port就會像是連到remote address一樣。
=>將本機上的某個 port 透過ssh server 對應到遠端主機所在的某個 port
data follow:
ssh client -> internet -> ssh server -> firewall -> ap server
The request to ssh client will forward to ap server through ssh server
Scenario:
You have a server in internet and you want a secured connection. You can open a tunnel to ssh server and all client in your side can access ap server through ssh client. The other benefit is only the ssh client need permission to access internet. But socket proxy will be better solution for permission control.

forward remote port to local address
=>將 SSH Server 上的某個 port 對應到本地主機上的某個 port
所以ssh server端(以及其他能連到ssh server)的人可以利用連到ssh server的某個port，連到client本地主機的某個port。
data follow:

ssh server -> internet -> nat -> ssh client
Use forward remote port to open a ssh tunnel from ssh client to ssh server. There will a listen port in ssh server to forward all request to ssh server specified port to ssh client. All machine in ssh server side can connect to ssh client through ssh server specified port.

Scenario:
You have ssh sever and you can controll it. The user in client is unable to configure network (or server or nat or dymanic ip). You can request client open a ssh connect to server with forward remote port to local address mode. Then you can send request to client intranet by tunnel.