终于有了间茅草棚

——我走时,会否有随风飘散的痕迹?

外面的风好大,雨也淅淅沥沥的。

世间种种的诱惑不惊不扰我清梦,山高路远不绝我追踪你绝美的笑容,登高一呼时才懂始终在为你心痛,俯首对花影摇动都是东风在捉弄

世间种种的迷惑都是因你而猜错,水光月光又交融描述这朗朗的夜空,生死到头的相从似狂花落叶般从容,当一切泯灭如梦就在远山被绝
随笔 - 42, 文章 - 2, 评论 - 269, 引用 - 3

导航

<2009年7月>
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

留言簿(10)

随笔档案

文章档案

收藏夹

其它的我

友情连接

网页连接

搜索

最新评论

  • 1. re: 陈刚
  • 中间件主要的好处在于便于整合,就像一个接口规范和标准。像游戏开发中3D图形技术有两套,有的游戏直接基于D3D或OenGL开发,现在更多的是基于一些图形引擎,像Ogre,Irrlicht等,在这些图形引擎下面去和具体的图形API打交道,从这个意义上来说Ogre和Irrlicht拥有一定的中间件的涵义(这些图形引擎不只是中间层,还包含有场景管理、渲染逻辑等更多内容)。加了这样一层后,当支持新的D3D10和D3D11时,中间层作出修改,原应用不需要修改就可运行,还有移植到支持OpenGLES的设备时,也是可行的。
  • --清风雨
  • 2. re: linux常见开发问题,.JPEG parameter struct mismatch
  • 你说的3.JPEG parameter struct mismatch没看明白,我现在也遇到了同样的问题,
    ”编译libjpeg的make文件里定位输出生成jpeg的地方“指的是哪啊,
    “打印出相关参数”也不明白
    “前台运行同样的./configure”什么意思?
    帮帮我了,谢谢!我邮箱litao_hao@16.com   qq;40362095
  • --haolitao
  • 3. re: linux移植建议
  • 这个学习了
  • --陈刚
  • 4. re: 软件开发模式猜测
  • 脚本在其可配置性、可扩展性上性能应该是已经超越了中间件技术。

    中间件在对其扩展、更新、配置时不知是否能做到依赖它的程序不中断运行呢
  • --陈刚
  • 5. re: 软件开发模式猜测
  • 对 “中间件模式” 还真不太了解。 

    不知 “中间件模式” 是否会影响运行、调试以及维护成本,以及如何能抽象出中间层?
  • --陈刚
  • 6. re: void *几用
  • class Sample
    {
    public:
        void draw( void *g );
    };

    我个人其实并不太认同这种做法,虽然实现了抽象但会加大维护代价
  • --陈刚
  • 7. re: 用自己的话浅谈封装
  • 封装也是一个不断完善的过程,当然再经过一段时间后随着技术的进步思想的成熟,也会推翻重来。
  • --陈刚
  • 8. re: linux常见开发问题
  • xargs不错,蛮有用的。
  • --hATEmATH的网上田园
  • 9. re: 关于“元编程”的浅思考
  • --免费打工仔
  • 10. re: 关于质数(素数)的算法

  • 是AKS方法。
    http://mathworld.wolfram.com/AKSPrimalityTest.html


  • --perry
  • 11. re: 关于质数(素数)的算法
  • 为了在数字比较小时计算得快些,可以应用一些初等数论的结论:

    1]
    仅计算6n+1和6n+5(n=1,2,3,...)形式的数。易知6n+2和6n+4是2的倍数,6n+3是3的倍数。因为2和3的倍数最多。
    2]
    根据“合数的最大的素因数都不大于它的平方根”定理,每次分解仅算到被分解的平方根为止即可。
    证明(一般的证明都不完整):
    设N=P*Q,P和Q是N的不少于1个素因数的乘积(指出这点很重要)。反证法可证P和Q都小于或等于N的平方根(否则P*Q>N)。等号当且仅当P=Q=N的平方根时成立(这时N是一个素数的平方)。

    1]可减少2/3的计算量,2]可再减少1/2的计算量。即为原计算量的1/6。

    几百位数位的数,建议采用ASK方法。





  • --perry
  • 12. re: 关于质数(素数)的算法

  • 素因数分解是一个NP问题。
  • --perry
  • 13. re: 关于质数(素数)的算法
  • 1121=19*59
  • --李圆欢
  • 14. re: void *几用
  • 方法都不错
  • --员工生日礼物
  • 15. re: void *几用
  • to oshj:
    最近才悟道这个用法,没想到你都用了很多了。

    to brent:
    不是为了玩才玩,这里每种用法在特定的情况下,都有他相应的好处。不过,我是做为自己记录的,指不定什么时候就忘记了,还可以这么用。
    1. 可以使得头文件简单,而且出于实现保密的需要,还是很有用处的。
    2. 很多时候对象本身应该简洁,但往往应对不同的需要,通常需要数据对应。举个例子,比如玩家在哪个房间,在哪个房间最好不要直接记在玩家身上,用数据注入的方式,能够很快的获得该信息。
    3. 因为是做为库暴露头文件的,使用者并不关心void *的实际意义,而且能够加快编译速度。真正要关心时,就Graphics.h这个头文件是不够的,通常会需要了解整底层个实现,才能较好的扩充。
  • --清风雨

阅读排行榜

评论排行榜

linux移植建议

linux的移植,有很多内容可以讲,也有很多内容需要考虑,市面上也有些专门介绍的书。这里是3个月前为公司做移植时遇到的一些问题和解决,原内容是发给其他同事做共享用的,这里直接贴出来,也不做修改了。

linux移植建议

本次linux移植,由于大家前期在数据类型、平台抽象接口方面做了很多工作,相对比较顺利。下面是移植中的一些小细节和处理经验,和大家一起分享。

1.文件名大小写
在linux系统上,大小是是敏感的,file和File分别表示不同的文件;由于windows系统不区分大小写,以上两个文件指向同一文件,当包含file.h时,写成File.h也能正常编译;在linux上需要注意以上问题,大小写会导致编译失败。

2.包含路径
#include <> 表示系统路径,#include ""表示本项目路径和系统路径。由于linux上的环境开发设置相对成熟度不够,在该问题上建议大家采用以下方式:
2.1.明确的第三方库采用#include <>方式,加强代码可阅读性。通常像C/C++库,平台API库,明确的第三方如OGRE、CEGUI等属于此列。
2.2.隐性的第三方库也建议采用#include <> 或 #include ""非路径语义方式。像本平台的kylin、networkengine库,对于游戏和平台层面而言,也属于第三方概念(因为本法并不关心其实现)。
2.3.平台架构层面建议采用#include ""方式,""内不含路径语义,以示该文件为构建本体现所须之共有内容。如common/agentserver下的内容等,可采用#include "kAS_Share.h"方式。
2.4.本项目(对应VC的项目)内的文件,采用相对路径方式的#include ""方式,如#include "./ls_listener_Console.h"、#include "../inc/ls_server.h"。
以上方式并非必需,仅仅为方便代码阅读和移植方便。

3.成员初始化顺序
c++的构造起成员初始化列表初始化顺序和其定义顺序是一致的,MS的VC编译器和gcc或其它c++编译器均遵守该c++标准规范。VC编译器对于成员初始化列表的书写顺序和定义顺序不一致的情况,未予警告;但gcc对两者顺序不一致问题予以强烈警告。建议将初始化别表上成员变量初始化顺序和定义保持一致,采用默认初始化构造器进行初始化的可不在初始化列表列出,也可显示写出。该顺序整理相当耗时,而且鉴于我们成员变量较多,期望大家配合。另成员变量的定义顺序最好采用类型大小排序(由小到大或由大到小一样),该排序方案有利于减小对象大小。

4.中文注释
这个问题比较好理解,很多系统不是中文系统嘛,虽然linux对中文的支持也不存在问题,但也很容易一不小心中文就乱码了。所以,大家最好别用中文注释,虽然用了并不影响移植。

5.模板
5.1.请大家在模板的两个<、>之间加一下空格,如std::vector>改为std::vector< std::list<> >,<<和>>在c++里看起来是另一个东西嘛,虽然未来的c++标准要求编译器处理该问题,但很遗憾现在还不是标准,而且g++会直接error。
5.2.应用typename关键字。编写模板代码时,std::vector< T >::iterator i在gcc上会无法编译,改为typename std::vector< T >::iterator i。示例:
template< class T >
void temp( void )
{
typename std::vector< T >::iterator i;
}

6.文件尾空行
gcc对于文件行没有空行的,会进行警告,在编写完头文件和实现后,记得在两个文件的最好多敲入一次回车。

7.dll导出
该问题不大,通常集中在DLL_EXPORTS上,在linux上不存在导入和导出的概念,在windows上才定义该宏,否则仅仅定义该宏#define DLL_EXPORT。

8.编译器指示符和预编译头
编译器指示符,通常都为编译器所独有,如#pragma warning、#pragma comment就是ms独有等。注,#pragma once稍微例外,gcc仍然警告。国外很多的专家和强人,对MS的态度一向比较奇怪(其实,似乎网上国内也有嘛^_^),对MFC、预编译头等都是抨击和嘲弄的,所以,除了#pragma外,预编译头也不要使用,gcc不支持。

9.整形比较
整数的有符号和无符号比较时容易产生隐形bug。gcc在遇到有符号和无符号比较时会警告,在编码时,根据具体的语义,直接采用static_cast转换为对应的有符号或符号类型。

10.inline/try
不要用ms专有的__inline,需要的话,采用c++语言的inline;不要用__try用try,同时不要打开VS2005编译器的SEH异常(缺省未打开,只是为了windows上调试、并不移植时可打开)。

11.strcpy_s等
不要用vs2005以来的_s安全函数,采用原先的非安全c库函数,strcpy_s、strcat_s等函数为ms专有。

12.gcc编译器
如果大家有兴趣,也可以装一个windows上的gcc编译器MinGW。我这里下载了codeblocks+gcc的windows版本(在linux下,我现在采用的是codeblocks),用它来验证linux下的可移植性(linux的项目配置,我已经上传,cbp文件就是codeblocks的项目文件)。

13.命名建议
现在的平台引擎层面,对外的文件接口,均是以k开头,后续单词首字母大写。为迎合linux习惯小写的命名,建议文件名采用首字母小写,后续单词首字母大写。命名和移植无关,仅便于维护和阅读。

14.其它
如有疑问或建议请找我 —— 张家旺。^_^

posted on 2008-10-14 13:12 终于有了间茅草棚 阅读(1471) 评论(1)  编辑 收藏

评论

# re: linux移植建议

这个学习了
2009-07-24 23:34 | 陈刚
标题  
姓名  
主页
验证码 *
内容   
  登录  使用高级评论  Top
[使用Ctrl+Enter键可以直接提交]