Qt5 已易主, 腦殘的事情也干的越來越多.

看qt下載頁的Qt的windows版本默認提供32位和64位, 那個啥opengl版暫時未理會

因為本人系統是win7 64bit, 因此毫無理由的下載了64位的qt5.2版本. 編譯了hello world, 結果報錯:

module machine type 'x64' conflicts with target machine type 'X86'

找了半天沒查到錯誤, 后面注意到vs2012的工程編譯類型選擇的是win32 x86, 才想起是由于qt5的所有lib是64位編譯, 而我使用32位的程序去鏈接, 當然要報錯.

重新下載32位的qt5.2, 編譯正確

另外一個錯誤也是在前面版本極為少見的:

fatal error C1083: Cannot open include file: ’GLES2/gl2.h’: No such file or directory

很多人的解決方法是包含QtANGLE下的gles2目錄, 但是由于我的工程內的cocos2dx本身也帶有這東西. 于是研究了下為啥這版本的qt默認要搞的非要和gles有關系

最終, 發現可以通過定義QT_NO_OPENGL宏來屏蔽opengl的渲染API使用, 編譯通過

很是懷念諾基亞時代的qt, 下載,編譯一氣呵成

cocos2dx引擎使用plist文件, 一種特殊的xml格式作為其atlas紋理的描述文件. plist遵循蘋果的xml中key-value的設計風格.對于OC來說是合適的, 但xml本身性能低下, 垃圾內容過多, 也讓plist對于高性能游戲引擎不再適合. 因此, 研究TexturePacker的導出插件技術

TexturePacker的自定義插件目錄位于其安裝目錄的bin\exporters\下, 但有一些插件屬于內建支持, 例如cocos2dx的plist格式, 因此無法找到對應插件

本人參考shiva3d插件, 對應導出界面的DataFormat中的Shiva3D, 快速學會了如何導出

官方文檔位于http://www.codeandweb.com/texturepacker/documentation/#customization

插件的基本格式及原理是:

bin\exporters\下的某一目錄下存在的一個名為exporter.xml文件作為插件的描述,例如:

<exporter version="1.0">

    <!-- identifier of the exporter -->

    <name>shiva3d</name>

    <!-- display name of the exporter for the combo box -->

    <displayName>Shiva3D</displayName>

    <!-- description of the exporter -->

    <description>Exporter for Shiva3D.</description>

    <!-- exporter version -->

    <version>1.0</version>

    <!-- currently only one file allowed - more to come with update -->

    <files>

        <file>

            <!-- name of this file variable -->

            <name>xml</name>

            <!-- human readable name (for GUI) -->

            <displayName>XML</displayName>

            <!-- file extension for the file -->

            <fileExtension>xml</fileExtension>

            <!-- name of the template file -->

            <template>shiva.xml</template>

        </file>

    </files>

    <!-- target framework supports trimming -->

    <supportsTrimming>false</supportsTrimming>

    <!-- target framework supports rotated sprites -->

    <supportsRotation>true</supportsRotation>

    <!-- rotated sprites direction (cw/ccw) -->

    <rotationDirection>cw</rotationDirection>

    <!-- supports npot sizes -->

    <supportsNPOT>true</supportsNPOT>

    <!-- supports file name stripping (remove .png etc) -->

    <supportsTrimSpriteNames>yes</supportsTrimSpriteNames>

    <!-- supports texure subpath -->

    <supportsTextureSubPath>yes</supportsTextureSubPath>

</exporter>

在Template字段中, 描述同目錄的導出文件格式模板. TexturePacker使用一種叫Grantlee的模板引擎,類似于Python使用的Django模板引擎, 文檔參見:Grantlee Documentation. 簡單的文本格式可以參考shiva.xml快速學會

這里我們使用protobuf的文本格式(極為類似json)導出plist, 下面是導出模板

{% for sprite in allSprites %}

Sprite {

    Name: "{{sprite.trimmedName}}"

    FrameX: {{sprite.frameRect.x}}

    FrameY: {{sprite.frameRect.y}}

    FrameWidth: {{sprite.frameRectWithoutRotation.width}}

    FrameHeight: {{sprite.frameRectWithoutRotation.height}}

    OffsetX: {{sprite.cornerOffset.x}}

    OffsetY: {{sprite.cornerOffset.y}}

    OriginalWidth: {{sprite.untrimmedSize.width}}

    OriginalHeight: {{sprite.untrimmedSize.height}}

    {% if sprite.rotated %}Rotated: true {% endif %}

}

{% endfor %}

導出的結果類似于:

Sprite {

    Name: "car01"

    FrameX: 100

    FrameY: 129

    FrameWidth: 76

    FrameHeight: 47

    OffsetX: 0

    OffsetY: 0

    OriginalWidth: 76

    OriginalHeight: 47

    Rotated: true 

}

Sprite {

    Name: "car02"

    FrameX: 100

    FrameY: 51

    FrameWidth: 76

    FrameHeight: 47

    OffsetX: 0

    OffsetY: 0

    OriginalWidth: 76

    OriginalHeight: 47

    Rotated: true 

}

...

導出插件還支持js擴展, 具體內容請繼續參考官方文檔, 但對于簡單的文本格式, 這種方式已經足夠了

對比plist后, 發現plist中的垃圾信息極為多, 而且作為spriteframe的name居然帶有擴展名...  因此脫離plist,編寫自己的導出插件才是王道!

概述

目前Go編譯器是C寫的，是時候換成Go啦。

背景

“gc"Go工具鏈來自Plan 9編譯器的工具鏈。組裝器、C編譯器和鏈接器基本沒變。Go的編譯器(cmd/gc,cmd/5g,cmd/6g,cmd/8g)是配合工具鏈寫的新的C程序。

項目起始時，用C而不是Go寫編譯器有很多好處。突出的比如，首先，那時候Go還不存在，沒法兒寫編譯器。而且實際上，就算存在，也會經常有明顯的不兼容的變化。用C不用Go可以避免初始和持續開發導致的問題。然而如今Go 1已經穩定，所以這些持續的問題減少了很多。

持續開發的問題已經消除，為了讓Go實現的編譯器比C更有吸引力，另一些工程問題出現：

• 寫正確的Go代碼比寫正確的C代碼更容易。

• 調試錯誤的Go代碼比調試錯誤的C代碼更容易。

• 使用Go編譯器需要對Go有一定理解。而用C編譯器還需要一定理解C。

• Go使并發執行比C更方便。

• Go有更好的標準支持模塊化，自動重寫，單元測試和性能分析。

• Go比C更有趣(fun)。

基于以上理由，我們相信是時候用Go寫Go編譯器啦。

計劃設想

我們打算用自動化翻譯工具來用Go重寫現在C的編譯器。這個翻譯需要一些階段，將從Go 1.3開始持續到未來的發行版。

第一階段。開發和調試一個自動化翻譯工具。這可以在日常開發時同步進行。而且，人們還可以在這個階段為C編譯器繼續改進。這個工具工作量很大，不過我們有信心完成這個特殊使命的工具。有許多C的觀念沒法兒直接轉換成Go；macros(宏)，unions(聯合，共用體,)，bit fields(位域)可能最先考慮。比較幸運（不是巧合），這些功能功能用的少，都會被翻譯掉。指針運算和數組也需要一些轉換工作，盡管編譯器里很少。編譯器里主要是tree(樹)和linked list(鏈表)。翻譯工具會保留注釋和C代碼的結構，所以翻譯后的代碼和當前的編譯器代碼一樣可閱讀。

第二階段。用翻譯工具轉換C代碼到Go，并刪除C源碼。這時我們已經開始翻譯，但是Go還是運行在C編譯器上。非常樂觀的，這可能發生在Go 1.3。不過更可能是Go 1.4。

第三階段。使用一些工具，可能來自gofix和the Go oracle，拆分編譯器到包，清理和文檔化代碼，添加適當的單元測試。這是編譯器會是地道的Go程序。目前打算在Go 1.4實現。

第四a階段。使用標準的分析和測試工具優化編譯器的CPU和內存使用。可能要引入并行。如果真這樣，Race Detector(Go的并行競爭檢測工具,)會有很大幫助。這目標在Go 1.4，可能部分會延后到1.5。基本的優化分析會在第三階段完成。

第四b階段。（和四a幾段同時進行）當編譯器依照明顯的界限分割成包之后，需要明確引入一個中介碼，在結構無關的無序樹(Node_s)和結構相關的有序鏈表(Prog_s)之間。這個中介碼應該不依賴整體架構，但是包含準確的執行順序信息，可以用于有順序但是結構無關的操作的優化，比如清理多余的nil檢測和出界檢測。這些過程基于SSA（靜態單賦值），你可以從Alan Donovan的 go.tools/ssa 包中了解更多。

第五階段。替換go/parser和go/types到最新（全新）的版本。Robert Griesemer參考現在的經驗，討論了設計新的parser和types的可能。如果聯系他們到編譯器后端，相信對設計新的API有很大幫助。

自展（Bootstrapping）用Go語言實現的Go的編譯器，從一開始就要考慮如何自展。我們考慮的規則就是Go1.3編譯器必須由Go1.2編譯，Go1.4的編譯器必須由Go1.4編譯，以此類推。

這時，我們就有了一個清晰的流程來生成當前的程序：編譯Go1.2的工具鏈（由C編寫），然后使用它編譯Go1.3的工具鏈，以此類推。這里需要一個腳本來做這個事情，來保證只會消耗CPU的時間而非某個人的時間。這樣的自展，每個機器只會做一次，Go1.x的工具鏈將會在本地保留，并在執行all.bash來編譯Go1.(x+1)工具鏈的時候被再次使用。

顯然，隨著時間的推移這種自舉方式是不充分的。在后面的多個版本被發布之前，為編譯器寫一個后端來生成C代碼也許是一個更有意義的事情。這些C代碼不要求效率或可讀性，只要正確即可。這些C代碼將會被簽入，就像我們簽入由yacc生成的y.tab.c文件一樣。這樣，自展過程就會變成：先用gcc編譯C代碼生成一個自展編譯器，然后使用這個自展編譯器來編譯真正的編譯器。類似于另一個自展過程，這個自展編譯器將會在本地保留，并在每次執行all.bash的時候重復使用（不用重新編譯）。

替代選擇還有一些比較明顯的替代方案，需要我們說明一下為什么放棄了這些選擇。

從一開始寫一個編譯器。現在的編譯器有一個非常重要的特征：他們能夠正常工作（或者其至少能夠滿足所有用戶的要求）。盡管Go語言比較簡單，但是編譯器中有很多細微的細節優化和改寫，直接丟棄10或數年的在這上面的努力是比較愚蠢的。

對編譯器進行人工翻譯。我們已經以人工的方式翻譯了一小部分C/C++代碼到Go語言了。這個過程是枯燥而且易錯的，且這些錯誤非常的細微及難以發現。相反，使用機械翻譯會形成一些比較一致的錯誤，而這些錯誤是易于發現的；而且不會因為枯燥的過程開小差。Go編譯器的代碼明顯的比我們翻譯的代碼多很多：超過60,000行C代碼，機械翻譯會使這個過程容易一些。就像Dick Sites在1974年說的一樣：“相比寫程序，我寧愿寫一個程序來幫我寫程序。“ 使用機械來翻譯編譯器也方便于在準備好切換之前，我們可以繼續開發完善現有的C程序。

只翻譯后端并鏈接到go/parser和go/types.從前端傳給后端的數據結構所包含的信息中，go/parser和go/types所能提供的除了API就沒其他的東西了。如果使用這些庫來替代前端，需要寫代碼來轉換go/parser和go/types所能提供數據結構到后端，這是一個非常寬泛且易出錯的工作。我們相信使用這些庫是有意義的，但更明智的是，等到將編譯器代碼調整的更像Go程序，分成確定邊界的、包含說明文檔和單元測試子包之后再使用。

放棄現有的編譯器，使用gccgo（或者go/parser + go/types + LLVM, …）。現有的編譯器是Go語言顯得比較靈活的一個重要組成部分。如果嘗試使用基于大量代碼的GCC或LLVM來開發Go程序，感覺會有礙到Go語言的靈活性。另外，GCC是大量C代碼（現在有部分C++）、LLVM是大量C++代碼的程序。以上列舉的、用于解釋不使用現有編譯框架代碼的幾個原因，也都適用于更多的類似的代碼庫。

C語言的長期使用

臨近結束，這個計劃還留下了由C寫成的Plan9的工具鏈的一部分。在長期發展中，還是將所有的C從代碼樹排除掉比較好。本章節推測了一下這件事將會如何發生，但不保證其指定會發生或者按照這種套路發生。

運行時包(runtime)。 runtime包的大部分都是用C寫成，基于一些同樣的原因，Go編譯器也是用C實現。但是，runtime包遠比編譯器的代碼量要小，且它現在已經是用Go和C混合編寫。將C代碼轉換為Go代碼時，一次轉化一部分貌似也是可行的。其中，主要部分有：調度器（scheduler），垃圾回收（the garbage collector），散列映射表（hash map）的實現，和channel的實現。（這里Go和C代碼混合的很融洽，是因為這里使用的6c而不是gcc來編譯的C代碼。）

C編譯器。 Plan 9的C編譯器本身就是用C寫成，如果我們要從Go包實現里面移除所有的C代碼，那么我們將移除這些編譯工具：“go tool 6c”等等，另外，.c的文件也將不被支持出現的Go包的目錄里面。我們應該提前聲明這樣的計劃，以便使用C的第三方包有時間去移除這類C代碼的使用。（Cgo，由于使用了gcc來替代6c，所以它仍然可以作為一個途徑來在Go包中使用C實現部分功能。）在Go1的兼容性文檔中沒有包含工具鏈修改的描述，也就是說去掉C編譯器是被允許的。

匯編器。 Plan 9的匯編器也是用C實現的，但這個匯編器只不過是一系列解析樹組成的簡單解析器，這使得不論手動還是自動將它翻譯成Go語言都比較簡單。

連接器。 Plan 9的連接器也是由C寫成。最近的一些工作，已經將大部分的連接器工作放到的編譯器中，而且，也已經有個計劃將剩余的部分重寫成一個新的、更簡單的Go程序。轉移到編譯器的部分連接器代碼，現在需要隨著編譯器的原有代碼一起進行翻譯。

基于Libmach的工具: nm, pack, addr2line, 和objdump。 Nm現在已經使用Go語言重寫。Pack和addr2line可以任何一天被重寫。Objdump現在依賴于libmach的反匯編器，但這些轉換為Go也是比較簡單的，不論是使用機械還是人工翻譯。所以基于這幾點，libmach本身將來也可以被移除。

來源: http://www.oschina.net/translate/go-1-3-compiler-overhaul

英文來源:https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1

goprotobuf是go語言中寫的較好的一個實現, linux下的安裝非常方便, 但是windows需要添加plugin的路徑才能識別

先確認你已經設置好GOPATH, 并安裝好goprotobuf

我的goprotobuf路徑是標準的: $GOPATH/src/code.google.com/p/goprotobuf

編譯并安裝proto工具:

go install code.google.com/p/goprotobuf/proto

go install code.google.com/p/goprotobuf/protoc-gen-go

確認$GOPATH/bin下有protoc-gen-go.exe

編譯proto文件輸出go文件:

使用命令行編譯path/to/protoc.exe  --plugin=protoc-gen-go=$GOPATH\bin\protoc-gen-go.exe --go_out . --proto_path .  XXX.proto

這里順便貼出notepad++使用nppexec插件的command

"path/to/protoc.exe"  --plugin=protoc-gen-go=path/to/gopath/bin/protoc-gen-go.exe --go_out $(CURRENT_DIRECTORY) --proto_path $(CURRENT_DIRECTORY)  $(FULL_CURRENT_PATH)

P.S.

protoc請自行在protobuf官網下載C++源碼后編譯

1. Qt這個C++的圖形庫由Trolltech在1994年左右開發。它可以運行在Windows,Mac OS X, Unix，還有像Sharp Zaurus這類嵌入式系統中。Qt是完全面向對象的。

2. Qt的架構明顯是經過精心設計的面向對象的。Qt因此在命名，繼承，類的組織等方面保持了優秀的一致性。你只需要提供唯一一個方法的參數，僅此一個。在不同的類中調用方式也是有很強的連貫性。返回值也很有邏輯性。所有一切達到了簡單和強大的和諧統一。一旦你使用了其中一個類，其他的類也就觸類旁通，因為他們是一致的。

3. Qt不強制使用任何設計模式。如果你認為恰當，使用Document/view沒有任何問題。不使用也沒有任何問題。

4. MFC是事件驅動的架構。要執行任何操作，都必須是對特定的消息作出響應。Windows對應用程序發送的信息數以千計，遺憾的是，要分清楚這些分繁蕪雜的消息是很困難的，并且關于這方面的文檔并不能很好的解決這些問題。
Qt的消息機制是建立在SIGNAL()發送和SLOT()接受的基礎上的。這個機制是對象間建立聯系的核心機制。利用SIGNAL()可以傳遞任何的參數。他的功能非常的強大。可以直接大傳遞信號給SLOT()，因此可以清楚的理解要發生的事情。一個類所發送的信號的數量通常非常的小(4或者5)，并且文檔也非常的齊全。這讓你感覺到一切盡在掌握之中。SIGNAL/SLOT機制類似于Java中listener機制,不過這種機制更加輕量級，功能更齊全。

5. Qt擁有非常簡單而又不失強大的layout機制，布局靈活多變
Qt還提供了一個圖形用戶工具，Qt Designer，可以用來幫助建立用戶界面。可以修改所使用的任何控件的屬性。不用將他們放在嚴格的位置，可以通過layout完美的組織他們。這個工具所產生的代碼我們是可以實際上閱讀并且可以理解的。生成的代碼單獨放在一個文件里，在編程的同時，你可以隨心所欲的多次重新生成用戶界面。
Qt Designer可以讓你完成許多在MFC中不可能完成的任務，比如用預先填好的生成listview，在每個tab上用不同的view來使用tab 控制。

6. 使用MFC，一部分開發過程要依靠“resources”,在很多的案例中開發者必須使用他們。這樣會導致如下的后果：出了Visual Studio，你很難使用其他的工具來完成開發。
資源編輯器僅有有限的功能，比如：通過Dialog編輯器不可能改變所有的屬性，一些屬性可以改變，另一些屬性則不可能改變。(譯者注：下面還有兩條陳述MFC缺點的實例，但我感覺這些已經夠說明問題了，暫時刪節不譯)
然而Qt并沒有資源的概念，這就解決了以上所提到的問題。Qt提供了一個腳本使得能將編入你的代碼。對于界面設計，Qt Designer則創建了可讀的代碼。

7. Qt的文檔完備且詳細的覆蓋了Qt的方方面面，竟然僅有18M。每一個類和方法都被詳盡描述，巨細靡遺，舉例充實。通過Trolltech公司提供的鏈接或者是Qt Assistant工具，可以方便的從一個類或者方法跳轉到其他的類。文檔還包含了一個初學者教程和一些典型應用的例子

8. 在發布基于MFC的軟件時，必須依靠存在于客戶電腦上的MFC。但是這是不安全的，同樣是MFC42.dll，可以基于相同的庫得到3個不同的版本。通常，需要檢查是否擁有正確的MFC42.dll版本，如果不是，就升級它。但是升級MFC42.dll會改變很多軟件的行為。
Qt則沒有這個風險，因為Qt壓根就沒有“升級整個系統”這個概念。

9. Qt 完全支持CSS2，這使得Qt應用程序，無論是美化還是換膚，實現起來都相當簡單

10. Qt自帶翻譯器，可以隨意切換軟件語言

在使用Qt動態鏈接庫的情況下，根據LGPL協議規定，是可以閉源發布任何形式的程序的。

參考鏈接：

來自Qt官方論壇的討論：http://qt-project.org/forums/viewthread/2428

博客鏈接：http://devbean.blog.51cto.com/448512/313477

轉自:http://blog.csdn.net/superzhaifd/article/details/18224923 翟冬狼_Trump

本人較喜歡第二點: 不使用任何設計模式構建底層. 設計模式只是思想, 也是羈絆. 大量使用只會讓系統臃腫.

最近下載了最新的linux mint 16和ubuntu 12中分別嘗試編譯protobuf 2.5.0.但都是報c compiler cannot create executables的錯. 查過網上解決方案, 清一色都是export LIBS=之類的, 無法解決問題. 最終一個回帖啟發了我, 使用apt-get install g++ 發現C++編譯器根本都沒安… 安裝完畢, 一切搞定. linux mint越來越娛樂了, 連g++都不默認裝了…

比較過LiteIDE和eclipse+goclipse, 最后還是覺得LiteIDE簡潔.但發現其自動完成功能偶爾會出現, 隨即搜索, 發現其使用gocode的一個開源項目開了一個簡單服務, 為各種IDE提供高速的自動完成服務.在goclipse環境發現其報了版本不匹配的錯, 而最近go的更新也是很頻繁, 所以覺得應該是gocode版本過老造成.

搜索到gocode的開發頁面https://github.com/nsf/gocode  結果發現nsf這家伙居然也是luaBridge的作者.

下載最新的gocode代碼, 解壓后, 編譯:

windows下命令行

go build gocode.go autocompletecontext.go autocompletefile.go client.go config.go cursorcontext.go decl.go declcache.go formatters.go os_windows.go package.go ripper.go rpc.go scope.go server.go utils.go

linux下, 只需要將os_windows.go換為os_posix.go即可

編譯完成后, 將可執行文件gocode覆蓋到liteIDE下的同名文件, 殺掉gocode進程后重啟liteIDE即可

項目客戶端腳本全面升級lua5.2 這是自06年后最大的一次主干更新, 帶來的機制, 函數變化也是非常不錯的

1. 去掉了全局性質的setfenv/getfenv系列函數, 語言層面提供_ENV語法糖, 這東西跟:操作符一樣, 只存在于編譯期.

官方建議自己實現module/require/package機制, 畢竟原生這套機制實現太弱智了..

2. 提供了無符號訪問函數

3. 更多的lua api變化. 如果想兼容lua5.1的寫法, 可以參考luabridge內LuaHelpers.h的實現

以下是本人使用lua5.2實現的一套package機制, 供大家參考

package = {}

-- 讀取標記

package.loaded = {}

-- 搜索路徑數組

package.path = {}

package.access =

{

    ["string"] = string,

    ["print"] = print,

    ["table"] = table,

    ["assert"] = assert,

    ["error"] = error,

    ["pairs"] = pairs,

    ["ipairs"] = ipairs,

    ["tonumber"] = tonumber,

    ["tostring"] = tostring,

    ["type"] = type,

    ["math"] = math,

}

local function getreadablepath( name, pathlist )

    for _, path in ipairs(pathlist) do

        local fullpath = path .. "/" .. name .. ".lua"

        local f = io.open( fullpath )

        if f then

            f:close()

            return fullpath

        end

    end

    return nil

end

function package.import( name )

    -- 已經讀取的直接返回

    local existedenv = package.loaded[name]

    if existedenv then

        return existedenv

    end

    local access = package.access

    -- 設置訪問控制權限

    local meta = 

    {

        __index = function( tab, key )

            -- 優先取包的空間

            local v = rawget( tab, key )

            if v then

                return v

            end

            -- 找不到時,從可訪問的權限表中查找

            return access[key]             

        end,

    }

    -- 初始化一個包的全局環境, 并設置訪問方法

    local env = setmetatable( {} , meta )

    --

    local readablepath = getreadablepath( name, package.path )

    if not readablepath then

        error(string.format("package '%s' not found \n%s", name, table.concat( package.path, "\n" ) ) )

    end

    local func = loadfile( readablepath, "bt",  env )

    if type(func) ~= "function" then

        return nil

    end

    -- 設置標記

    package.loaded[name] = env

    -- 執行全局空間

    func( )

    return env

end

package.path = {"E:/Download/t"}

local m = package.import "m"

m.foo()

以下是m模塊(m.lua)的內容

function foo( )

    print("轉載注明: 戰魂小筑 http://m.shnenglu.com/sunicdavy", io )    

end

測試結果中, io打印出nil, 顯示權限已經被控制住

本package設計比原生package更靈活, 更強大

最近準備在手機項目客戶端中使用lua, 以前一直在服務器使用luabind. 另外, tolua++也體驗過, LuaPlus也在早年用過. 以下是本人對這些綁定庫的個人感覺:

luabind

利用boost機制把綁定做到極致, 比較適合主c++, 弱lua的腳本框架.

作者已經停止更新, 在windows/linux編譯沒問題, 但是在ios的LLVM下, 無法編譯

tolua++

像cocos2dx使用tolua++也是可以理解的, 那么多函數需要綁定, tolua++的頭文件parse及自動代碼生成節約了很多手動綁定的時間.

但是看到代碼中有一部分bugfix就心存不安(純個人感覺, 本人使用不多, 歡迎磚頭伺候),另外, tolua++只能由腳本層驅動C++, 而沒有將已經實例化的句柄注冊到lua的功能也是煞筆啊

LuaPlus

接口較為簡單, 適于初學者上手, 無任何的模板, 性能不高

luaBridge

項目地址: https://github.com/vinniefalco/LuaBridge

手冊: http://vinniefalco.com/LuaBridge/Manual.html

純頭文件實現, 無需編譯, 包含進入工程即可, 接口簡潔高效

相比luabind, 唯一不能實現的常用功能就是枚舉, 但是可以支持類成員靜態變量注冊, 這個就無所謂了, 手寫一個枚舉支持也很簡單

看下演示代碼:

class A
{
public:
    A( )
    {

    }
    virtual void foo( int a )
    {
        printf("foo base\n");
    }

    std::string Member;
};

class B : public A
{
public:
    virtual void foo( int a )
    {
        printf("foo inherited\n");
    }
};

void foo( int b )
{

}

luabridge::getGlobalNamespace(L)
        .beginClass<A>("Sobj")
            .addConstructor<void (*) (void)> ()
            .addFunction("foo", &A::foo)
            .addData("Member",&A::Member)
        .endClass()
        .deriveClass<B, A>("SSec")
            .addFunction("foo",&B::foo )
        .endClass();

    luabridge::getGlobalNamespace(L).addFunction("foo", foo );


    B ins;
    ins.Member = "data";
    luabridge::setGlobal(L, ins, "ins");

lua側的代碼

local a = Sobj()
a:foo(2)
a.Member = "hello"


ins:foo(3)

NDK版本r8

下載log4cpp-1.1.tar.gz并解壓

默認情況下, log4cpp準備好了windows平臺的config文件, 但是linux下一般是通過configurator生成的.

我先找了個linux生成了一下, 然后把config放在log4cpp/include/log4cpp/config.h, 內容參見

#ifndef _INCLUDE_LOG4CPP_CONFIG_H

#define _INCLUDE_LOG4CPP_CONFIG_H 1

/* include/log4cpp/config.h. Generated automatically at end of configure. */

/* include/config.h.  Generated from config.h.in by configure.  */

/* include/config.h.in.  Generated from configure.in by autoheader.  */

/* Define to 1 if you have the <dlfcn.h> header file. */

#ifndef LOG4CPP_HAVE_DLFCN_H 

#define LOG4CPP_HAVE_DLFCN_H  1 

#endif

/* Define to 1 if you have the `ftime' function. */

#ifndef LOG4CPP_HAVE_FTIME 

#define LOG4CPP_HAVE_FTIME  1 

#endif

/* Define to 1 if you have the `gettimeofday' function. */

#ifndef LOG4CPP_HAVE_GETTIMEOFDAY 

#define LOG4CPP_HAVE_GETTIMEOFDAY  1 

#endif

/* define if the compiler has int64_t */

#ifndef LOG4CPP_HAVE_INT64_T 

#define LOG4CPP_HAVE_INT64_T  /**/ 

#endif

/* Define to 1 if you have the <inttypes.h> header file. */

#ifndef LOG4CPP_HAVE_INTTYPES_H 

#define LOG4CPP_HAVE_INTTYPES_H  1 

#endif

/* Define to 1 if you have the <io.h> header file. */

/* #undef LOG4CPP_HAVE_IO_H */

/* Define to 1 if you have the `idsa' library (-lidsa). */

/* #undef LOG4CPP_HAVE_LIBIDSA */

/* Define to 1 if you have the `localtime_r' function. */

#ifndef LOG4CPP_HAVE_LOCALTIME_R 

#define LOG4CPP_HAVE_LOCALTIME_R  1 

#endif

/* Define to 1 if you have the <memory.h> header file. */

#ifndef LOG4CPP_HAVE_MEMORY_H 

#define LOG4CPP_HAVE_MEMORY_H  1 

#endif

/* define if the compiler implements namespaces */

#ifndef LOG4CPP_HAVE_NAMESPACES 

#define LOG4CPP_HAVE_NAMESPACES  /**/ 

#endif

/* Define if you have POSIX threads libraries and header files. */

#ifndef LOG4CPP_HAVE_PTHREAD 

#define LOG4CPP_HAVE_PTHREAD  1 

#endif

/* define if the C library has snprintf */

#ifndef LOG4CPP_HAVE_SNPRINTF 

#define LOG4CPP_HAVE_SNPRINTF  /**/ 

#endif

/* define if the compiler has stringstream */

#ifndef LOG4CPP_HAVE_SSTREAM 

#define LOG4CPP_HAVE_SSTREAM  /**/ 

#endif

/* define if you have the <stdint.h> header file. */

#ifndef LOG4CPP_HAVE_STDINT_H 

#define LOG4CPP_HAVE_STDINT_H  /**/ 

#endif

/* Define to 1 if you have the <stdlib.h> header file. */

#ifndef LOG4CPP_HAVE_STDLIB_H 

#define LOG4CPP_HAVE_STDLIB_H  1 

#endif

/* Define to 1 if you have the <strings.h> header file. */

#ifndef LOG4CPP_HAVE_STRINGS_H 

#define LOG4CPP_HAVE_STRINGS_H  1 

#endif

/* Define to 1 if you have the <string.h> header file. */

#ifndef LOG4CPP_HAVE_STRING_H 

#define LOG4CPP_HAVE_STRING_H  1 

#endif

/* Define to 1 if you have the `syslog' function. */

#ifndef LOG4CPP_HAVE_SYSLOG 

#define LOG4CPP_HAVE_SYSLOG  1 

#endif

/* Define to 1 if you have the <sys/stat.h> header file. */

#ifndef LOG4CPP_HAVE_SYS_STAT_H 

#define LOG4CPP_HAVE_SYS_STAT_H  1 

#endif

/* Define to 1 if you have the <sys/types.h> header file. */

#ifndef LOG4CPP_HAVE_SYS_TYPES_H 

#define LOG4CPP_HAVE_SYS_TYPES_H  1 

#endif

/* define if threading is enabled */

#ifndef LOG4CPP_HAVE_THREADING 

#define LOG4CPP_HAVE_THREADING  1 

#endif

/* Define to 1 if you have the <unistd.h> header file. */

#ifndef LOG4CPP_HAVE_UNISTD_H 

#define LOG4CPP_HAVE_UNISTD_H  1 

#endif

/* Define to the sub-directory in which libtool stores uninstalled libraries.

   */

#ifndef LOG4CPP_LT_OBJDIR 

#define LOG4CPP_LT_OBJDIR  ".libs/" 

#endif

/* Name of package */

#ifndef LOG4CPP_PACKAGE 

#define LOG4CPP_PACKAGE  "log4cpp" 

#endif

/* Define to the address where bug reports for this package should be sent. */

#ifndef LOG4CPP_PACKAGE_BUGREPORT 

#define LOG4CPP_PACKAGE_BUGREPORT  "" 

#endif

/* Define to the full name of this package. */

#ifndef LOG4CPP_PACKAGE_NAME 

#define LOG4CPP_PACKAGE_NAME  "log4cpp" 

#endif

/* Define to the full name and version of this package. */

#ifndef LOG4CPP_PACKAGE_STRING 

#define LOG4CPP_PACKAGE_STRING  "log4cpp 1.1" 

#endif

/* Define to the one symbol short name of this package. */

#ifndef LOG4CPP_PACKAGE_TARNAME 

#define LOG4CPP_PACKAGE_TARNAME  "log4cpp" 

#endif

/* Define to the home page for this package. */

#ifndef LOG4CPP_PACKAGE_URL 

#define LOG4CPP_PACKAGE_URL  "" 

#endif

/* Define to the version of this package. */

#ifndef LOG4CPP_PACKAGE_VERSION 

#define LOG4CPP_PACKAGE_VERSION  "1.1" 

#endif

/* Define to necessary symbol if this constant uses a non-standard name on

   your system. */

/* #undef LOG4CPP_PTHREAD_CREATE_JOINABLE */

/* Define to 1 if you have the ANSI C header files. */

#ifndef LOG4CPP_STDC_HEADERS 

#define LOG4CPP_STDC_HEADERS  1 

#endif

/* define if pthread library is available */

#ifndef LOG4CPP_USE_PTHREADS 

#define LOG4CPP_USE_PTHREADS  1 

#endif

/* Version number of package */

#ifndef LOG4CPP_VERSION 

#define LOG4CPP_VERSION  "1.1" 

#endif

/* _INCLUDE_LOG4CPP_CONFIG_H */

#endif 

接著, 修改log4cpp/include/log4cpp/RemoteSyslogAppender.hh的包含,改為

#ifdef WIN32
#include <winsock2.h>
#else
#include <netdb.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#endif

可以刪除RemoteSyslogAppender.cpp里的這個定義即可

添加Android.mk

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := log4cpp

LOCAL_SRC_FILES := \

src/AbortAppender.cpp \

src/Appender.cpp \

src/AppendersFactory.cpp \

src/AppenderSkeleton.cpp \

src/BasicConfigurator.cpp \

src/BasicLayout.cpp \

src/BufferingAppender.cpp \

src/Category.cpp \

src/CategoryStream.cpp \

src/Configurator.cpp \

src/DllMain.cpp \

src/DummyThreads.cpp \

src/FactoryParams.cpp \

src/FileAppender.cpp \

src/Filter.cpp \

src/FixedContextCategory.cpp \

src/HierarchyMaintainer.cpp \

src/IdsaAppender.cpp \

src/LayoutAppender.cpp \

src/LayoutsFactory.cpp \

src/LevelEvaluator.cpp \

src/Localtime.cpp \

src/LoggingEvent.cpp \

src/Manipulator.cpp \

src/MSThreads.cpp \

src/NDC.cpp \

src/NTEventLogAppender.cpp \

src/OmniThreads.cpp \

src/OstreamAppender.cpp \

src/PassThroughLayout.cpp \

src/PatternLayout.cpp \

src/PortabilityImpl.cpp \

src/Priority.cpp \

src/Properties.cpp \

src/PropertyConfigurator.cpp \

src/PropertyConfiguratorImpl.cpp \

src/PThreads.cpp \

src/RemoteSyslogAppender.cpp \

src/RollingFileAppender.cpp \

src/SimpleConfigurator.cpp \

src/SimpleLayout.cpp \

src/SmtpAppender.cpp \

src/StringQueueAppender.cpp \

src/StringUtil.cpp \

src/SyslogAppender.cpp \

src/TimeStamp.cpp \

src/TriggeringEventEvaluatorFactory.cpp \

LOCAL_C_INCLUDES := $(LOCAL_PATH) \

                    $(LOCAL_PATH)/include

include $(BUILD_STATIC_LIBRARY)