用 goto 語句 算循環(huán)嗎？
或者，直接用匯編Jmp 算 循環(huán)嗎？

xxx.h
#define Printf1 printf("Hello World")
#define Printf2 Printf1;Printf1;
#define Printf3 Printf2;Printf1;
#define Printf4 Printf3;Printf1;
......

#define Printf( N ) Printf ## N

硬編碼 行不。。
Printf(n);

偶也去年也 在做 Windows CE 方面的 開發(fā)，每次都想用個 獨立的 LOG模塊，發(fā)現(xiàn)單純移植還是有很多麻煩的。比如 到后期你發(fā)現(xiàn)效率或什么不如意的，想 修正太難（可能由于原作者制作庫的 時候，有些在WIN平臺可以忽略的問題，在嵌入式上卻必須首要考慮）。
我也想嘗試自己寫個能夠很好移植到各個版本的嵌入式LOG模塊（只寫了個開頭），但嵌入式方面的經(jīng)驗太少，沒有辦法做整體方面的設(shè)計。
關(guān)于STLport，不知道能不能移植到各大主流的嵌入式系統(tǒng)中去，我想應(yīng)該沒多大問題。所以我認為 LOG模塊 是 建立 在 C、C++、STL、簡單模板（？）基礎(chǔ)上，核心使用C++，外包C或其他語言接口。
我的那個簡單的LOG模塊是參照wxWidgets,OGRE,Log4cpp,Gdal等，做的一個嘗試。
如果有興趣，我覺得還是參照已有的東西，新設(shè)計一份比較好。畢竟，嵌入式方面還是比較新的方向，已有的設(shè)計沒法照顧到這些的。
過會我會把我寫的一些東東發(fā)布到我的主頁里面。（很零碎，沒有實用價值，僅參考）
http://m.shnenglu.com/Files/63956372/zyzx.rar

呵呵，，樓上 正解。。

看這么多的經(jīng)歷，有種崩潰的感覺。。

嗯，，稍微有點感覺。。
以前碰到過類似的問題，，在多繼承做指針轉(zhuǎn)換時，有可能出我們的意料。。還有就是在非x86指令集機器上編程，有可能會因為字節(jié)對齊方式使得原C風(fēng)格指針轉(zhuǎn)換出現(xiàn)問題。。

對于事件或消息處理部分看得不是很明白。
樓上的，在不同處理音頻文件播放上正解。使用“責(zé)任鏈模式”，可以使你的設(shè)計在業(yè)務(wù)邏輯中間層不必考慮不同文件格式（MP3,MIDI,WAV等）帶來的影響。
針對不同文件格式，提供與之對應(yīng)的Handler（樓上的IPlayerCreator ），如果參照Com原理與Plugin思想，會使程序更靈活。
開源的音頻處理軟件audacity（http://audacity.sourceforge.net/），在不同音頻格式的讀取播放和插件方面寫的不錯，可以參考。
audacity的GUI部分是使用開源庫wxWidgets（http://www.wxwidgets.org/）寫的。