Q金?jin)的专栏Q?/p>
gcov l计 inline 函数
Q金?jin)的专栏Q?/p>
gcov可以l计 inline 函数Q可是实际用中到l计ơ数L?的现象?/p>
假设cA的头文g?A.h, 实现文g?A.cpp.
A 有几?inline 成员函数定义?A.h 中?/p>
使用 gcov l计 A 的代码覆盖率Ӟ可能?x)发?A.h 中的 inline 成员调用ơ数为空??/p>
除了(jin)实未调用的原因Q可能是 gcov l计的对象错?jin)?/p>
"gcov A.cpp" l计的是 A.cpp 中实现的函数代码Q如?A.cpp 中未调用自n?inline 函数Q统计结果确实ؓ(f)0?/p>
只有到这?inline 的调用方 cpp 文g中去l计Q才?x)有惌的结果?/p>
例如QB.cpp 中调用了(jin) A ?inline 函数Q?gcov B.cpp" 才会(x)l计?inline 代码.
参考:(x)
另外QCMake 构徏?o文g命名不是 A.o, 而是 A.cpp.o, 所?/p>
gcov A.cpp
?x)?A.gcno 不存在?/p>
实际文g应该?A.cpp.gcno.
把它复制?A.gcno p?jin)?/p>
或者用
gcov A.cpp.gcda
不知Z么,可以直接?gcda 文g作ؓ(f)输入?/p>
或?/p>
gcov -o A.cpp.o A.cpp
q样应该是标准的调用方式?/p>
ASYNC异步输出到ROLLING和CONSOLE?/p>
另外QLua日志异步输出为每天一个的独立日志?/p>
默认仅输出INFO日志QTHServer日志c输出DEBUG日志?/p>
CONSOLE屏蔽DEBUG日志?/p>每个服务器用相cM的配|,仅输出文件名不同。可用如下Shell脚本生成各个配置文gQ?br />
我们传统的程序基本都只在Windows或只在Linux下运行,W(xu)indowsE序使用?br />中文GB18030~码QLinuxE序则只使用英文Q多q以来这些程序运行v来都没有
问题?/font>
q年来,随着E序的组件化Q部分代码特别是公用lg都需要同时支持Windows
?qing)Linuxq_Q这样就出现?jin)不同程度的~码问题Q例如在~译时编译器报错Q?br />或者在q行时出Cؕ码。这些问题都和程序选用的字W编码不正确有关?/font>
本文要地分析?jin)C++的一些字W编码问题,q提供了(jin)的方案。受l验和时
间的限制Q有些内容可能不一定全面,仅供大家参考?/font>
首先要区分几个概念:(x)
指的是C++源程序文Ӟ.cpp/.hQ本w用什么字W编码(GB18030/UTF-8{)(j)?
C++E序的内?~译后,C++中的字符串常量都?x)变成一串字节存攑֜可执行文件中。这个内
码指的就是在可执行文件中Q字W串以什么编码进行存放。这里的字符串常?br />指的是窄(jing)字符QcharQ而非宽字W(wchar_tQ。宽字符通常是以UnicodeQVC
使用UTF-16BEQgcc使用UTF-32BEQ存放?
指的是执行程序时Q操作系l或l端所使用的编码。程序中输出的字W最l要
转换行环境编码才能正显C,否则׃(x)出现q?
通常在简体中文Windows环境下,各种~辑器(包括Visual StudioQ新建文件的
~省~码都是GB18030Q所以不特别指定的话QW(xu)indows环境下C++源文件的~码
通常为GB18030?/font>
而在Linux环境下,最怋用,也是推荐使用的是UTF-8~码?/font>
一般来_(d)我们常用的简体中文版VC所使用的内码是GB18030Q而gcc/g++使用?br />内码~省是utf-8Q但可以通过-fexec-charset参数q行修改?/font>
Note |
可以通过在程序中打印字符串每个字节十六进制Ş式来判断E序所使用的内码?/font> |
我们常用的简体中文版Windows的环境编码是GB18030Q而Linux下最常用的环?br />~码是UTF-8?/font>
源程序需要由~译器编译ؓ(f)目标文gQ目标文件运行后输出信息到终端,因此q?br />几个~码之间存在一些的兌Q?/font>
~译器需要正识别源文g的编码,把源文g~译为目标文Ӟq把源文件中
的以源文件编码的字符串{换ؓ(f)以程序内码编制的字符串保存在目标文g中?
Note |
当源文g的字W编码与E序内码都是UTF-8Ӟgcc的缺省情况)(j)Qgccgq不?x)对源文件中的字W编码进行{换,而是直接把字W串原样存放到目标文 件中Q在q种情况下,源程序中的GB18030~码的字W串在输出时仍然为GB18030 ~码。但如果在其它源文g字符~码的实际g~译选项不同Ӟ?x)在~译时报无法从XXX转换到UTF-8的错Q因此还不清楚ؓ(f)什么两个编码都是UTF-8ӞGB18030 ~码的源文g能通过~译?/font> |
C++标准库需要正识别终端的q行环境~码Qƈ把程序的输出转换行环
境所使用的编码,以便正确昄?
在这q程中,如果有一个环节出现问题,׃(x)DE序的输出发生异常,产生?br />码或其它更严重的后果?/font>
Ҏ(gu) http://stackoverflow.com/questions/688760/how-to-create-a-utf-8-string-literal-in-visual-c-2008
一文中提供的资料,gcc/vc各版本对C++源文件编码有不同的处理:(x)
gcc (v4.3.2 20081105):
支持UTF-8~码的源文gQUTF-8~码的源文g不能有BOM?/font>
Ҏ(gu) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415 Q似乎gcc 4.4.0
开始支持带BOM的UTF-8文g?/font>
vc2003:
支持UTF-8~码的源文gQUTF-8~码的源文g可以有BOMQ也可以没有?/font>
vc2005+:
如果源文件用UTF-8~码的话Q?strong>必须?/strong>BOM?/font>
Note |
gcc提供?finput-charset参数可以指定源文件的字符~码Q但׃标准 头文仉是ascii~码的,因此如果要引用标准头文g的话Q源代码的编码必d容ascii。而vc未能扑ֈcM的选项?/font> |
很多文章都推荐C/C++代码中只使用ascii字符Q如果有非ascii字符可以用\xHH
或\uXXXX表示。注释中使用utf-8~码。也可以使用gettext 把非ascii字符串放到单独的语言文g中,而在源代码中只保留ascii字符?/font>
在实践中Q由于\xHH或\uXXXX{方式很不直观,Ҏ(gu)出错且不易发玎ͼ而未必所
有程序都需要支持多语言Q因此未必想引入gettext或类似的解决Ҏ(gu)。在q样
的情况下Q大安?fn)惯在源E序文g中直接写入中文等非ascii字符Q这需?br />选择一U至能被gcc和vc接受的文件编码?/font>
本来QUnicode是解军_语言问题的最好选择Q而UTF-8׃与ASCII兼容Q也?br />最通用的Unicode~码方式Q但从上面的资料中可见,如果用UTF-8的话QgccQ?br />臛_是低版本Q不允许有BOMQ而vc2005 以上要求必须有BOMQ因此同一个文?br />无法在gcc?qing)vc下通过~译QUTF-8g不是一个好的选择。但如果使用gcc比较
高的版本Q?.4.0以上Q)(j)Q用带BOM的UTF-8~码文g应该也是可行的?/font>
考虑到目前现Ӟ我们一般都在简体中文Windows下工作,源文件中使用GB18030
~码g是一个比较现实的选择。在vc下可以直接编译,而在gcc下也可以通过
增加~译选项-finput-charset=gb18030予以支持。而且Ҏ(gu)l基癄中GB18030
的词条内容,GB18030 is a superset of ASCII and can represent the whole
range of Unicode code pointsQGB18030向后兼容ASCIIQƈ且能表示所有的
Unicode码点Q,因此使用GB18030有够的表达能力Q可以表C所有的Unicode
字符。用GB18030的唯一~点是在非体中文版本的VC下,׃无法指定?br />文g的编码,因此有可能无法正识别此~码的源文g?/font>
正如前面提到的,C++有窄(jing)字符QcharQ和宽字W(wchar_tQ的分别Q分别有一
套相应的cd函数Qstring/cout/strlen与wstring/wcout/wcslen{)(j)。前者在
不同的编译器下有不同的缺省编码(体中文vc是GB18030Qgcc是UTF-8Q,?br />者一般都使用UnicodeQ其中vc下用UTF-16Qgcc~省使用UTF-32?/font>
C++在输出窄(jing)字符时会(x)按程序内码原栯出,不会(x)q行~码转换Q因此在使用H?br />字符时要求程序内码与q行环境~码一_(d)q样才不?x)出Cؕ码。由于简体中?br />版vc的程序内码是GB18030Q因此用窄(jing)字符的vcE序只能q行在GB18030环境?br />。同P׃gcc~省使用UTF-8作ؓ(f)E序内码Q因此用窄(jing)字符的gccE序只能
q行在UTF-8的终端环境下。(q里说的都是在源代码中直接写中文{非ascii?br />W的E序。用前面提到的gettext?qing)其它工P使用H字W的E序也可以在不同
~码的运行环境中正确输出中文Q?/font>
C++在输出宽字符时会(x)自动转换行环境的~码Q因此只要正设|了(jin)q行?br />境编码,同一个程序就可以在不同编码的q行环境中正显CZ文。这一点与
Java/.Net很象QJava/.Net的字W串cd都用UnicodeQ在输入/输出旉需?br />与当前运行环境的~码q行互{?/font>
一般来_(d)如果需要支持多语言Q有两种比较好的做法Q?/font>
使用H字W,但源E序中只使用ascii字符Q非ascii字符通过gettext或其?br />工具攑ֈ单独的文件中Q由gettext{工具处理编码{换的问题?
在各U编码的q行环境中均能正输Z文?
E序中不能直接出现非ascii字符Q也不能通过\uXXXX方式指定非ascii字符Q后者也?x)被~译器{换ؓ(f)非ascii字符q存攑֜目标文g中?
注释中可以用ascii兼容的编码,不媄(jing)响编译器?
有比较多的现成代码可供重用?
使用宽字W?
在各U编码的q行环境中均能正输Z文?
E序中可以用非ascii字符?
需要配合前面的源程序文件编码设|,让编译器能正识别源E序中的?br />ascii字符?
׃以前使用宽字W的E序比较?yu),可供重用的代码较(yu)?
Note |
如果E序中需要一些固定字W编码的字符串常量,例如固定是GB18030 ~码的字W串帔RQ这些常量应该以\xXX的方式存攑֭W串帔RlGB18030~码后的内容Q这L(fng)内容才不?x)被转换为程序的内码Q也不会(x)转换行环境编码?/font> |
正如上面提到的,使用H字W和使用宽字W的E序对运行环境的字符~码要求?br />不一L(fng)?/font>
使用宽字W,只要在程序中正确讄当前环境的字W编码(一般通过locale::global(locale("")) q行讄Q,C++标准库会(x)在输入、输出时?br />进行字W编码{换,因此可以适应各种~码的运行环境?/font>
使用H字W,但程序中不出现非ascii字符的话Q对q行环境没有特别要求Q?br />可以适应各种~码的运行环境?
使用H字W,E序中也直接使用汉字{非ascii字符的话Q由于C++标准库会(x)?br />目标文g中保存的字符Ԍ以程序内码保存)(j)直接输出Q不?x)进行字W编码{换,因此要求q行环境的编码与E序内码一致。即体中文VC~译的程序只能运行在GB18030环境下,gcc~译的程序只能运行在UTF-8环境下(可以在编译时通过-fexec-charset参数q行修改Q?
Ҏ(gu)上面的讨论,目前看来Q要兼容Windows/LinuxQVC/gcc的话Q有几种做法
Q?/font>
使用H字W,源程序中只用ascii字符Q非ascii字符Q如中文{通过
gettext{工h到单独的语言包中?
q种做法比较多h推荐?
兼容VC?qing)gcc各版本?
׃源程序中不出现非ascii字符Q因此不需要考虑源程序文件的~码问题?
兼容各种~码的运行环境?
使用H字W,源程序中允许使用非ascii字符?
要求q行环境的编码与E序内码一_(d)卛_支持GB18030~码的Windows?br />UTF-8~码的Linux?
Ҏ(gu)源程序用的~码不同Q对~译器的兼容性也不同Q?
使用H字W,源程序用带BOM的UTF-8~码?
兼容VC各语U的各版本?
兼容gcc 4.4.0以上版本?
使用H字W,源程序用GB18030~码?
兼容VC的简体中文各版本?
兼容gcc各版本,但在~译旉要加?finput-char=gb18030参数?
使用宽字W,源程序中允许使用非ascii字符?
兼容各种~码的运行环境?
Ҏ(gu)源程序用的~码不同Q对~译器的兼容性也不同Q?
使用H字W,源程序用带BOM的UTF-8~码?
兼容VC各语U的各版本?
兼容gcc 4.4.0以上版本?
使用H字W,源程序用GB18030~码?
兼容VC的简体中文各版本?
兼容gcc各版本,但在~译旉要加?finput-char=gb18030参数?
Ҏ(gu)我们的现Ӟ对于需要支持多语种的程序,使用H字W,源程序中只
用ascii字符?/font>
对于不需要支持多语种的程序,考虑到重用已有的代码Q可以考虑使用H字W,
采用GB18030~码Q但只能q行在GB18030~码的Windows环境?qing)UTF-8~码?br />Linux环境下?/font>
׃用户输入、输出及(qing)从文件、网l等设施d的数据在E序底层看来都是字节
,因此存在在输入时如何把这些字节流解释成有效的信息Q在输出时怎么把程
序中的信息{换ؓ(f)正确的字节流的问题?/font>
如果E序本n不需要处理这些数据,只是把数据从一个来源搬到另一个地方(
如把用户输入保存到文Ӟ或者从一个流dQ写到另一个流{)(j)Q而输入的字符~码与输出的字符~码一致的话,E序不需要对数据q行M~码转换Q只需要把d的数据按原样写到输出卛_Q数据的字符~码与程序的~码没有关系?
比如|站应用E序Q只需要保证用户页面用UTF-8~码Q数据库、数据文件也都用UTF-8~码Q那么用戯入的数据可以直接写入数据库及(qing)数据文gQ从数据库或数据文g中读取的数据也可以直接展现给用户Q不需要进行编码{换?/font>
如果E序需要在一定程序上Ҏ(gu)据进行处理(如需要判断字W个数、对字符q?br />行比较、在字符串上附加或去掉内容)(j)Q就要把数据转换ZU明的字符~码Q一般来说是E序内码Q再q行处理Q在处理后再转换为所需的字W编码进行输出?
对于宽字W程序,如果只需要处理采用当前运行环境字W编码的数据Q可以通过ios::imbue()可以指定io的字符~码Q在输入、输出时C++标准库会(x)自动在所指定的字W编码与E序内码之间q行~码转换。如果不使用的话,也可以通过标准的wcstombs()或mbstowcs()函数q行当前~码Q通过locale::global()或setlocale()指定Q与宽字W之间的转换?/font>
对于H字W程序,如果数据的字W编码与E序内码一致也不需要进行编码{换,直接处理卛_?
对于其它情ŞQ需要引入iconv或类似的字符~码转换库,以便实现不同
字符~码之间的{换?
׃gettext?qing)iconv都属于GNU ProjectQ考虑到版权因素,q所有程序,特别是商业程序,都适合使用q些库。在Boost 1.48.0中,Boost.Locale库首ơ正式发布,该库提供?jin)gettext、iconv的功能,q在此基上进行了(jin)增强Q提供了(jin)大小写变换、字W顺序比较、时间的处理 、分词、数字的格式化输?输出、消息格式化、多语种支持、字W编码{换等功能Q值得q一步研I及(qing)使用?/font>
Linux下Debug版不?x)自动添?_DEBUG宏,只有NDEBUG宏可用?/p>
cmake ../src _DCMAKE_BUILD_TYPE=Debug -D_DEBUG
?x)报错?x) -D_DEBUG should be: VAR:type=value
需?D_DEBUG=1.
改ؓ(f)在CMakeLists.txt中添加:(x)
if (CMAKE_BUILD_TYPE STREQUAL Debug)
add_definitions(
-D_DEBUG
)
endif ()
Win7讉KRedhat samba׃n
首先是开启samba:
service smb start
service smb restart
samba的配|文件是/ect/samba/smb.conf, 几乎不用改,使用默认配置p?jin)?/p>
默认是?security=user 模式׃nQ需要输入用户名密码才能讉K?/p>
默认有[homes]׃n配置Q各个用户可讉K自己的主目录?/p>
如添加新用户Q?/p>
useradd jinqing
passwd jinqing
smbpasswd -a jinqing
smb需要自q用户密码Q需用smbpasswd讄?/p>
q样共享了(jin)/home/jinqing.
试Qsmbclient //localhost/jinqing -Ujinqing
需要设|Selinux参数Q以允许׃n讉KQ可参照smb.conf中的注释q行Q?/p>
setsebool -P samba_enable_home_dirs on
然后是win7需要设|安全策略,不然也会(x)q不上?br />
打开理工具Q?#8220;本地{略”->“安全选项”->“|络安全QLAN Manager w䆾验证U别”Q?br />单击列表中:(x)发送LM和NTLMv2Q如果已协商Q则使用NTLMv2协议?br />
用到gprof时才知道Q原来gprof只能对主U程l计耗时。manual上也没写U程相关的问题啊Q?/p>
不过有现成的解决Ҏ(gu)Qhttp://sam.zoy.org/writings/programming/gprof.html
该方案封装了(jin)pthread_create(), 让线E初始化执行一个setitimer(ITIMER_PROF, ...)?/p>
易的Ҏ(gu)是直接在代码中写个setitimer()?/p>
./a.out
gprof
q样pl计出foo()的耗时?jin)。没有setitimer()׃?x)有foo()的耗时l计?/p>
未来的MySql 5.6.6 中,CMake选项中添加了(jin)gprof性能试支持Q见Q?br />
http://dev.mysql.com/doc/refman/5.6/en/source-configuration-options.html
ENABLE_GPROF Enable gprof (optimized Linux builds only) OFF 5.6.6
代码库中的CMakeLists.txt 摘录如下Q?/p>
CMakedgcov代码覆盖试支持
Q金?jin)的专栏Q?/p>
在根CMakeList.txt中添加ENABLE_GCOV选项Q?br />
OPTION(ENABLE_GCOV "Enable gcov (debug, Linux builds only)" OFF)
IF (ENABLE_GCOV AND NOT WIN32 AND NOT APPLE)以上代码来自MySQL的CMakeLists.txt.
如下执行cmake:
cmake SRC_DIR -DCMAKE_BUILD_TYPE=Debug -DENABLE_GCOV=1
~译后就可以看到图文?*.gcno?/p>
q行后,可以看到数据文g*.gcda生成?/p>执行 gcov main.cpp.gcno q?main.cpp.gcov 试l果?/div>
摘自Q?http://www.shnenglu.com/tx7do/archive/2010/08/19/124000.html
建立debug/release两目录,分别在其中执行cmake -DCMAKE_BUILD_TYPE=DebugQ或ReleaseQ,需要编译不同版本时q入不同目录执行make卛_Q?/p>
Debug版会(x)使用参数-gQRelease版?O3 –DNDEBUG
摘自Q?http://www.cnblogs.com/LittleFox/archive/2009/04/08/1431781.html
讑֮“svn:needs-lock”属?br />使用命o(h)行锁?#8220;介绍.doc”Q?br />
svn propset svn:needs-lock 'x' 介绍.doc
q?行这个命令后Q?#8220;介绍.doc”已l是讄?#8220;svn:needs-lock ”Q但Z(jin)使之生效q要q行“svn commit”Q之后其他用户update的时候就?x)发现这个文件已l是只读的了(jin)。需要注意的是我们设|的属性值是“x”Q实际上L值都可以Q? Subversion?x)忽略其内容?br />
使用TortoiseSVN讑֮属性也很简单:(x)
“介绍.doc”右键选中- >属?>Subversion选项?>properties->addQ然后在弹出的窗口中的property name选择“svn:needs-lock”QgQ意,然后选择OK。之后再提交“介绍.doc”卛_?/span>
|上搜烦(ch)的所有方法都没有解决q个错误?/p>
最后make clean;make;make install好?jin)?/p>
估计是需要make clean清除上次的错误才行?/p>