战魂小筑

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://www.cppblog.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)