Programming

這是從Kenneth學來的撇步，不知道這個好工具真是太弱了..XD 這個東西基本上就是幫你把C++ manged name給demangle，讓你知道一些link error時的訊息到底出在哪個member functions的工具。直接看examples:

$> c++filt insertValue__7AverageFd
Average::insertValue(double)

$> c++filt _ZN5trend8clooster8antelop37nebular18DataProcessorQueueIPNS_3spn3wrs9AkamaiLogEbE8pushBackEPNS2_13DataProcessorIS7_bEE
trend::clooster::antelop3::nebular::DataProcessorQueue::pushBack(trend::clooster::antelop3::nebular::DataProcessor*)

這不是清楚多了嘛..XD

今天因為project需要，Alex好心的cmake簡易教學，第一次真正接觸CMake，從此只有一個感想：哇靠！我絕對不會想回去寫Makefile或搞什麼autotools了阿！這才叫build automation嘛！於是花了一個下午把Alex給我的example好好研究，大致弄懂cmake怎麼用，然後把我們的project用cmake建立起來，哇，用CMake好爽好輕鬆！最佳入門參考，可以參見jserv學長的[貓也會的CMake]投影片，生動有趣，簡單明瞭。說真的，學長的引言真是讚，不要當個autofool啦，與其花時間在coding，別讓時間都花在寫makefile..XD (<--在說我自己以前)

其中，source tree和binary tree的概念，把source dir和binary dir分開，實在是非常棒的，cmake完全不會用.o/.so/.a和executables來污染source tree。source tree就該只是source tree，多了幾個CMakeLists.txt而已。

Anyway..C stands for Cross-platform，無論是Linux/Unix/Mac/Windows還有Embeded..都非常方便使用..雖然我的世界除了第一者，其他都幾年沒碰過啦。Cmake的介紹不多說，除了jserv的投影片，就是google吧。很容易學的。給個helloworld.c的CMakeLists.txt感覺一下：

PROJECT(helloworld)
SET(hello_SRCS hello.c)
ADD_EXECUTABLE(hello ${hello_SRCS})

而build的方式，就是cd到某空目錄當作binary tree dir，然後cmake [CMakeLists.txt所在目錄]; make即可。

最後，我覺得最爽的就是cmake後make，都會有彩色的字跑出來寫[XX%]Building...XXX... 這也是重點之一，非常清楚好看..XD 比看一對落落長的compiling command舒服太多~ 感謝Alex的教學。

日前在癮科技看見一篇文章，提到一個有趣的flash遊戲：GeoSketch。他的運作原理很簡單：

• 三根棍子。第1根棍子的中心點固定，三根棍子頭尾相連，不會分開。
• 每根棍子各自有自己旋轉的速率。譬如第1根每次逆時針轉4度，第2根每次逆時針轉21度，第3根則順時針33度。
• 用第三根棍子的尾端畫圖吧！

畫出的圖非常迷人，讓我想起來小時候玩過的一種很大片的尺，裏面有幾個邊緣有鋸齒的圓形空洞，可以塞一個小齒輪進去，鉛筆抵住用小齒輪繞著那個洞，然後就會畫出來奇形怪狀很漂亮的圖形。這個遊戲就是這個道理，不過以前玩的這種“萬花筒尺”感覺像是兩根棍子轉就可以達成，這個遊戲用3根，畫出來更迷人更漂亮！隨便給著數字，畫出來就是完全不一樣的感覺。

看到這篇文章，把這個flash玩了不知道多久，於是想起，阿對了，來開始練習寫Android好了！就用這個簡單又有趣的遊戲當作練習吧！哈，就這樣，前天晚上下班後，花了一個晚上的時間看了Android SDK有關2D graphics的部份，使用SurfaceView把他實作出來。昨天晚上又拿出來，改成可以隨意設定要有幾根棍子一起轉來轉去，不過後來發現3應該是比較有趣的選擇，4或5畫出來的圖形幾乎就常常就會像是幼稚園小朋友拿筆亂塗的樣子了。

ps.這遊戲還真好玩，有沒有正式的數學model或名稱呢？每天還是開出Android emulator玩不同的參數設定：P

I never use Hungarian notation. I hate the ugly look a variable name will become with the use of Hungarian notation. Sigh... I can’t simply bypass them. My implementation should conform to previous works.

How could one enjoy using this type of naming convention? Nevertheless, I should learn to accept this notation...

likely() and unlikely() macros use __builtin_expect() to optimize branches with high probabilities.

In GCC manual:

long __builtin_expect (long exp, long c) [Built-in Function]
You may use __builtin_expect to provide the compiler with branch prediction information. In general, you should prefer to use actual profile feedback for this (‘-fprofile-arcs’), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect. The return value is the value of exp, which should be an integral expression. The value of c must be a compile-time constant. The semantics of the built-in are that it is expected that exp == c. For example:
if (__builtin_expect (x, 0))
    foo ();
would indicate that we do not expect to call foo, since we expect x to be zero. Since you are limited to integral expressions for exp, you should use constructions such as
if (__builtin_expect (ptr != NULL, 1))
    error ();
when testing pointer or floating-point values.

=====

With use of __builtin_expect(), we define:

#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)

NOTE:  __builtin_expect(!!expr, 0) -- > ‘!!’ acts as booleanizers (to ensure x is either 1 or 0)

References:
http://bytes.com/groups/c/217942-replacing-builtin_expect-normal-code
http://stenlyho.blogspot.com/2007/05/likelyunlikelygccbuiltinexpect.html