For doing task management well, I found that vertex42 does make a good Excel gantt chart template. However, I can not modify that template due to I don't know the unprotect password. Hence, I make a similar one, and add some features useful to me. My simple Excel gantt chart template can be downloaded from Here.
Wei
X 工
大陸習慣簡稱工程師為 X 工, 比方說 "陳工程師" 就叫 "陳工".
一日, 我旁邊的同事打電話給客戶...
"喂, 請問是蔣工嗎"
一日, 我旁邊的同事打電話給客戶...
"喂, 請問是蔣工嗎"
昨天公司樓下的便利商店舉辦杜老爺冰棒買一送一特惠活動
我就買了兩根卡布奇諾口味的, 結果晚上就失眠了...!@#$%
"Shared library" + "C++" + "static" is evil
Shared library 在 Microsoft windows 上通常是以 .dll 作為檔名結尾,而在 UNIX like 系統上則是以 .so 作為結束。為什麼會有這麼大的差異呢?這是因為 shared library 並沒有一個跨 OS 的 standard 可以遵循,所以在撰寫 C/C++ 程式時就會碰到很多麻煩。
基本上,只要使用到 shared library,這個程式就不 portable 了。所有用來處理 shared library 的機制都不 portable。 Windows 有他自己的一套,UNIX 有它自己的另一套。當 C++ 程式裡面使用到 static 時更是嚴重,如果再加上 template 的話,那基本上就很難去切割的很模組化了。
舉例來說,下面是 dll 的 .h 檔:

再來看 exe 的 .c 檔:

為求完整,附上 dll 的 .c 檔:

這樣子經過 Visual C++ 2008 express edition 編譯後,執行時會發現在 .exe 跟 .dll 內部都會存在一份 static member 的 memory space。所以執行後的結果會得到 .exe 跟 .dll 看到的是不一樣的值:

這是因為在 Visual C++ 中的 default 設定是 .exe 或 .dll 內的 symbol 都不會被 export 出去,如果沒有特別設定的話,都預設是專屬於該 .exe 或 .dll 內部的,也就是說外面是看不到的。所以如果外面也要能夠存取到的話,那麼 Visual C++ 提供一個 keyword,也就是 __declspec(dllimport) 跟 __declspec(dllexport),可以做到這件事情。透過這兩個 keyword 的使用,就可以讓 .exe 檔也能存取 .dll 內的 static member,而不會產生不一致的現象了。所以新的 .dll 的 .h 檔會像是如下所示:


我在 mingw gcc 4.2.3 上做試驗,也得到一樣的結果,一定要加上 __declspec(dllimport) 以及 __declspec(dllexport) 這樣的關鍵字才有用。
<不負責猜想> 我沒有在 linux 版上的 gcc 做試驗,不過我記得 gcc 的 default 行為是 export module 內所有的 symbol,所以我想 linux 版的 gcc 應該是不用加任何 keyword 就應該是 .exe 跟 .so 都只會看到同一份 static member data 才對。不負責猜想>
基本上,只要使用到 shared library,這個程式就不 portable 了。所有用來處理 shared library 的機制都不 portable。 Windows 有他自己的一套,UNIX 有它自己的另一套。當 C++ 程式裡面使用到 static 時更是嚴重,如果再加上 template 的話,那基本上就很難去切割的很模組化了。
舉例來說,下面是 dll 的 .h 檔:
再來看 exe 的 .c 檔:
為求完整,附上 dll 的 .c 檔:
這樣子經過 Visual C++ 2008 express edition 編譯後,執行時會發現在 .exe 跟 .dll 內部都會存在一份 static member 的 memory space。所以執行後的結果會得到 .exe 跟 .dll 看到的是不一樣的值:
這是因為在 Visual C++ 中的 default 設定是 .exe 或 .dll 內的 symbol 都不會被 export 出去,如果沒有特別設定的話,都預設是專屬於該 .exe 或 .dll 內部的,也就是說外面是看不到的。所以如果外面也要能夠存取到的話,那麼 Visual C++ 提供一個 keyword,也就是 __declspec(dllimport) 跟 __declspec(dllexport),可以做到這件事情。透過這兩個 keyword 的使用,就可以讓 .exe 檔也能存取 .dll 內的 static member,而不會產生不一致的現象了。所以新的 .dll 的 .h 檔會像是如下所示:
我在 mingw gcc 4.2.3 上做試驗,也得到一樣的結果,一定要加上 __declspec(dllimport) 以及 __declspec(dllexport) 這樣的關鍵字才有用。
<不負責猜想> 我沒有在 linux 版上的 gcc 做試驗,不過我記得 gcc 的 default 行為是 export module 內所有的 symbol,所以我想 linux 版的 gcc 應該是不用加任何 keyword 就應該是 .exe 跟 .so 都只會看到同一份 static member data 才對。不負責猜想>
什麼時候晚上用時速 40 公里的龜速開沒路燈的蘇花高還會緊張個半死?
就是當自己是第一台車,而後面跟著一屁股車的時候。。。
Open source 的 scene graph library 的選擇
3D scene graph 在很多地方都見得到,例如 Java 的 JSR-184 (a.k.a m3g),3D studio max 裡面也有自己的一套 (要用 3dsmax sdk 或更高一層的 3DXI 才存取得到)。談到 open source 的 3D scene graph library,常見到的幾乎就是下列三套:
其中的 Coin3D 是 GPL license,所以如果你的 project 不是 GPL license, 那麼就不用考慮他了。OpenSG 採用的是 LGPL,而 Open Scene Graph 採用的也是類似 LGPL,但卻是更寬鬆的 license,他容許 static linking 以及直接 embedded 到 application 中。所以就 license 而言,Open Scene Graph 是最有彈性的。
另外就使用者及社群的活躍性而言,以這個網頁的資料來看,Open Scene Graph 不論是在使用者以及社群活躍度上,都比另外兩個 project 來的蓬勃。OpenSG 次之,Coin3D 敬陪末座。
在架構上,Open Scene Graph 跟 OpenSG 類似,都是採用 Application-driven 的方式,也就是在 application 的執行期間內,會一直不斷的進行 render 的動作,所以適合用在遊戲以及模擬類的程式中 (比方說飛行模擬)。而 Coin3D 只會在 scene 的內容有變的時候,才會 render,比方說 view point 改變等等。
Coin3D 是基於 SGI 的 OpenInventor 這套 API 而來,所以他跟 OpenInventor 是 API 相容的。雖然他跟 SGI 的 OpenInventor 相容,但也加入了不少自己的一些 extension。而且 SGI OpenInventor 上次的 source release 是在 2003 年,跟一直在進行更新的 Coin3D 相比,似乎活躍度差了那麼一點。
另外,就網路上查到的資料,同樣的一個 3D scene,用這三套 library 來撰寫,結果似乎以 OpenSG 撰寫所得到的 performance 最好,Open Scene Graph 次之,Coin3D 最末。
所以看來要選一套 open source 的 scene graph library 來用的話,不外乎就是挑 OpenSG 或 Open Scene Graph 了。雖然 OpenSG 似乎有個比較好的 performance 表現,但以社群的活躍度以及所得或的支援來說,Open Scene Graph 看來是 open source scene graph 中最好的選擇了。
其中的 Coin3D 是 GPL license,所以如果你的 project 不是 GPL license, 那麼就不用考慮他了。OpenSG 採用的是 LGPL,而 Open Scene Graph 採用的也是類似 LGPL,但卻是更寬鬆的 license,他容許 static linking 以及直接 embedded 到 application 中。所以就 license 而言,Open Scene Graph 是最有彈性的。
另外就使用者及社群的活躍性而言,以這個網頁的資料來看,Open Scene Graph 不論是在使用者以及社群活躍度上,都比另外兩個 project 來的蓬勃。OpenSG 次之,Coin3D 敬陪末座。
在架構上,Open Scene Graph 跟 OpenSG 類似,都是採用 Application-driven 的方式,也就是在 application 的執行期間內,會一直不斷的進行 render 的動作,所以適合用在遊戲以及模擬類的程式中 (比方說飛行模擬)。而 Coin3D 只會在 scene 的內容有變的時候,才會 render,比方說 view point 改變等等。
Coin3D 是基於 SGI 的 OpenInventor 這套 API 而來,所以他跟 OpenInventor 是 API 相容的。雖然他跟 SGI 的 OpenInventor 相容,但也加入了不少自己的一些 extension。而且 SGI OpenInventor 上次的 source release 是在 2003 年,跟一直在進行更新的 Coin3D 相比,似乎活躍度差了那麼一點。
另外,就網路上查到的資料,同樣的一個 3D scene,用這三套 library 來撰寫,結果似乎以 OpenSG 撰寫所得到的 performance 最好,Open Scene Graph 次之,Coin3D 最末。
所以看來要選一套 open source 的 scene graph library 來用的話,不外乎就是挑 OpenSG 或 Open Scene Graph 了。雖然 OpenSG 似乎有個比較好的 performance 表現,但以社群的活躍度以及所得或的支援來說,Open Scene Graph 看來是 open source scene graph 中最好的選擇了。
RD有兩種
RD 有兩種,一種是 Research & Design,另一種是 Revise & Debug...
苦命工程師
有人說我這種好與人為善的彌勒佛個性,不適合當主管。
...
看來我天生就是苦命工程師唉。
...
看來我天生就是苦命工程師唉。
添購新的沐浴乳卻沒有仔細看標籤的後果
就是在強烈冷氣團來襲的晚上, 用清爽的薄荷口味沐浴乳讓自己稍微動一下就 "涼"~ 到不行...
平常太貪吃的後果
對於同事一看到有新的餅乾口味就馬上來通知我的心態覺得有深入研究的必要性
過敏源
從小我就對灰塵還有冷空氣過敏
雖然長大了好很多
但爾偶還是會這麼來個折磨一下
今天晚上吃晚餐的時候
大概是為了邊吃飯, 邊跟同事聊天
所以不小心把飯吃到鼻子裡去
沒想到晚上就開始過敏了
邊加班邊過敏的感覺, 怎個讚字了得
好不容易撐到事情做的差不多
回家洗個熱水澡就好多了
所以我的過敏源除了灰塵跟冷空氣
還有今天晚餐的... 一粒米
什麼叫做質疑的眼神
就是當我晚上 10:30 看到同事正在吃大碗公泡麵而跟他說這樣會變胖的時候, 他看著我嘴巴裏面塞了滿滿滿~餅乾時的眼神...
Subscribe to:
Posts (Atom)
