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.其它
如有疑问或建议请找我 —— 张家旺。^_^
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
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.其它
如有疑问或建议请找我 —— 张家旺。^_^
评论列表
陈刚2014-4-7 15:43:00
re: linux移植建议
这个学习了
这个学习了
发表评论
- 访问:34810次
- 积分:490分
- 排名:第20名
- 随笔:49篇
- 评论:275条
随笔分类
随笔归档
个人相册
阅读排行榜
- 特定条件下,ftell返回值错误 (1755)
- linux移植建议 (1323)
- 真实的陷阱1 — 错误的宏定义 (1257)
- 自己的lzw实现 (1248)
- 关于“元编程”的浅思考 (1150)
- windows上的简单读写锁实现 (1116)
- 真实的陷阱2 — 多线程案例 (1109)
- 关于几个C字符串库函数的思考 (1051)
- 关于质数(素数)的算法 (1038)
- 贴一个头文件,恳请大家意见和想法 (996)
评论排行榜
- 有感公司一次郁闷的服务器重写 (19)
- 关于质数(素数)的算法 (16)
- 我是一个中国人,但是我却很羞愧 (16)
- 贴一个头文件,恳请大家意见和想法 (15)
- 关于几个C字符串库函数的思考 (15)
- 我犯的一个很愚蠢的错误,当时还以为没错 (13)
- 今天刚批下来,特别高兴! (13)
- 关于“元编程”的浅思考 (12)
- 经常发生的故事!请平静看待。 (12)
- 用自己的话浅谈封装 (12)
最新评论
- 自己的lzw实现
MukkAlomo:<a href=></a>. . . &nb...
- 自己的lzw实现
XertJak:10mg zolpidem tartrate can you take more than one ...
- 自己的lzw实现
Hytcem:zolpidem tartrate 10 mg price ingredien...
- 自己的lzw实现
Sadnus:where can i buy ambien ambian pill ambien hallucin...
- 自己的lzw实现
KoipSiny:10mg ambien buy astelin . ambien classi...
- 自己的lzw实现
FreaBox:ambien uses ambiencr ambien cr buy online <a hr...
- 自己的lzw实现
Merjoum:ambien where to buy sleep pill ambien ....
- 真实的陷阱2 — 多线程案例
aab:这代码,看着是有点累!
- 特定条件下,ftell返回值错误
wifecooky:re: 特定条件下,ftell返回值错误 以r+b方式打开就没问题
- 特定条件下,ftell返回值错误
清风雨:re: 周星星 在windows上我运行得到的结果也是“0,3,0,6,0,9”; 在centos...