C#

开发效率：Windows下可以通过VisualStudio进行开发，其他平台可以使用MonoDevelop，非常方便

运行效率：JIT的性能优化比较到位，能适应90%性能环境

部署便捷性：可以通过交叉编译生成其他平台的可执行文件，通过mono运行可执行文件

调试便捷性：VisualStudio和MonoDevelop调试均很方便， 还可远程调试

上手度：对C系语言熟悉的几天就可上手

热更新：可以通过DLL方式进行

Web对接：可做，代码比较啰嗦

崩溃处理：可通过try catch捕获错误

网络库编写难度：一般，需注意gc问题

第三方网络库及框架数量：一般

Golang

开发效率：高

运行效率：并发上非常有优势，对CPU利用率比较高，原生运行无虚拟机

部署便捷性：一次编译到处运行，无任何运行库依赖

调试便捷性：实际操作中，单线程挂接调试器可行， 但变量显示不正确，开发期基本采用日志方式进行查错

上手度：语言简单，特性少， 新手1周能贡献代码

热更新：无法进行热更新，语言无法编译为DLL，也不支持DLL加载（linux平台的.so加载忽略不计）

Web对接：非常方便， 代码精简

崩溃处理：崩溃后以命令行方式打印出栈，程序内可以捕获任何崩溃错误并继续运行

网络库编写难度：简单，比C socket更简单

第三方网络库及框架数量：偏少

Skynet(lua+C)

开发效率：基于动态语言的开发初次写比较快，后期维护和重构会耗费一定的时间在查错上

运行效率：基于lua jit的运行效率还是能接受的

部署便捷性：方便， 只有底层修改需要重新编译， 大部分时间只用更新lua文件

调试便捷性：不是很方便，基于日志方式进行查错

上手度：lua语言特性有部分和C系语言有一定差异，基于Actor模型的思想学习，适应需要耗费一定的时间

热更新：类似于Erlang，可精确到函数级的热更新

Web对接：有一些http支持，通过社区慢慢进行完善

崩溃处理：lua天生可以捕获错误

网络库编写难度：自带，无需编写

第三方网络库及框架数量：通过社区慢慢完善

C++

开发效率：编译慢，文件多，通用库少

运行效率：native速度标杆

部署便捷性：编写各类的make门槛较高

调试便捷性：可通过VisualStudio进行Windows平台调试

上手度：2~3年经验的熟手仍然会写出崩溃和泄露代码

热更新：可通过DLL进行

Web对接：代码啰嗦，第三方库少

崩溃处理：Windows下可使用SEH捕获段异常，其他平台只能通过崩溃后进行coredump分析，容错非常差

网络库编写难度：基于asio编写较为简单，但总体看来难度不低

第三方网络库及框架数量：较多

以下是得分

从发文时的项目对这些语言使用率来说，Java，Erlang，C++编写的服务器较多，Golang，JavaScript，C#是第二梯队，Skynet由于上手不是很容易，所以仅有两位数的团队在使用，但总体表现还是比较出色的

对于老团队， C++的服务器工具链和框架已经相对成熟， 完全没必要更换新语言， 只是在对接sdk感觉困难时，可以尝试Golang这些对web有优势的语言进行混合语言开发

对于新团队，开发效率，上手度和部署效率是优先选择的，C#，Golang，JavaScript这些新兴语言会让你事半功倍

对于大规模无需选服的服务器， Skynet的actor模型对扩展会比较容易

对于大公司，好项目，上线后需要通过热更新进行bug修补的，C#，C++，Erlang会是首选

但总的一点， 还是根据团队熟悉度来选择语言，贸然的使用新语言的风险也是很大的

基于C/C++游戏服务器框架总体设计的还是不错的, 兄弟们总体使用效果都是好评. 因为在技术上喜欢"偷懒", 所以在很多设计上, 都是力求简单, 高效(开发效率).

基于任务的异步DB查询系统, 带多重异步的同步

代码示例:

   1:   

   2:  void BatchQueryPlayerInfo( uint32 ClientID, const std::string& AccountName, int64 CharID )

   3:  {

   4:      GDBExecutor->Commit

   5:          (    

   6:          dynamic_cast<DBDataTask*>( (new DBQueryCharInfo(  ClientID, CharID ) ) 

   7:          ->LinkAtomTask( new DBQueryQuest( ClientID, CharID ) )

   8:          ->LinkAtomTask( new DBQuerySkill( ClientID, CharID ) )

   9:          ->LinkAtomTask( new DBQueryHero( ClientID, CharID ) )

  10:          ->LinkAtomTask( new DBQueryAccountInfo( ClientID, AccountName ) )

  11:          ->LinkAtomTask( new DBQueryEquip( ClientID, CharID ) )

  12:          ->LinkAtomTask( new DBQueryObject( ClientID ,CharID ) )

  13:          ->LinkAtomTask( new DBQueryLevel(ClientID, CharID))

  14:          ->LinkAtomTask( new DBQueryChapter(ClientID, CharID))

  15:          ->LinkAtomTask( new DBQueryActivity( ClientID, CharID ))

  16:          )

  17:          );

  18:   

  19:  }

这段主要处理玩家在登陆时, 需要从DB查询大量的不同分类的数据. 为了保证效率, 我让每个Task并行执行, 然后通过一个机制, 让所有任务完成后, 回调第一个任务的一个函数. 这样就无需手动实现很多粘合代码, 避免了反复调试和错误

基于protobuf反射机制的语句自动合成

   1:  DBUpdateCharInfo::DBUpdateCharInfo( int64 CharID, const std::string& Buffer )

   2:  {

   3:      char buffer[256];

   4:   

   5:      sprintf( buffer, "update tb_char set $FIELD$ where charid = %lld;", CharID );

   6:          

   7:      ExecuteCommand( buffer, Buffer, dbopr::FET_Equation );

   8:  }

这段就是一个典型的DB任务, 构造函数提供了CharID和一个由结构体序列化好的buffer, $FIELD$字段, 是通过反射根据Buffer内容, 自动填充字段

这段例子中, $FIELD$可以填充为 hp=100, mp=100之类的. 自动填充避免了因为添加字段的到处添加代码, 还需要调试, 容易搞错

配置系统概念

基于同一个配置系统, 分层实现不同的需求. 更简单的说, 解决的1个实际问题是:

自己改了配置文件中的ip, 上传svn后, 覆盖了别人的配置, 很多人的解决方法都是, 本地配置不提交. 但同时问题又来了:

当配置中有别人新加的系统配置, 怎么保证每个人都能更新到?

上线后, 服务器交付运维, 他们会对配置有一定程度的修改, 这个时候怎么合并程序配置和运维配置?

其实对于冲突的需求, 只要对系统进行分层就可以解决问题,我的处理方式:

配置分为:

全局配置: 所有服务的总体配置

单服务配置: 本服务的配置, 涉及网络及逻辑

本地配置: 这个配置每个人一份, 不上传SVN

命令行配置: 格式和前面的一致, 这块就可以通过运维进行配置

总体结构其实就是OO的派生概念, 下层可以覆盖, 修改上层的配置

服务器互联及识别框架

基本功能: 基于一些简单的配置就可以将多台服务器, 同种类的不同服务器互相连接起来, 断线自动重连.

服务器连接后, 所有服务器可知晓并可自动按需连接

逻辑端也很方便的进行广播或者单独发送等

也就是说, 每个服务器的连接和接受端都是带识别名称或id的.

后面觉得这套东西实在是做的复杂, 多整出一台中心服务器来做. 但好歹框架稳定下来了, 也就好了.

基于lua的服务器web后台框架

思想是很不错的,  C++ 配合lua本身绝对是个失败

问题出在web处理,本身都是一个同步阻塞过程, 而这个后台框架是异步方式来做, 所以特别别扭

不过比起以前的本地GM系统, 这块的设计是伟大的进步

现在正在设计基于golang的服务器框架, 基本框架已经完工, 等待编写逻辑后的实战测试

以上的很多思想在golang的服务器框架都有改进, 特别是golang本身做web也是优秀的, 外加martini这种牛X框架, 更是水到渠成

如果你对服务器框架设计有特别的认识, 或者想碰撞思想, 可以加博客群 309800774或者我的qq: 20998333讨论

Decoda

    这是现今地球上调试lua5.1最方便的工具, 没有之一. 强大的注入式调试, 性能极高.支持 挂接进程, 变量展开, 断点等各种日常所需.

早期的Decoda是收费工具, 因此质量非常高.

    Decoda现在已经停止开发并开源了, 调试lua5.2会crash. 源代码可以作为一种技术参考, 很多dll注入修改技术, 灰常牛X

LuaStudio

   比较优秀的调试工具(因为收费), 可以调试lua5.1/5.2, 界面属于vs2008类型, 土豪可以考虑买几套试试

ZeroBrane Studio

对lua5.1支持较好, 5.2也能调但偶尔还是会crash, 基于远程调试方式, 所以性能略低.

RemDebug

没有IDE, 纯命令行方式调试器, 但因为简单, 所以可以参考后写一个自己的程序内建调试器

Babe Lua

把这货放在最后是有原因的, 还记得那句老话: 老外一开源, 我们就有自主研发了, 对的, 这货一定是参考了Decoda的代码后搞出个vs的插件来, 虽然不收费, 但是不提下参考对象的行为还是值得批斗的. 这货在中文博客上说, 不支持挂接到进程(Decoda支持), 不支持64位调试(LuaStudio支持), 调试30~50次偶尔挂1到2次. 哎, 毕竟只是代码搬运工, 不生产代码.

这货装上, 能用, 调5.2是不行的, 5.1比Decoda方便点, 毕竟vs支持悬浮显示变量.

说了那么多, 其实对于lua5.2版本的调试, 还是没有免费的比较合适的方案, 如果实在想调试, 还是可以参考下RemDebug的原理及lua官方调试文档, 自己通过c api调用写一套适合自己的远程调试工具. 其实没有多复杂, 但总比不调试的好

由于要使用protoc-gen-lua, 这东西生成出来的lua依然使用官方的module/package机制. 对于游戏项目来说, 想进行一些自定义读取, 加密等, 就变得不可能. 幸好官方在扩展上支持的还是不错的.

参考lua5.2的官方文档http://www.lua.org/manual/5.2/manual.html#pdf-require

require时, lua会自动根据一定的搜索规律找到加载代码的方法. 这个方法定义在package.searchers这个数组中. 一共有4个加载搜索顺序

1. preload, 对已加载的module进行直接返回, 对应package.preload[modname]

2. lualoader, 对lua文件进行加载, 搜索路径为package.path

3. cloader, 对lua标准dll进行加载, 搜索路径为package.cpath

4. croot, 官方文档说的是all-in-one加载器, 感觉很神奇, 感兴趣可以自行参考源码

那么, 如果只需要自己的加载器, 只需要这样做:

  package.searchers[2] = function( name )
        print("try to load", name )
    end
    package.searchers[3] = nil
    package.searchers[4] = nil
    
    require "libtest"

看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, 下载,编译一气呵成

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,编写自己的导出插件才是王道!

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

本人较喜欢第二点: 不使用任何设计模式构建底层. 设计模式只是思想, 也是羁绊. 大量使用只会让系统臃肿.

最近准备在手机项目客户端中使用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)

error: missing binary operator before token "("

根据老外的描述, boost中的BOOST_PP_ITERATION_FLAGS从1.49版本后发生了一些变化.

在git找到一个patch, 链接在此

以下简单描述

修改call_function.hpp, call_member.hpp及wrapper_base.hpp

去掉#elif BOOST_PP_ITERATION_FLAGS() == 1

更换为

#else

#if BOOST_PP_ITERATION_FLAGS() == 1

然后在源码底部加一个#endif即可

在启动前, 添加如下代码:

QApplication qapp(argc, argv);   

qapp.addLibraryPath(QCoreApplication::applicationDirPath()+"/plugins");

将QT开发目录下: Qt\4.8.2\plugins\拷贝到Qt的exe目录即可

cygwin参考这里

http://my.oschina.net/tonywolf/blog/49214

简单的说

1.下载cygwin的网络安装包(第一次安装只能这样)

2. 选择靠前一点的网站进行下载( 下好的包可以留着, 下次安装直接从文件夹中选择就可以安装)

cygwin下使用NDK编译boost参考这里

http://blog.sina.com.cn/s/blog_a6946c8a01016aot.html

细节注意:

1. boost官网下载boost_1_53_0.tar.bz2, 解压放在android-ndk-r8e/sources下

2. 生成boost编译工具: 在boost目录下运行 ./bootstrap.sh 或者 bootstrap.bat 生成 b2

3. 修改 boost/tools/build/v2/user-config.jam 内容修改如下

import os ;

if [ os.name ] = CYGWIN || [ os.name ] = NT {

androidPlatform = windows ;

}

else if [ os.name ] = LINUX {

androidPlatform = linux-x86_64 ;

}

else if [ os.name ] = MACOSX {

androidPlatform = darwin-x86 ;

}

modules.poke : NO_BZIP2 : 1 ;

ANDROID_NDK = ../.. ;

using gcc : android4.6 : $(ANDROID_NDK)/toolchains/arm-linux-androideabi-4.6/prebuilt/$(androidPlatform)/bin/arm-linux-androideabi-g++ :

<archiver>$(ANDROID_NDK)/toolchains/arm-linux-androideabi-4.6/prebuilt/$(androidPlatform)/bin/arm-linux-androideabi-ar

<ranlib>$(ANDROID_NDK)/toolchains/arm-linux-androideabi-4.6/prebuilt/$(androidPlatform)/bin/arm-linux-androideabi-ranlib

<compileflags>--sysroot=$(ANDROID_NDK)/platforms/android-9/arch-arm

<compileflags>-I$(ANDROID_NDK)/sources/cxx-stl/gnu-libstdc++/4.6/include

<compileflags>-I$(ANDROID_NDK)/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi/include

<compileflags>-DNDEBUG

<compileflags>-D__GLIBC__

<compileflags>-DBOOST_FILESYSTEM_VERSION=3

<compileflags>-lstdc++

<compileflags>-lgnustl_shared

<compileflags>-mthumb

<compileflags>-fno-strict-aliasing

<compileflags>-std=gnu++11

<compileflags>-O2

;

4. 为了安全起见, 我打了个BoostForAndriod上的补丁: 手动修改下就好了

diff -ruN boost_1_53_0-boot/boost/asio/detail/socket_types.hpp boost_1_53_0-patched/boost/asio/detail/socket_types.hpp

--- boost_1_53_0-boot/boost/asio/detail/socket_types.hpp     2012-01-15 14:46:25.000000000 +0100

+++ boost_1_53_0-patched/boost/asio/detail/socket_types.hpp     2012-06-27 19:19:01.279562338 +0200

@@ -123,7 +123,12 @@

typedef int socket_type;

const int invalid_socket = -1;

const int socket_error_retval = -1;

+// @Moss - Some platforms do not define it (Android)

+#if defined(INET_ADDRSTRLEN)

const int max_addr_v4_str_len = INET_ADDRSTRLEN;

+#else // defined(INET_ADDRSTRLEN)

+const int max_addr_v4_str_len = 16;

+#endif // defined(INET_ADDRSTRLEN)

#if defined(INET6_ADDRSTRLEN)

const int max_addr_v6_str_len = INET6_ADDRSTRLEN + 1 + IF_NAMESIZE;

#else // defined(INET6_ADDRSTRLEN)

diff -ruN boost_1_53_0-boot/boost/asio/ip/impl/address_v6.ipp boost_1_53_0-patched/boost/asio/ip/impl/address_v6.ipp

--- boost_1_53_0-boot/boost/asio/ip/impl/address_v6.ipp     2012-01-15 14:46:25.000000000 +0100

+++ boost_1_53_0-patched/boost/asio/ip/impl/address_v6.ipp     2012-06-27 19:19:11.029581297 +0200

@@ -11,6 +11,23 @@

#ifndef BOOST_ASIO_IP_IMPL_ADDRESS_V6_IPP

#define BOOST_ASIO_IP_IMPL_ADDRESS_V6_IPP

+// @Moss - Define IPv6 macros

+#if !defined(IN6_IS_ADDR_MULTICAST) 

+#define IN6_IS_ADDR_MULTICAST(a) (((__const uint8_t *) (a))[0] == 0xff)

+#endif

+

+#if !defined(IN6_IS_ADDR_MC_NODELOCAL)

+#define IN6_IS_ADDR_MC_NODELOCAL(a) \

+        (IN6_IS_ADDR_MULTICAST(a) \

+         && ((((__const uint8_t *) (a))[1] & 0xf) == 0x1))

+#endif

+

+#if !defined(IN6_IS_ADDR_MC_GLOBAL)

+#define IN6_IS_ADDR_MC_GLOBAL(a) \

+        (IN6_IS_ADDR_MULTICAST(a) \

+         && ((((__const uint8_t *) (a))[1] & 0xf) == 0xe))

+#endif

+

#if defined(_MSC_VER) && (_MSC_VER >= 1200)

# pragma once

#endif // defined(_MSC_VER) && (_MSC_VER >= 1200)

diff -ruN boost_1_53_0-boot/boost/config/user.hpp boost_1_53_0-patched/boost/config/user.hpp

--- boost_1_53_0-boot/boost/config/user.hpp     2004-01-10 13:10:00.000000000 +0100

+++ boost_1_53_0-patched/boost/config/user.hpp     2012-06-27 19:18:46.129532736 +0200

@@ -13,6 +13,15 @@

//  configuration policy:

//

+// Android defines

+#define __arm__ 1

+#define _REENTRANT 1

+#define _GLIBCXX__PTHREADS 1

+// There is problem with std::atomic on android (and some other platforms).

+// See this link for more info:

+// https://code.google.com/p/android/issues/detail?id=42735#makechanges

+#define BOOST_ASIO_DISABLE_STD_ATOMIC 1

+

// define this to locate a compiler config file:

// #define BOOST_COMPILER_CONFIG <myheader>

diff -ruN boost_1_53_0-boot/boost/detail/endian.hpp boost_1_53_0-patched/boost/detail/endian.hpp

--- boost_1_53_0-boot/boost/detail/endian.hpp     2011-03-29 23:58:48.000000000 +0200

+++ boost_1_53_0-patched/boost/detail/endian.hpp     2012-06-27 19:18:39.359519453 +0200

@@ -31,7 +31,7 @@

// GNU libc offers the helpful header <endian.h> which defines

// __BYTE_ORDER

-#if defined (__GLIBC__)

+#if defined (__GLIBC__) || defined(ANDROID)

# include <endian.h>

# if (__BYTE_ORDER == __LITTLE_ENDIAN)

#  define BOOST_LITTLE_ENDIAN

diff -ruN boost_1_53_0-boot/boost/interprocess/detail/workaround.hpp boost_1_53_0-patched/boost/interprocess/detail/workaround.hpp

--- boost_1_53_0-boot/boost/interprocess/detail/workaround.hpp     2011-12-26 18:21:36.000000000 +0100

+++ boost_1_53_0-patched/boost/interprocess/detail/workaround.hpp     2012-06-27 19:18:52.909546004 +0200

@@ -54,7 +54,7 @@

    #endif

    //Check for XSI shared memory objects. They are available in nearly all UNIX platforms

-   #if !defined(__QNXNTO__)

+   #if !defined(__QNXNTO__) && !defined(ANDROID)

       #define BOOST_INTERPROCESS_XSI_SHARED_MEMORY_OBJECTS

    #endif

diff -ruN boost_1_53_0-boot/libs/filesystem/src/operations.cpp boost_1_53_0-patched/libs/filesystem/src/operations.cpp

--- boost_1_53_0-boot/libs/filesystem/src/operations.cpp     2012-01-28 15:40:16.000000000 +0100

+++ boost_1_53_0-patched/libs/filesystem/src/operations.cpp     2012-06-27 19:19:19.269597266 +0200

@@ -73,13 +73,15 @@

     const fs::path dot_dot_path("..");

#   include <sys/types.h>

#   include <sys/stat.h>

-#   if !defined(__APPLE__) && !defined(__OpenBSD__)

+#   if !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__ANDROID__) && !defined(ANDROID)

#     include <sys/statvfs.h>

#     define BOOST_STATVFS statvfs

#     define BOOST_STATVFS_F_FRSIZE vfs.f_frsize

#   else

#     ifdef __OpenBSD__

#     include <sys/param.h>

+#     elif defined(__ANDROID__) || defined(ANDROID) // @Moss - Android messes up a bit with some headers, this one is the correct one :D

+#     include <sys/vfs.h>

#     endif

#     include <sys/mount.h>

#     define BOOST_STATVFS statfs

@@ -206,7 +208,19 @@

          || ::mkdir(to.c_str(),from_stat.st_mode)!= 0))

#   define BOOST_COPY_FILE(F,T,FailIfExistsBool)copy_file_api(F, T, FailIfExistsBool)

#   define BOOST_MOVE_FILE(OLD,NEW)(::rename(OLD, NEW)== 0)

+#if defined(__ANDROID__) || defined(ANDROID)

+    int BOOST_RESIZE_FILE(const char *path, off_t size)

+    {

+      int result = -1;

+      int fd = open(path, O_WRONLY);

+      if (fd != -1)

+        result = ftruncate(fd, size);

+      close(fd);

+      return result;

+    }

+#else

#   define BOOST_RESIZE_FILE(P,SZ)(::truncate(P, SZ)== 0)

+#endif

#   define BOOST_ERROR_NOT_SUPPORTED ENOSYS

#   define BOOST_ERROR_ALREADY_EXISTS EEXIST

5. 命令行编译:

./b2 --without-python --without-mpi --without-serialization toolset=gcc-android4.6 link=static runtime-link=static target-os=linux --stagedir=android

使用编译完成的boost库

1. 将编译boost_1_53_0\android\lib\ 下的.a库 及boost_1_53_0\boost\下的头文件拷贝出来放在工程的boost4android目录下

2. 在boost4android目录下,创建Android.mk, 内容如下

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_atomic

LOCAL_SRC_FILES:= lib/libboost_atomic.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_chrono

LOCAL_SRC_FILES:= lib/libboost_chrono.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_context

LOCAL_SRC_FILES:= lib/libboost_context.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_date_time

LOCAL_SRC_FILES:= lib/libboost_date_time.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_exception

LOCAL_SRC_FILES:= lib/libboost_exception.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_filesystem

LOCAL_SRC_FILES:= lib/libboost_filesystem.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_graph

LOCAL_SRC_FILES:= lib/libboost_graph.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_iostreams

LOCAL_SRC_FILES:= lib/libboost_iostreams.a 

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_math_c99

LOCAL_SRC_FILES:= lib/libboost_math_c99.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_math_c99f

LOCAL_SRC_FILES:= lib/libboost_math_c99f.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_math_c99l

LOCAL_SRC_FILES:= lib/libboost_math_c99l.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_math_tr1

LOCAL_SRC_FILES:= lib/libboost_math_tr1.a 

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_math_tr1f

LOCAL_SRC_FILES:= lib/libboost_math_tr1f.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_math_tr1l

LOCAL_SRC_FILES:= lib/libboost_math_tr1l.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_program_options

LOCAL_SRC_FILES:= lib/libboost_program_options.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_random

LOCAL_SRC_FILES:= lib/libboost_random.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_regex

LOCAL_SRC_FILES:= lib/libboost_regex.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_system

LOCAL_SRC_FILES:= lib/libboost_system.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_thread

LOCAL_SRC_FILES:= lib/libboost_thread.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE:= boost_timer

LOCAL_SRC_FILES:= lib/libboost_timer.a

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_STATIC_LIBRARY)

LOCAL_WHOLE_STATIC_LIBRARIES += boost_system
LOCAL_WHOLE_STATIC_LIBRARIES += boost_filesystem
LOCAL_WHOLE_STATIC_LIBRARIES += boost_thread

用多少, 包多少

添加异常支持 LOCAL_CPPFLAGS += –fexceptions

添加模块引用

$(call import-module,boost4android)

文本格式的解析错误不能使用捕获错误来获取, 因此,我们需要使用自定义的错误收集器进行收集, 看代码:

#include <google/protobuf/text_format.h>

#include <google/protobuf/io/zero_copy_stream_impl_lite.h>

#include <google/protobuf/io/tokenizer.h>

class PBTextErrorCollector : public google::protobuf::io::ErrorCollector

{

public:

    PBTextErrorCollector( const std::string& FileName )

        : mFileName( FileName )

    {

    }

    virtual void AddError(int line, int column, const string& message)

    {

        CCLog("%s(%d:%d) %s ", mFileName.c_str(), line, column, message.c_str() );

    }

    virtual void AddWarning(int line, int column, const string& message) 

    {

        CCLog("%s(%d:%d) %s ", mFileName.c_str(), line, column, message.c_str() );

    }

private:

    std::string mFileName;

};

解析代码

google::protobuf::TextFormat::Parser P;        

    P.RecordErrorsTo( &PEC );

    P.Parse( &AIS, &AF );

另外: 文本格式的注释使用unix shell风格: 以#开头

下面是我的文本格式的配置文件

AnchorPointX: 0.5
AnchorPointY: 0

SpriteScale: 2

ComponentName: "ActorActionManager"
ComponentName: "ActorFrameEventDispatcher"
#ComponentName: "SoundFXController"
ComponentName: "RoleDeltaMoveController"
ComponentName: "RoleBehaviorDirector"

InitAction: AA_Idle

Animations 
{
  AnimationName: "mai_idle"
  AnimationInterval: 0.067
}

在你的Android.mk文件中添加 LOCAL_CPPFLAGS += -std=gnu++0x即可

pdb加载是正常的, 但是堆栈没显示如此简单的空指针访问位置. Google了以下

http://blogs.msdn.com/b/debugger/archive/2010/05/12/visual-studio-debugger-fails-to-catch-unhandled-exception-for-a-windows-form-or-wpf-application.aspx

解决方法: Debug->Exception中将所有异常勾选即可

不知道哪里的设置导致如此诡异的问题, 害的我重装一次..

ProjectName\

src\

  core\

  share\

  proj.android\

    jni\

    …

sdk\

  protobuf-2.4.1\

    src\

    …

从Google code下载protobuf-2.4.1源码包, 解压, 在protobuf-2.4.1目录下添加Android.mk, 内容如下

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := protobuf-2.4.1

LOCAL_SRC_FILES := \

src/google/protobuf/io/coded_stream.cc                \

src/google/protobuf/io/printer.cc                     \

src/google/protobuf/io/gzip_stream.cc                 \

src/google/protobuf/io/tokenizer.cc                   \

src/google/protobuf/io/zero_copy_stream.cc            \

src/google/protobuf/io/zero_copy_stream_impl.cc       \

src/google/protobuf/io/zero_copy_stream_impl_lite.cc  \

src/google/protobuf/stubs/common.cc                   \

src/google/protobuf/stubs/once.cc                     \

src/google/protobuf/stubs/structurally_valid.cc       \

src/google/protobuf/stubs/strutil.cc                  \

src/google/protobuf/stubs/substitute.cc               \

src/google/protobuf/compiler/importer.cc              \

src/google/protobuf/compiler/parser.cc                \

src/google/protobuf/descriptor.cc                     \

src/google/protobuf/descriptor.pb.cc                  \

src/google/protobuf/descriptor_database.cc            \

src/google/protobuf/dynamic_message.cc                \

src/google/protobuf/extension_set.cc                  \

src/google/protobuf/extension_set_heavy.cc            \

src/google/protobuf/generated_message_reflection.cc   \

src/google/protobuf/generated_message_util.cc         \

src/google/protobuf/message.cc                        \

src/google/protobuf/message_lite.cc                   \

src/google/protobuf/reflection_ops.cc                 \

src/google/protobuf/repeated_field.cc                 \

src/google/protobuf/service.cc                        \

src/google/protobuf/text_format.cc                    \

src/google/protobuf/unknown_field_set.cc              \

src/google/protobuf/wire_format.cc                    \

src/google/protobuf/wire_format_lite.cc               \

LOCAL_C_INCLUDES := $(LOCAL_PATH) \

                    $(LOCAL_PATH)/src

include $(BUILD_STATIC_LIBRARY)

此时编译会报config.h找不到的错误, 这个文件在vsproject目录有, 但只是VC编译使用,  这篇文章说需要手动创建, 但实际上, Linux下可以通过config系统自动生成的, 但是Android平台下,不使用cygwin时, 就需要自己手动创建config.h, 内容如下

/*

    This make file is only for android ONLY, modified by Davy Xu June 17, 2013

    Cause android platform can't use linux config system when cygwin envirement is not available

*/

/* the location of <hash_set> */

#define HASH_SET_H <ext/hash_set>

#define HASH_MAP_H <ext/hash_map>

#define HASH_NAMESPACE __gnu_cxx

/* define if the compiler has hash_map */

//#define HAVE_HASH_MAP 1

/* define if the compiler has hash_set */

//#define HAVE_HASH_SET 1

#define HAVE_PTHREAD

剩下的事情就简单了, 在你的工程Android.mk里添加protobuf的引用

例如:

LOCAL_WHOLE_STATIC_LIBRARIES += protobuf-2.4.1

$(call import-module,protobuf-2.4.1)

还要在NDK_MODULE_PATH中增加搜索路径D:\Develop\ProjectName\sdk\

注意, 这里protobuf-2.4.1名称必须与sdk下的文件夹名, LOCAL_MODULE中的名称保持一致, 否则搜索不到

请注意下载对应你系统的版本, 64位系统请保证后文全系使用64位程序, 以免遇到不必要的麻烦

1.JDK&JRE       JAVA运行时及开发包

2.ADT               是Eclipse的一个插件，这一步是为了管理安卓开发库

http://developer.android.com/sdk/index.html

作为新手, 请下载ADT Bundle For Windows, 这个版本已经包含

ADK（安卓开发包）, CDT（Eclipse的C/C++开发插件）及对应的Eclipse, 可以避免第一次部署出现的各种烦心!

3.NDK              只有ADT已经可以运行普通的Andriod程序，但是如果需要编译C/C++程序， 还需要NDK

http://developer.android.com/tools/sdk/ndk/index.html

4. cocos2dx 2.0.4版本

准备SDK API

下载好ADT后解压， 有如下目录

eclipse\      <- 开发环境

sdk\           <- Andriod SDK

SDK Manager.exe     <-- Android开发包管理器, 由于Andriod版本较多, 所以此管理器可以方便开发者选择部署目标机器

打开SDK Manager在Android 2.2(API 8)里的 SDK Platform, Google APIs前打勾, 点击右下角的Instal packages

如果感觉下载速度慢, 可以移步这里http://my.oschina.net/heguangdong/blog/17443, 选择Andriod离线下载

这里是下载链接

http://dl-ssl.google.com/android/repository/google_apis-8_r02.zip

http://dl-ssl.google.com/android/repository/android-2.2_r02-windows.zip

https://dl-ssl.google.com/android/repository/usb_driver_r04-windows.zip

把android开头的文件解压到platforms目录下

把goole_apis开头的文件解压到add-ons目录下

把usb_driver_r03-windows.zip解压到usb_driver目录下。

Eclipse导入工程

打开Eclipse

导入Cocos2dx例子工程:

Eclipse中File->New->Other...选择Andriod Project from Existing Code

在Import Projects的Root Directory中导入D:\Develop\RevWar\sdk\cocos2d-2.0-x-2.0.4\samples\HelloCpp\proj.android\

注意, 不要选中 Copy project into workspace, 否则路径编乱很难编译成功

导入cocos2dx的java框架

在src目录中new package, 输入org.cocos2dx.lib, 在org.cocos2dx.lib的package中点Import-> FileSystem

选中目录D:\Develop\RevWar\sdk\cocos2d-2.0-x-2.0.4\cocos2dx\platform\android\java\src\org\cocos2dx\lib\, 点选所有java文件

工程Properties->Builder->New->Program

在Main标签中填写

填写NDK编译命令行 D:\Develop\android-ndk-r8e\ndk-build.cmd

点击Browser Workspace选中当前工程,出现${workspace_loc:/HelloCpp}

切换到Environment标签中填写

新建NDK_MODULE_PATH 填写D:\Develop\RevWar\sdk\cocos2d-2.0-x-2.0.4\;D:\Develop\RevWar\sdk\cocos2d-2.0-x-2.0.4\cocos2dx\platform\third_party\android\prebuilt\

修改cocos2dx的Android.mk, diff如下

@@ -153,6 +153,7 @@

LOCAL_WHOLE_STATIC_LIBRARIES += cocos_jpeg_static

LOCAL_WHOLE_STATIC_LIBRARIES += cocos_libxml2_static

LOCAL_WHOLE_STATIC_LIBRARIES += cocos_libtiff_static

+LOCAL_WHOLE_STATIC_LIBRARIES += cocosdenshion_static

# define the macro to compile through support/zip_support/ioapi.c              

LOCAL_CFLAGS := -DUSE_FILE32API

@@ -164,3 +165,4 @@

$(call import-module,libpng)

$(call import-module,libxml2)

$(call import-module,libtiff)

+$(call import-module,CocosDenshion/android)

F&Q

andriod-8问题

修改D:\Develop\RevWar\sdk\cocos2d-2.0-x-2.0.4cocos2dx\platform\android\java\project.properties中的target=android-8改成你需要的版本

resources.ap_ does not exist

assert目录中有资源出问题, 排查即可

例如: cocos2d-2.0-x-2.0.4\samples\TestCpp\proj.android\assets\Images\*.pvr.gz

启动Android模拟器时的Failed to allocate memory: 8问题

调整内存值,请求内存太大导致

api版本过低导致JAVA Symbol未定义问题

setEGLContextClientVersion undefined

api8(andriod 2.2)后的版本, 才支持openGL es 2.0

自己做工程遇到的问题D:\Develop\RevWar\sdk\cocos2d-2.0-x-2.0.4\/cocos2dx/platform/android/jni/JniHelper.h:28:18: fatal error: string: No such file or directory

将cocos2dx例子中的Application.mk拷过来, 修改下内部名称即可

调试请尽量使用真机, 模拟器速度很慢

请执行每次Clean, Build project, Debug.  真机上在需要时, 会弹出安装...

Android启动日志

带有ADT的Eclipse中有一个logcat窗口, 里面有系统及程序本身的日志, 可以做过滤,方便检查问题. 如需自己打日志, 可以使用cocos2dx中的LOGD宏来做, 原型是__android_log_print(ANDROID_LOG_DEBUG,LOG_TAG,__VA_ARGS__)

Remark

添加assert后, F5刷新后再编译
NDK build时,默认从工程的jni目录开始

Andriod.mk的import 原则$(call import-module,模块名) 这里的模块名必须与目录名, 模块make file中的名称报纸一致

参考文章

http://www.cnblogs.com/ybgame/archive/2012/06/07/2540693.html

发文时, Andriod Studio已经发布了一段时间, 虽然是测试版, 但将代表未来更方便的Andriod发布工具

编译python版的protobuf模块

在https://code.google.com/p/protobuf/downloads/list 下载官方的原生版本protobuf, 这里发文时使用的是2.4.1版本

编译出protoc执行文件, 放一份在protobuf-2.4.1\src\下

下载python2.7版本, 在protobuf-2.4.1\python下运行python setup.py install(如果找不到python请给python绝对路径)

这一步, python会下一个蛋( 真的是一个python的egg文件 ), 然后编译出python版本的protobuf模块放置在python下

制作protoc-gen-lua的批处理

放一份protoc在protoc-gen-lua的plugin目录

编写批处理:protoc-gen-lua.bat

@python "%~dp0protoc-gen-lua"

协议目录生成脚本

在你需要放置协议的目录编写如下批处理

buildproto.bat

rd /S /Q .\%1%
"..\..\src\protoc-gen-lua\plugin\protoc.exe" --plugin=protoc-gen-lua="..\..\src\protoc-gen-lua\plugin\protoc-gen-lua.bat" --lua_out=. %1%.proto

注意protoc.exe及protoc-gen-lua.bat的路径符合你的路径

再编写要编译的proto协议的批处理generate.bat

call buildproto.bat loginsvc

执行generate.bat后, 将会编译同目录下的loginsvc.proto,输出loginsvc_pb.lua

编译链接lua的pb库

将protoc-gen-lua\protobuf\目录拷贝到之前的协议目录

将其下的pb.c链入你的工程, 注意VS2010的VC下需要修改源码

1.将 #include <endian.h>修改为

#ifndef _WIN32
     #include <endian.h>
     #endif

避免在windows下缺失文件报错.

2. 调整struct_unpack函数前几行为

static int struct_unpack(lua_State *L)
{
    uint8_t format = luaL_checkinteger(L, 1);
    size_t len;
    const uint8_t* buffer = (uint8_t*)luaL_checklstring(L, 2, &len);
    size_t pos = luaL_checkinteger(L, 3);
    uint8_t out[8];   

    buffer += pos;

避免VS2010的VC编译器过于标准, 严格要求C风格函数变量前置声明

在lua_State声明后添加如下代码

extern "C" { int luaopen_pb (lua_State *L);}   // 注意防在命名空间外的全局声明

    luaopen_pb( L );   // 直接注入全局pb, 避免动态加载pb.dll造成的一系列跨平台问题

lua中使用pb

local loginsvc_pb = require “loginsvc_pb”

local REQ = loginsvc_pb.CheckVersionREQ()

local Data = REQ:SerializeToString( )

local ACK = loginsvc_pb.CheckVersionACK()

ACK:ParseFromString( Data )

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

我的工程目录

script\
        protobuf\
            buildproto.bat
            generate.bat
            loginsvc_pb.lua
            loginsvc.proto
        Main.lua
    src\
        protoc-gen-lua\
            example\
            plugin\
            protobuf\

在编写本文前, 笔者使用过诸如libunwind等库进行错误时堆栈打印, 但是其本身由于需要引用第三方库, 使用还是稍微麻烦.

经过Google后, 居然找到一篇好文, 其通过捕获SIGSEGV信号, 并迫使程序进入gdb调试阶段, 利用gdb强大的调试功能可以进行各种错误跟踪, 此法已与Windows下程序崩溃后弹出VC调试几乎接近.

我在此文基础上, 扩展了其通用性及便利性

1. 使用gdb的 -ex参数, 在挂接程序后, 执行bt指令打出程序堆栈

2. 将信息重定向到自定义的文件,在多进程都需要进行后台输出时带来更大的灵活性, 同时也解决了gdb只能在前台调试的问题

代码如下

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>

void dump(int signo)
{
        char buf[1024];
        char cmd[1024];
        FILE *fh;

        snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());
        if(!(fh = fopen(buf, "r")))
                exit(0);
        if(!fgets(buf, sizeof(buf), fh))
                exit(0);
        fclose(fh);
        if(buf[strlen(buf) - 1] == '/n')
                buf[strlen(buf) - 1] = '/0';
        snprintf(cmd, sizeof(cmd), "gdb %s %d -ex=bt > ./a.txt", buf, getpid());
        system(cmd);

        exit(0);
}

在服务器开启时,添加 signal(SIGSEGV, &dump ); 进行信号处理挂接即可

引用: http://blog.csdn.net/kakaka2011/article/details/6597857  作者: kakaka2011

”After a successful async_read_until operation, the streambuf may contain additional data beyond the delimiter. An application will typically leave that data in the streambuf for a subsequent async_read_until operation to examine.”

意思是, streambuf中并不一定是到分隔符前的所有数据, 多余的数据可能一样会在streambuf中. 也就是说, 还需要自己再次处理一遍数据...

动手呗, async_read_until看似就是一个废柴, 底层已经费了很多CPU在逐字符与分隔符的匹配上, 抛上来的数据居然还是半成品.

代码如下, 测试通过, 但是实在很费解为啥非要再做一次..

          boost::asio::streambuf* SB = SBP.get();

            // 访问缓冲
            const char* Buffs = boost::asio::buffer_cast<const char*>( SB->data() );

            uint32 DataSize = 0;
            for ( uint32 i = 0; i < SB->size(); ++i )
            {
                const char DChar = Buffs[i];

                // 这里需要自己判断字符串内容, read_until的文档里这么说的
                if ( DChar == '\0' )
                {
                    DataSize = i;
                    break;
                }
            }

            if ( DataSize > 0 )
            {
                // 取成字符串
                std::string FullText( Buffs, DataSize );
                
                // 消费
                SB->consume( DataSize );                

                mWorkService->post(
                    boost::bind(&AsioSession::NotifyReadString,
                    shared_from_this(),
                    FullText )
                    );

            }

  另外, 为了保证输入性安全, 可以在streambuf构造时加一个最大一个读取量, 超过此量会返回报错, 避免了缓冲区被撑爆的危险

在Windows环境变量中没有找到$(QTDIR)

随即在Qt的Visual Studio 插件菜单中, Qt->Qt Options-> Qt Versions

设置Default Qt/Win version为新版本

选中原有的Qt工程, 在插件菜单中找到Qt Project Settings->Properties->Version中,将版本设置为最新版本

如果装有Visual AssitX, 此时这东西应该开始Parse新的Qt库了

have fun !

最近遇到DB服务器中报出一个MySQL的错误:Commands out of sync; you can't run this command now,2014

查阅很多代码, 解决方法都是使用C接口的方式, 模仿其解决方法,在MySQL++中找到了比较好的解决方案:

方案A: 清空每次未使用的记录

for (int i = 1; DataQuery.more_results(); ++i)
{
   DataQuery.store_next();                
}

其中 DataQuery类型为mysqlpp::Query

方案B: 对于存储过程中,使用了多个select语句返回同样的列结果, 就需要使用以下语句

static void print_multiple_results(Query& query)

{

    // 执行查询并输出结果表

 StoreQueryResult res = query.store();

 print_result(res, 0);

 for (int i = 1; query.more_results(); ++i) {

  res = query.store_next();

  print_result(res, i);

 }

}

参考文章:http://hi.baidu.com/freeknight/item/ea9fd88e7d291f854514cf43

Lisp之魅

长久以来，Lisp一直被许多人视为史上最非凡的编程语言。它不仅在50多年前诞生的时候带来了诸多革命性的创新并极大地影响了后来编程语言的发展，即使在一大批现代语言不断涌现的今天，Lisp的诸多特性仍然未被超越。当各式各样的编程语言摆在面前，我们可以从运行效率、学习曲线、社区活跃度、厂商支持等多种不同的角度进行评判和选择，但我特别看中的一点在于语言能否有效地表达编程者的设计思想。学习C意味着学习如何用过程来表达设计思想，学习Java意味着学习如何用对象来表达设计思想，而虽然Lisp与函数式编程有很大的关系，但学习Lisp绝不仅仅是学习如何用函数表达设计思想。实际上，函数式编程并非Lisp的本质，在已经掌握了lambda、高阶函数、闭包、惰性求值等函数式编程概念之后，学习Lisp仍然大大加深了我对编程的理解。学习Lisp所收获的是如何“自由地”表达你的思想，这正是Lisp最大的魅力所在，也是这门古老的语言仍然具有很强的生命力的根本原因。

Lisp之源

Lisp意为表处理(List Processing)，源自设计者John McCarthy于1960年发表的一篇论文《符号表达式的递归函数及其机器计算》。McCarthy在这篇论文中向我们展示了用一种简单的数据结构S表达式(S-expression)来表示代码和数据，并在此基础上构建一种完整的语言。Lisp语言形式简单、内涵深刻，Paul Graham在《Lisp之根源》中将其对编程的贡献与欧几里德对几何的贡献相提并论。

Lisp之形

然而，与数学世界中简单易懂的欧氏几何形成鲜明对比，程序世界中的Lisp却一直是一种古老而又神秘的存在，真正理解其精妙的人还是少数。从表面上看，Lisp最明显的特征是它“古怪”的S表达式语法。S表达式是一个原子(atom)，或者若干S表达式组成的列表(list)，表达式之间用空格分开，放入一对括号中。“列表“这个术语可能会容易让人联想到数据结构中的链表之类的线形结构，实际上，Lisp的列表是一种可嵌套的树形结构。下面是一些S表达式的例子:

foo

()

(a b (c d) e)

(+ (* 2 3) 5)

(defun factorial (N)
    (if (= N 1)
        1
        (* N (factorial (- N 1)))
    )
)

据说，这个古怪的S表达式是McCarthy在发明Lisp时候所采用的一种临时语法，他实际上是准备为Lisp加上一种被称为M表达式(M-expression)的语法，然后再把M表达式编译为S表达式。用一个通俗的类比，S表达式相当于是JVM的字节码，而M表达式相当于Java语言，但是后来Lisp的使用者都熟悉并喜欢上了直接用S表达式编写程序，并且他们发现S表达式有许多独特的优点，所以M表达式的引入也就被无限期延迟了。

许多Lisp的入门文章都比较强调Lisp的函数式特性，而我认为这是一种误导。真正的Lisp之门不在函数式编程，而在S表达式本身，Lisp最大的奥秘就藏在S表达式后面。S表达式是Lisp的语法基础，语法是语义的载体，形式是实质的寄托。“S表达式”是程序的一种形，正如“七言”是诗的一种形，“微博”是信息的一种形。正是形的不同，让微博与博客有了质的差异，同样的道理，正是S表达式让Lisp与C、Java、SQL等语言有了天壤之别。

Lisp之道

一门语言能否有效地表达编程者的设计思想取决于其抽象机制的语义表达能力。根据抽象机制的不同，语言的抽象机制形成了面向过程、面向对象、函数式、并发式等不同的范式。当你采用某一种语言，基本上就表示你已经“面向XXX“了，你的思维方式和解决问题的手段就会依赖于语言所提供的抽象方式。比如，采用Java语言通常意味着采用面向对象分析设计；采用Erlang通常意味着按Actor模型对并发任务进行建模。

有经验的程序员都知道，无论是面向XXX编程，程序设计都有一条“抽象原则“：What与How解耦。但是，普通语言的问题就在于表达What的手段非常有限，无非是过程、类、接口、函数等几种方式，而诸多领域问题是无法直接抽象为函数或接口的。比如，你完全可以在C语言中定义若干函数来做到make file所做的事情，但C代码很难像make file那样声明式地体现出target、depends等语义，它们只会作为实现细节被淹没在一个个的C函数之中。采用OOP或是FP等其它范式也会遇到同样的困难，也就是说make file语言所代表的抽象维度与面向过程、OOP以及FP的抽象维度是正交的，使得各种范式无法直接表达出make file的语义。这就是普通语言的“刚性”特征，它要求我们必须以语言的抽象维度去分析和解决问题，把问题映射到语言的基本语法和语义。

更进一步，如果仔细探究这种刚性的根源，我们会发现正是由于普通语言语法和语义的紧耦合造成了这种刚性。比如，C语言中printf(“hello %s”, name)符合函数调用语法，它表达了函数调用语义，除此之外别无他义；Java中interface IRunnable { … }符合接口定义语法，它表达了接口定义语义，除此之外别无他义。如果你认为“语法和语义紧耦合“是理所当然的，看不出这有什么问题，那么理解Lisp就会让你对此产生更深的认识。

当你看到Lisp的(f a (b c))的时候，你会想到什么？会不会马上联想到函数求值或是宏扩展？就像在C语言里看到gcd(10, 15)马上想到函数调用，或者在Java里看到class A马上想到类定义一样。如果真是这样，那它就是你理解Lisp的一道障碍，因为你已经习惯了顺着语言去思考，总是在想这一句话机器怎么解释执行？那一句话又对应语言的哪个特性？理解Lisp要反过来，让语言顺着你，Lisp的(f a (b c))可以是任何语义，完全由你来定，它可以是函数定义、类定义、数据库查询、文件依赖关系，异步任务的执行关系，业务规则 …

下面我准备先通过几个具体的例子逐步展示Lisp的本质。需要说明的是，由于Lisp的S表达式和XML的语法形式都是一种树形结构，在语义表达方面二者并无本质的差别。所以，为了理解方便，下面我暂且用多数人更为熟悉的XML来写代码，请记住我们可以很轻易地把XML代码和Lisp代码相互转换。

首先，我们可以轻易地用XML来定义一个求两个数最大公约数的函数：

    <func name='gcd' return_type='int'>
        <params>
            <a type='int'/>
            <b type='int'/>
        </params>
        <body>
            <if>
               <equals>
                   <a/>
                   <int>0</int>
               </equals>
            </if>
            <then>
                <return><b/></return>
            </then>
            <else>
                <return>
                    <gcd>
                        <modulo><b/><a/></modulo>
                        <a/>
                    </gcd>
                </return>
            </else>
        </body>
    </func>

其次，我们可以用它来定义类：

    <class name="Computer">
        <field access="private" type="MainBoard" name="main-board" />
        <field access="private" type="CPU" name="cpu" />
        <field access="private" type="Memory" name="memory" />

        <method access="public" return_type="boolean" name="powerOn" />
            <params>...</params>
            <body>...</body>
        </method>

        <method access="public" return_type="boolean" name="powerOff" />
            <params>...</params>
            <body>...</body>
        </method>
    </class>

还可以轻易地用它来编写关系查询：

<sql>
    <select>
        <column name="employees.id" />
        <column name="bonus.amount" />
    </select>
    <from>
        <table name="employees" />
        <table name="bonus" />
    </from>
    <where>
        <equals>
            <column name="employees.id" />
            <column name="bonus.employee_id" />
        </equals>
    </where>
</sql>

还可以用它来实现类似make file的自动化构建(语法取自ant)：

    <project name="MyProject" default="dist" basedir=".">
        <property name="src" location="src"/>
        <property name="build" location="build"/>
        <property name="dist"  location="dist"/>

        <target name="init">
            <mkdir dir="${build}"/>
        </target>

        <target name="compile" depends="init" description="compile the source " >
            <javac srcdir="${src}" destdir="${build}"/>
        </target>

        <target name="dist" depends="compile" description="generate the distribution" >
            <mkdir dir="${dist}/lib"/>
            <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
        </target>

        <target name="clean" description="clean up" >
            <delete dir="${build}"/>
            <delete dir="${dist}"/>
        </target>
    </project>

一口气举了这么多个例子，目的在于用XML这种树形结构来说明Lisp的S表达式所能够描述的语义。不知道你是否发现了S表达式和XML这种树形语法在语义构造方面有着特别的“柔性”？我们可以轻易地用它构造出函数、变量、条件判断语义；类、属性、方法语义；可以轻易地构造出关系模型的select、where语义；可以轻易地构造出make的target、depends语义，等等数不清的语义。在普通语言里，你可以定义一个函数、一个类，但你无法为C语言增加匿名函数特性，也没法给Java语言加上RAII语义，甚至连自己创造一个foreach循环都不行，而自定义语义意味着在Lisp之上你创造了一门语言！不管是面向过程，面向对象，函数式，还是关系模型，在Lisp里统统都变成了一种DSL，而Lisp本身也就成了一种定义语言的语言，即元语言(Meta Language)。

Lisp的柔性与S表达式有着密切的关系。Lisp并不限制你用S表达式来表达什么语义，同样的S表达式语法可以表达各种不同领域的语义，这就是语法和语义解耦。如果说普通语言的刚性源于“语法和语义紧耦合”，那么Lisp的柔性正是源于“语法和语义解耦”！“语法和语义解耦”使得Lisp可以随意地构造各种领域的DSL，而不强制用某一种范式或是领域视角去分析和解决问题。本质上，Lisp编程是一种超越了普通编程范式的范式，这就是Lisp之道：面向语言编程(LOP, Language Oriented Programming)。Wikipedia上是这样描述LOP的：

Language oriented programming (LOP) is a style of computer programming in which, rather than solving problems in general-purpose programming languages, the programmer creates one or more domain-specific languages for the problem first, and solves the problem in those languages … The concept of Language Oriented Programming takes the approach to capture requirements in the user’s terms, and then to try to create an implementation language as isomorphic as possible to the user’s descriptions, so that the mapping between requirements and implementation is as direct as possible.

LOP范式的基本思想是从问题出发，先创建一门描述领域模型的DSL，再用DSL去解决问题，它具有高度的声明性和抽象性。SQL、make file、CSS等DSL都可以被认为是LOP的具体实例，下面我们再通过两个常见的例子来理解LOP的优势。

例1：在股票交易系统中，交易协议定义若干二进制的消息格式，交易所和客户端需要对消息进行编码和解码。

消息格式是一种抽象的规范，本身不对语言做任何的限制，你可以用C，C++，Java，或者Python。普通的实现方式是按照消息格式规范，在相应的语言中定义消息结构，并编写相应的编解码函数。假设为一个消息定义结构和实现编解码函数的工作量为M，不同消息类型的数量为N，这种方式的工作量大致为M*N。也就是说每增加一种消息类型，就需要为该消息定义结构，实现编解码函数，引入bug的可能性当然也和M*N成正比。如果仔细观察不难发现，各个消息结构其实是高度类似的，编解码函数也大同小异，但是普通语言却找不到一种抽象机制能表达这种共性，比如，我们无法通过面向对象的方法定义一个基类把消息结构的共性抽象出来，然后让具体的消息去继承它，达到复用的目的。这正是由于普通语言的抽象维度限制所致，在普通语言中，你只能从函数、接口等维度对事物进行抽象，而恰好消息格式共性所在的维度与这些抽象维度并不匹配。

其实，不同消息类型的共性在于它们都具有相同的领域语义，比如：“某字段内容是另一个字段内容的md5码”就是一种消息格式的领域语义，这种领域语义是OOP的抽象机制无法描述的。LOP的思路是先创建一门消息定义DSL，比如，类似Google的Protocol Buffer，Android的AIDL。然后，通过DSL编写消息定义文件，直接声明式地描述消息的结构特征，比如，我们可以声明式地描述“某字段内容是另一个字段内容的md5码”。我们还需要为DSL开发编译器用于生成C、Java等通用语言的消息定义和编解码函数。

有了消息定义DSL和编译器之后，由于DSL编写消息定义是一种高度声明式的编程方法，每增加一种消息的只需要多编写一个消息定义文件而已，工作量几乎可以忽略不计。所有的工作量都集中在编译器的开发上，工作量是一个常数C，与消息的数量没有关系；质量保证方面也只需要关注编译器这一点，不会因为增加新的消息类型而引入bug。

例2：在图书管理系统中，需要支持在管理界面上对书籍、学生、班级等各种实体进行管理操作。

如果按传统的三层架构，一般需要在后端程序中为每一种实体定义一个类，并定义相应的方法实现CRUD操作，与之相应的，还需要在前端页面中为每一个实体编写相应的管理页面。这些实体类的CRUD操作都是大同小异的，但细节又各不相同，虽然我们很想复用某些共同的设计实现，但OOP所提供的封装、继承、多态等抽象机制不足以有效捕获实体之间的共性，大量的代码还是必须放在子类中来完成。比如，Student和Book实体类的实现非常相似，但是如果要通过OOP的方式去抽象它们的共性，得出的结果多半是Entity这样的大而空的基类，很难起到复用的效果。

其实，不同实体之间的共性还是在于它们具有相同的领域语义，比如：实体具有属性，属性具有类型，属性具有取值范围，属性具有可读取、可编辑等访问属性，实体之间有关联关系等。LOP方法正是直接面向这种领域语义的。采用LOP方法，我们并不需要为每一个实体类单独编写CRUD方法，也不需要单独编写管理页面，只需要定义一种DSL并实现其编译器；然后，用DSL声明式地编写实体描述文件，去描述实体的属性列表，属性的类型、取值范围，属性所支持的操作，属性之间的关系和约束条件等；最后，通过这个实体描述文件自动生成后端的实体类和前端管理页面。采用LOP，不论前后端采用何种技术，Java也好，C#也好，JSP也好，ASP.NET也好，都可以自动生成它们的代码。采用LOP的工作量和质量都集中在DSL的设计和编译器的开发，与实体的数量无关，也就是说，越是庞大的系统，实体类越多越是能体现LOP的优势。

通过上面两个小例子我们可以感受到，LOP是一种面向领域的，高度声明式的编程方式，它的抽象维度与领域模型的维度完全一致。LOP能让程序员从复杂的实现细节中解脱出来，把关注点集中在问题的本质上，从而提高编程的效率和质量。

接下来的问题是如果需要为某领域设计DSL，我们是应该发明一门类似SQL这样的专用DSL呢，还是用XML或S表达式去定义DSL呢？它们各有何优缺点呢？

我认为采用XML或S表达式定义DSL的优点主要有：1) SQL、make file、CSS等专用DSL都只能面向各自的领域，而一个实际的领域问题通常是跨越多个领域的，有时我们需要将不同领域融合在一起，但是由于普通语言的刚性，多语言融合通常会是一件非常困难的事情，而XML和S表达式语法结构的单一性和“代码及数据”的特点使得跨领域融合毫无障碍。2) 在为DSL开发编译器或解释器的方面，二者难度不同。对XML和S表达式定义的DSL进行语法分析非常简单，相比之下，对SQL这样的专用DSL进行语法分析，虽然可以借助Lex、Yacc、ANTLR等代码生成工具，但总的来讲复杂度还是要明显高一些。

当然，XML和S表达式的优点也正好是其缺点，由于XML和S表达式的语法形式是固定的，不能像专用DSL那样自由地设计语法。所以，一般来讲专用DSL的语法显得更加简洁。换句话说，XML和Lisp其实是在语法和语义间做了一个交换，用语法的限制换来了语义的灵活。

Lisp之器

接下来我们继续探讨DSL的解释执行问题。DSL代码的解释执行一般分为3种典型的方式：1) 通过专门的解释器解释执行；2) 编译生成其他语言的代码，再通过其他语言的解释器解释执行(或编译运行)；3) 自解释。比如，第1类的代表是SQL，上一节举的两个例子都属于第2类，而第3类自解释正是Lisp的特色。

为了理解自解释，我们可以先从内部DSL的解释执行说起。内部DSL是指嵌入在宿主语言中的DSL，比如，Google Test单元测试框架定义了一套基于流畅接口(Fluent Interface)的C++单元测试DSL。从语义构造的角度看，内部DSL直接借用宿主语言的语法定义了自己的领域语义，是一种语法和语义解耦；从解释执行的角度看，内部DSL是随宿主语言的解释器而自动解释的，不需要像外部DSL一样开发专门的解释器，因而实现的代价很低。当然，并不是说设计内部DSL不用关心任何的解释实现，实际上，还是需要熟悉宿主语言的特性，并利用该特性使得DSL能随着宿主语言的解释器得到解释执行。

Lisp拥有强大的自解释特性，这得益于独一无二的Lisp之器：宏 (macro)。宏使得Lisp编写的DSL可以被Lisp解释器直接解释执行，这在原理上与内部DSL是相通的，只是内部DSL一般是利用宿主语言的链式调用等特性，通常形式简陋，功能有限，而Lisp的宏则要强大和灵活得多。

C语言中也有宏的概念，不过Lisp的宏与C语言的宏完全不同，C语言的宏是简单的字符串替换。比如，下面的宏定义：

#define square(x) (x*x)

square(1+1)的期望结果是4，而实际上它会被替换成(1+1*1+1)，结果是3。这个例子说明，C语言的宏只在预编译阶段进行简单的字符串替换，对程序语法结构缺乏理解，非常脆弱。Lisp的宏不是简单的字符串替换，而是一套完整的代码生成系统，它是在语法解析的基础上把Lisp代码从一种形式转换为另一种形式，本质上起到了普通语言编译器的作用。不同的是，普通编译器是把一种语言的代码转换为另一种语言的代码，比如，Java编译器把Java代码转换成Java字节码；而Lisp宏的输入和输出都是S表达式，它本质上是把一种DSL转换为另一种DSL。下面的例子是宏的一个典型用法。

例3：假设Lisp解释器已经具备解释执行面向过程DSL的能力，需要实现类似ant的自动化构建工具。

我们可以基于宏构建一门类ant的DSL，宏的作用是把类ant DSL通过宏展开变成面向过程的DSL，最后被Lisp解释器所解释执行。这样用Lisp编写的ant DSL就不需要被编译为其他语言，也不需要像XML的ant一样依赖于专门的解释器了。

当然，和开发专门的解释器/编译器相比，Lisp的宏也并非没有缺点，宏难以理解，开发和调试更加困难。到底是开发专门的解释器/编译器还是直接采用宏应该视具体情况而定。

总结

Lisp采用单一的S表达式语法表达不同的语义，实现了语法和语义解耦。这使得Lisp具有强大的语义构造能力，擅长于构造DSL实现面向语言编程，而宏使得Lisp具有自解释能力，让不同DSL之间的转换游刃有余。进入Lisp的世界应当从理解面向语言编程入门，这是Lisp之道，而函数式编程和宏皆为Lisp之器，以道驭器方为正途。

后记

本文是我学习Lisp的一个总结，也是写给有兴趣学习Lisp的程序员的入门资料。必须说明，我还是一个标准的Lisp初学者，几乎没有写过像样的Lisp程序，文中的错误和不足在所难免，希望读者批评指正，感谢！

参考

The Roots of Lisp

The Nature of Lisp

Why Lisp macros are cool, a Perl perspective

Wikipedia: Language-oriented programming

《实用Common Lisp编程》

《冒号课堂 – 编程范式与OOP思想》

在包含中添加#include <memory>即可

mysql++版本3.1.0

进入mysql++目录,执行以下指令生成libmysqlpp.a

ar rcu libmysqlpp.a mysqlpp_beemutex.o mysqlpp_cmdline.o mysqlpp_connection.o mysqlpp_cpool.o mysqlpp_datetime.o mysqlpp_dbdriver.o mysqlpp_field_names.o mysqlpp_field_types.o mysqlpp_manip.o mysqlpp_myset.o mysqlpp_mysql++.o mysqlpp_mystring.o mysqlpp_null.o mysqlpp_options.o mysqlpp_qparms.o mysqlpp_query.o mysqlpp_result.o mysqlpp_row.o mysqlpp_scopedconnection.o mysqlpp_sql_buffer.o mysqlpp_sqlstream.o mysqlpp_ssqls2.o mysqlpp_stadapter.o mysqlpp_tcp_connection.o mysqlpp_transaction.o mysqlpp_type_info.o mysqlpp_uds_connection.o mysqlpp_utility.o mysqlpp_vallist.o mysqlpp_wnp_connection.o ssqls2parse_parsev2.o

然后mv到usr/local/lib,重新链接服务器即可

[root@localhost bin]# ldd wkcenter
./wkcenter: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./wkcenter)
./wkcenter: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./wkcenter)
./wkcenter: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./wkcenter)
./wkcenter: /lib/libc.so.6: version `GLIBC_2.9' not found (required by ./wkcenter)
./wkcenter: /lib/libc.so.6: version `GLIBC_2.7' not found (required by ./wkcenter)
./wkcenter: /lib/libc.so.6: version `GLIBC_2.8' not found (required by ./wkcenter)
./wkcenter: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./wkcenter)
        linux-gate.so.1 =>  (0xffffe000)
        liblog4cpp.so.4 => not found
        libprotobuf.so.7 => not found
        libboost_filesystem.so.1.48.0 => not found
        libboost_system.so.1.48.0 => not found
        libboost_thread.so.1.48.0 => not found
        libboost_program_options.so.1.48.0 => not found
        libunwind-x86.so.7 => not found
        libluabind.so.0.9.0 => not found
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x008ae000)
        libm.so.6 => /lib/libm.so.6 (0x0044b000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00476000)
        libc.so.6 => /lib/libc.so.6 (0x002c1000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x0041d000)
        librt.so.1 => /lib/librt.so.1 (0x00440000)
        /lib/ld-linux.so.2 (0x002a2000)

上面红字部分表示glibc及glibcxx库依赖不正确. 本人使用的Linux编译版本为Mint 11(基于Ubuntu), 一般Ubuntu发行版的glibc配备非常高. 但是上文中的发布的Linux版本为CentOS 5.8

使用/lib/libc.so.6 查看libc版本为2.5, 远远低于开发环境的2.11

GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-51).
Compiled on a Linux 2.6.9 system on 2012-02-21.
Available extensions:
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        GNU libio by Per Bothner
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

由于Linux操作系统的特有elf加载顺序. (可以参考此文). 虽然可以很大程度上解决Windows早期版本的dll hell问题, 但是给部署带来了很大难度

一般常见的解决方法是, 找到一个与目标Linux版本及glibc版本一致的Linux, 将代码及依赖包放在之上编译, 完成后再发布.这种方法与Linux下常见软件安装方法类似. 但是对于商用服务器部署步骤来说未免繁琐, 安全性低.

还有一种方法,使用静态链接. 将所有可执行文件文件依赖的静态库, 系统库,全部静态链接到可执行文件中,可以一次性解决这个问题

步骤:

    1. 在gcc链接命令行中添加-static -static-libgcc -static-libstdc++

    2. 将第三方依赖库打开静态链接开关, 将原来链接.so的库,全改为链接.a

    3. gcc对链接库顺序很敏感, 链接库顺序需要按照从前至后为:  项目产生的静态库 > 第三方库静态库 > 系统静态库

    4. 链接时, 若有未解决的symbol, 可以尝试在最后添加-lpthread及-lrt解决

在发布版本Linux上运行可能遇到的问题:

terminate called after throwing an instance of 'std::runtime_error'

what(): locale::facet::_S_create_c_locale name not valid

解决方法: 执行之前运行export LC_ALL="C"

另外一种获取方法是table.getn(obj), 但是这个方法已经标记为废除了, 尽量使用通用且简洁的#操作符

使用lua api实现此功能就需要用到lua_objlen( ),但是这个功能未在luabind中提供.所以我们顺手添加一个

首先找到luabind源码的object.hpp中取对象类型的type函数,在其下添加以下代码

  1: template<class ValueWrapper>
  2: inline int obj_size(ValueWrapper const& value)
  3: {
  4:     lua_State* interpreter = value_wrapper_traits<ValueWrapper>::interpreter(
  5:         value
  6:         );
  7: 
  8:     value_wrapper_traits<ValueWrapper>::unwrap(interpreter, value);
  9:     detail::stack_pop pop(interpreter, 1);
 10:     return lua_objlen(interpreter, -1);
 11: }
 

   1: void ScriptManagedChannel::OnServiceInitialize()

   2: {    

   3:     try

   4:     {        

   5:         mThread = lua_newthread( GScriptScriptContext->GetVM() );

   6:  

   7:         luabind::resume_function<void>( mThread, "ScriptMain", this );

   8:  

   9:         Resume();

  10:     }

  11:     catch (std::exception& e)

  12:     {

  13:         const char* ErrorMsg = lua_tostring( GScriptScriptContext->GetVM(), -1 );            

  14:         printf("%s\n", e.what() );

  15:     }

  16:  

  17:     

  18: }

  19:  

  20: void ScriptManagedChannel::Resume( )

  21: {

  22:     luabind::resume<void>( mThread );

  23: }

  24:  

  25: void ScriptManagedChannel::StopTest( )

  26: {

  27:     lua_yield( mThread, 0 );

  28: }

  29:  

  30:  

代码中, mThread类型为lua_State*类型

GScriptScriptContext->GetVM()是加载了代码的lua_State*

StopTest为注册为ScriptManagedChannel类成员函数到lua中的定义

接下来看lua端的测试代码:

   1: function ScriptMain( Channel )

   2:  

   3:     

   4:     for i = 1, 5 do

   5:     

   6:     print("done", i)

   7:     

   8:     Channel:StopTest( )

   9:     

  10:     

  11:     

  12:     end

  13: end

刚开始,在测试代码时, lua中有个手误而造成的错误, 导致C++代码运行到第7行时弹出assert

位于:luabind-0.9.1\luabind\detail\call_function.hpp 第264行,对应以下代码第13行

   1: ~proxy_function_void_caller()

   2: {

   3:     if (m_called) return;

   4:  

   5:     m_called = true;

   6:     lua_State* L = m_state;

   7:  

   8:     int top = lua_gettop(L);

   9:  

  10:     push_args_from_tuple<1>::apply(L, m_args);

  11:     if (m_fun(L, boost::tuples::length<Tuple>::value, 0))

  12:     {

  13:         assert(lua_gettop(L) == top - m_params + 1);

  14:  

  15: NO_EXCEPTIONS

  16:         throw luabind::error(L);

  17: #else

  18:         error_callback_fun e = get_error_callback();

  19:         if (e) e(L);

  20:     

  21:         assert(0 && "the lua function threw an error and exceptions are disabled."

  22:                 " If you want to handle the error you can use luabind::set_error_callback()");

  23:         std::terminate();

  24: #endif

  25:     }

  26:     // pops the return values from the function call

  27:     stack_pop pop(L, lua_gettop(L) - top + m_params);

  28: }

11行代码中调用的是lua_resume, 返回的是运行错误, 但是被13行的assert挡住了, 无法通过第16行抛出异常被外面捕获.

因此,尝试注释第13行, 再测试, 可以在lua抛出错误后, 在栈顶捕获到coroutine函数resume时报出的错误信息.问题解决

对于lua的coroutine, 网上资料不多, 这里有一篇比较详细的代码

我比较疑惑的是, 有没有必要将代码在dofile或者dobuffer时, 必须传入newthread出的state? 如果还是传入原始的state会有什么影响?

欢迎各位有此经验的讨论