[C++] virtual destructor

C++ 在設計 class 時，virtual destructor 會是個在設計時必須要謹慎考量的點 (特別是在 class 會被繼承以及有 dynamic binding 的狀況時)， stack overflow 上或者 google "virtual destructor" 其實都可以找到相當多的文章說明為何需要 virtual destructor。不過其實大多數的文章會把重點放在 memory leak 上的問題，今天才發現原來這是 undefined behavior

標準上有這麼一句話

In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

換言之雖然確實是有問題，但如果是 undefined behavior 的話，我個人會認為要假設程式在此時不能正常運作，是個必須嚴格避免的狀況。

[遊記] 臺東三日遊 - 大武觀海步道、三仙臺、知本森林遊樂區、臺東海濱公園、初鹿牧場

這次趁著 5/1 勞動節的連假，跟朋友約了一起出遊
起因也很簡單，純粹是清明連假沒出去玩朋友覺得悶，所以提議了趁著勞動節連假出去散心這樣 XD

這次出遊的地點最後決定去我們兩個都很少去、也比較麻煩的臺東
比較麻煩的原因來自於交通：
臺東的位置不論何種交通工具都很花時間，所以不趁著連假去的話會有大半的時間都花在交通上

基於這段時間我們兩個都很忙，沒辦法仔細的規畫行程，所以最後去的景點都是些比較常見的點
以下是我們這次的行程：

第一天：
8:00 高雄出發 -> 枋寮 7-11 山海關門市休息 -> 臺 9 線南迴 -> 大武觀海步道 (休息兼散步) -> 臺東市區 (中餐兼休息) -> 三仙臺 -> 臺東市區晚餐

第二天：
9:00 臺東市區出發 -> 知本森林遊樂區 (約 30 分鐘車程) -> 臺東海濱公園 ->晚餐

第三天：
10:00 民宿出發 -> 初鹿牧場 (約 30 分鐘車程) -> 高雄

第一天其實大多數時間都在開車 XD
三仙臺是我個人想去的點，所以當時就請朋友讓我安排這個距離其他景點都有點遠的地方
三仙臺位在成功鎮，從臺東市區過去的話車程約 1 小時
所以第一天朋友開了大約有 5 ~ 6 小時的車，中途雖然每隔一小時就會找個點休息一下
不過這樣開還是挺傷神的就是了

 大武觀海步道

 簡單來說就是一個在臺 9 線附近的制高點，由鄉公所 (還是林務局有點忘了) 開闢出來的一個只有長約一公里的步道
步道頂點有觀景亭可以眺望太平洋，入口附近是林務局的工作站，所以也可以在那邊稍作休息
這次會到這邊一來是這邊在剛出南迴不遠處，是個可以暫時停歇的地方
興致來了也可以走一小段步道看看風景轉換一下心情
是個不錯的小景點
不過這次我們只有在林務局工作站前面的停車常稍微休息散步，沒有上去走步道就是 XD

三仙臺

而我個人最想去的三仙臺呢，主要就是這個拉

這個八拱橋連接到對面的那做小島，小島本身是珊瑚礁地形
從找到的一些資料來看，以前好像有相連過，後來被沖刷斷掉後才變成小島
現在只靠著這個八拱橋連接
個人想到三仙臺是因為這邊是少數我很喜歡的海景
可惜這次天氣不佳，有陽光的話整體景色會很有活力、也很亮眼
而且因為我們這次是下午去的，所以本來期望可以看到一些不錯的雲彩 XD
可惜老天不賞臉

小島因為是珊瑚礁地形，除了鋪設的水泥路外，靠近海邊的路都不是很好走
不過島的另一邊有個燈塔，可以上到燈塔處看海景

當時跟朋友在走這一段時發現其實有不少人特地跑到這邊來釣魚
不過這邊如果漲潮或是有海浪之類的其實滿危險的就是了
但是風景不錯，值得走一趟
這邊完整的走一圈大約 2 小時，小客車的停車費是 $60 (沒有門票)
環境也都有在維護，可惜人多了點，特別是海灘附近

知本森林遊樂區

這邊就是一些森林步道 XD
我們這次的走法就是直接每個步道走一遍，剛好繞一圈迴遊客中心

不過這次因為好漢坡步道在維修，所以森林浴步道有一段沒有走
維修的地方是遊客中心到十字路口那段
所以我們最後的路線是
森林浴步道 -> 十字路口 -> 榕蔭步道 -> 景觀步道
值得注意的話這次榕蔭步道上的觀海亭也在施工中

森林浴步道就真的像是一般登山健行會走的路

不過可能之前有大雨、地震之類的，這次路上可以看到有許多的落石
施工中的步道也大多是這個原因在維修中

從十字路口往回看好漢坡步道

 

好漢坡步道約有 300 公尺，平常沒在運動的人應該會覺得很吃力 XD
另外瀑布那段也被擋住了過不去，估計都需要等到施工完畢才能靠進吧

基於朋友喜歡悠哉的行程，這次我們在這邊待了約 5 小時
(9:30 左右到知本森林遊樂區，約 15:00 左右離開)
包含中午吃飯時間，所以其實走得滿悠哉的，邊走邊聊天
不過大概是夏天快到了，蟬叫聲超級吵
聊著聊著就調到了這些蟬到底是用 TCP 還是 UDP 在傳輸訊息
↑ 兩個阿宅在發神經

這邊如果走快一點的話其實大約 2 ~ 3 小時就走的完了
不過因為園區內沒有食物，所以這次我們是買麥當當帶進去吃 XD
出園區後因為知本市區就在附近，所以用餐到是很方便

知本森林遊樂區附近沒有停車場，所以要自己找個路邊的空位停
門票的畫則是全票 $100，優惠票 (軍警、學生 ...) 是 $50

臺東海濱公園 + 臺東森林公園

這 2 個點某種程度上就是大安森林公園這一類的地區
算是當地居民休閒散步的地區，不過佔地非常大
因為遊客也非常多，所以附近有很多腳踏車的出租店
我們這次去有看到大約 5 ~ 6 臺的遊覽車
另外還有不少自行出車前來的散客
所以其實人潮非常多，不過因為我跟朋友都不喜歡人多的地方
雖然是個很適合租臺腳踏車閒逛的點，但最後我們小走一圈後就離開了
不過有看到一個很神奇的國際地標

其實我不懂為何是國際地標就是 XD

本來因為這邊相當大，預計可以逛個幾小時，最後因為人多，大約一小時不到我們就離開了
結果就是我們提早吃了晚餐，晚上沒事做就開車亂繞
然後就跑去逛了大潤發 XDD
朋友因為車子的雨刷清潔劑用完了，就到大潤發買了一小罐回去民宿自己處理
然後還因為兩個人都沒開過汽車引擎蓋，看了說明書後好不容易打開了
結果處理完畢後確發現怎樣都蓋不回去 XDDD
後來朋友打電話回去求救後才知道我們兩個都太秀氣
引擎蓋要很大力的蓋上去，但我們兩個只有輕輕的蓋回去，所以才會怎樣都蓋不上 XD
最後因為太晚了怕吵到人，我們是到了隔天早上才把引擎蓋恢復原狀
以上是由兩個神經病在第二天引發的小插曲

初鹿牧場

這是我們在 booking.com 上訂完民宿後，booking.com 推薦的景點之一
是臨時起意的，加上這邊雖然能簡單體驗銀之匙的生活，不過逛不了太久
所以安排在第三天

當時朋友看到一大片草皮有想躺上去睡覺的衝動 XD

這片草皮其實是滑草場，不過雖然有設備，附近卻沒有工作人員
估計是不打算繼續營業這個項目了

初鹿牧場包含這次的話我應該來過至少三次了
不過這次跟朋友來是第一次去餵食動物，其實還滿有趣的
雖然馬除了你餵食之外都不會理你
袋鼠是根本就被隔絕
牛大概是被太多人餵，有幾隻好像已經吃飽了
除此之外都還挺有意思的

這次也有發生一個小插曲：
我們因為懶得把整捆牧草拆開，所以就整捆牧草送過去給牛咬
結果沒想到牛的力氣超級大，牛一咬我們就整個人被拉過去撞護欄了 XDD
然後最後就演變成我們在跟牛拔河
是個有趣的初體驗

初鹿牧場的門票平日是 $100，假日是 $180
我們這次雖然是在星期一去的，不過因為是連假最後一天，所以還是算假日
小客車的停車費則是 $50
裡面有景觀餐廳賣一些饅頭、關東煮一類的輕食
想吃其他食物的話就必須出去到市區了

不過這邊要來最好要避開星期六
當時我們在紀念品店有問過店員人潮的問題
他說這次星期六有 4 臺還 5 臺遊覽車到那邊
人潮爆炸多 XD

住宿 

這次住宿的地點我們是在 booking.com 上看到米蟲民宿在特價
住兩晚的雙人套房是 $3400
床是加大的雙人床、有提供 wifi 與飲水機
沒有附早餐 (不過附近有早餐店)
沒有專屬停車位 (不過附近巷子很好停車)
因為在巷子內，所以還滿安靜的，我跟我朋友睡覺時都怕吵
所以對於這點很滿意
另外因為是新裝潢好的民宿，整體來說都很乾淨漂亮

民宿地點位在市區跟火車站中間，交通還算方便
不過如果晚上臨時想出門吃東西的話還是要到市區
所以會建議回民宿前預先買好想要的東西

民宿內有提供許多旅遊簡介，我們在房間內還看到他們推薦的市區食物分佈圖
幫我們解決了用餐地點的困擾 XD
也因此對他們的印象還不錯

結論

雖然臺東能逛的地方還有不少，不過基於交通問題，要怎麼規畫其實還是頗頭痛的
這次也有跟一個做旅遊業的老闆聊到
基本上像花東這些地方他比較建議找當地人做司機兼導遊
一來是他們比較清楚有哪些景點可以走，行程怎麼安排比較順
他們也有一些私人景點可以逛、什麼季節有哪些活動可以參加...等等
我想這是個我之後出遊會考慮的方式之一
不過這種方法需要參加的人夠多，費用分擔起來才會划算
但不失為一個好方法

[隨筆] 研究的實驗結果這回事

最近看了許多跟系統架構相關的文章，讓我想到剛升碩一時不知天高地厚的跑去修了虛擬機器這門課，然後因為各種聽不懂大受打擊的事情 XD 當時這門課的期末專題是要想辦法找出 QEMU 中可以改善的地方，然後做實驗說明改善的結果跟幅度，現在想想當初能順利做完這個專題還拿到高分實在是運氣破表 XD

[筆記] 最佳化演算法 (Optimization Algorithm) 的使用與誤用

(這篇的數學式有用到 javascript 來顯示，請不要檔掉 JS，不然顯示上會很奇怪 XD)

最佳化演算法簡單來說就是個搜尋演算法，這類演算法的再做的事情是給定一個問題，定義合法的解集合 (或是空間，英文是 solution space)，再給一個函數用以判別一個解的好壞 (objective function)，這類最佳化演算法就會在解集合中找出符合要求的一個解。

有點難懂？舉個例子：假設我想要再一個 2D 的平面座標中找到一個點使得 $f(x, y) = (x - 5)^2 + (y + 3)^2$ 得值最小，求 (x, y) 為？在這個例子中，solution space 就是 2D 平面上所有可能的點座標，而 objective function 就是 $f(x, y) = (x - 5)^2 + (y + 3)^2$。而最佳化演算法就是針對 "任何" 這樣的問題，找出一個盡可能滿足 objective function 也合法的解給你。沒錯，就是任何這類需要在一個 solution space 中找解的問題都行。所以這類演算法很萬用，但也因此容易被誤用。

[EDA] Steiner Tree v.s. Spanning Tree

一般演算法講到 greedy method 時都會用 spanning tree (生成樹) 當範例，因為 spanning tree 有 O(n log n) 的 greedy method 可以找到最佳解。相對於 spanning tree，某些情況人們會更偏好 Steiner tree (中文好像是翻成史坦納樹)，兩者雖然都是要找一個方法把給定的點連成一顆樹，並且一般都會要求 cost 要最低，但是一個很大的差別在於 steiner tree 允許連線時增加多餘的點，但 spanning tree 不行。有多餘的點可連差異會很大嗎？我想可以參考 wikipedia 這篇的圖例就會知道這差異有多大。簡單的一個結論是 minimum steiner tree 的 cost 是小於、最多等於 minimum spanning tree。

[隨筆] 簡潔而精準 與 冗長但易懂 都幾?

在 FB 上看到朱家安 (哲學哲學雞蛋糕的作者，最近有上去臺灣吧介紹哲學的那位) 的這篇詢問文時，想到了剛開始寫論文的一些事情，當時也被老闆告誡過跟這篇文章想問的事情有關的原則。

我相信其實不只哲學論文，一般學界的論文都會為了要求精準而簡潔而使用了大量的符號去避免冗餘的文字還有錯誤的解讀，因為自然語言很常出現同樣的一個句子可以有 2 種以上的解讀方式。像那篇文章中的 A1、B1 就用了一些代號去代表一個特定的事件、情境等等的現像。相較於 A2、B2 來說，因為可以大量減少文字中所需要的代名詞，而且因為符號所代表的事情是固定的，因此可以減少讀者在解讀上的困擾。比方說，如果文章的某個段落提到 "該事件"、"此方法" ... 等等之類的用詞時，讀者通常必須要能緊緊的跟住文章的脈絡才能正確的理解這些名詞在指涉哪些內容；相對的，姪皆使用代號的話就沒有這個問題，比方說我上面的 A1、A2 只要有看到原文的都會知道我在指甚麼。

當然，依照情境優點也是會變成缺點的：當今天代號過多時，一般人會難以將大量的代號與其所代表的意義迅速的連結，因此下場就會變成讀者會需要常常翻閱每個代號的意義，反而增添閱讀上的困擾與意願。我想應該沒有人喜歡閱讀文章時還需要常常往回翻每個代號的用意吧？就我自己的想法，適量的使用代號有助於理解文章的內容，當然何謂適量就是另一個問題了。我的看法是當作者自己本身都必須往回翻翻看有多少代號然後哪些是甚麼含義時就是個警訊了。另一個可以著力的點是使用代號時也盡量都使用默認常用的符號，別自創新符號。

備註：

有看到推文有人提到數學式子，但我覺得數學式子跟代號又有一點微妙的不同，因為複雜的數學式子會有理解困難的問題，但代號應該沒有複雜的代號這回事 XD

[閒聊] 人際關係

最近因為發生了點事情，所以比較常跟人聊到人際關係這回事，一個可以簡單可以複雜的問題

[隨筆] 性格

最近覺得要想了解一個人，除了從平時的互動可以略知一二外，最好的方法其實是觀察他的負面情緒

 一個人在身處負面情緒的狀況下因為多少失去理性了 (當然，憂鬱症這種已經屬於精神疾病的不在這邊的討論範圍，我沒那麼厲害)，此時展現出來的就有很高的機率是他的原始面貌。比方說，容易有肢體衝突、容易有語言上的暴力、酸言酸語、孤僻、高傲、自尊心強烈 ... 等等，在人身處負面情緒時很容易展露無疑。當然，也有些人即便身處負面情緒下還是有著關懷、體貼、包容 ... 等等的正面情緒，所以觀察一個人身處負面情緒時會有何反應大概就可以簡單的窺探一個人的本性。

不過，我果然還是不習慣跟刺蝟類型的人相處太深入，因為當這類人身處負面情緒時，張開的刺保護了自己，卻也阻隔了所有試圖 - 不論是好意或惡意 - 靠近的人，而且往往越接近的人被傷的反而是最深的。或許是我自己的偏執，往往很希望可以在別人低潮時試圖陪伴，因為我覺得這或許可以給別人一種安心感，現在覺得這種自做多情的事情還是別幹了，往往自己被弄得滿身傷還不被諒解。

[EDA] Design Challenge in Rouoting Algorithm - 繞線演算法的設計困難處

在 IC 設計中，Routing (中譯：繞線) 的用意就是把需要連接的地方用金屬線連起來，概念很簡單。要判別一個 routing 結果的好與壞也很容易：計算總線長就好。因為總線長越長也就意謂著需要越多的金屬線以及空間，所以如果有許多種不同的 routing 結果，我們會選擇總線長最少的那個當成最後結果。

隨著製程的演進，現在 routing 要考慮的因素越來越多，因此在演算法的設計上也就越趨複雜，而且通常難以有個通盤考量的好結果。這一篇要來簡單的總結現在 routing 上最重要的設計考量 - 繞線資源的規劃與使用 (routing resource estimation & management, 以下簡寫 RREM)

[隨筆] 程式能力該如何檢定?

最近這幾年推廣寫程式的風潮越演越烈，比方說科技界的大老的推廣、人人都該寫程式、甚至也有教授開始推廣國中小的學生開始學習寫程式。究竟為什麼推廣寫程式，我想已經有很多文章在闡述這點了，今天想談的是從這點往下延伸的問題：

究竟如何判斷一個人的程式能力?