C++博客- 驭风万里无垠-随笔分类-C++

GCC4.5的profile mode

skyscribe — Sun, 09 May 2010 07:16:00 GMT

GCC最近发布了4.5版本，对于C++的支持除了更为丰富的0x特性支持外（参考这里），
还增加了一个新的profile模式（尚处于试验阶段），可以根据程序运行状态给出关于STL使用的一些优化建议。

参看如下的描述：

An experimental profile mode has been added. This is an implementation of many C++ standard library constructs with an additional analysis layer that gives performance improvement advice based on recognition of suboptimal usage patterns. For example,
```
#include 
int main() 
{
  std::vector v;
  for (int k = 0; k < 1024; ++k) 
    v.insert(v.begin(), k);
}
```
When instrumented via the profile mode, can return suggestions about the initial size and choice of the container used as follows:
```
vector-to-list: improvement = 5: call stack = 0x804842c ...
    : advice = change std::vector to std::list
vector-size: improvement = 3: call stack = 0x804842c ...
    : advice = change initial container size from 0 to 1024
```
These constructs can be substituted for the normal libstdc++ constructs on a piecemeal basis, or all existing components can be transformed via the -D_GLIBCXX_PROFILE macro.

这个profile mode的主要作用就是根据代码实际运行状况给出关于STL的使用优化建议。有点遗憾的是，该profile方法是intrusive的，必须添加-D_GLBCXX_PROFILE来重新编译所有的代码。

Profile mode的提出源于09年CGO的一篇paper，作者里边出现了华人的名字（根据拼音来判断）;作者地址填的显然是Purdue大学的：
Dept. of Comput. Sci., Purdue Univ., West。

GCC的Profiler对C++的支持一贯停留在和C同样的水平；由于C++模板机制和OO的存在使得很多时候分析profiling结果的意义被大大削弱。
这个针对STL的profile mode还是很值得期待的。

skyscribe 2010-05-09 15:16 发表评论

boost.cmake: 方便解决boost的升级问题

skyscribe — Sun, 09 May 2010 06:59:00 GMT

以前常用boost的一些库，由于项目自身用cmake组织build。
boost每次升级之后，重新用bjam编译一次都很是不便（某些平台，用默认选项编译有些问题，基本安装不成功）。

最近才发现boost的cmake版本已经独立出来了，对于使用cmake的用户而言，这里是个不错的选择。
项目主页的文档很是清晰，最新的版本是1.41 (版本号对应的基本就是其upstream的boost版本号)。
源代码是用git组织的，对于Linux用户而言更加方便。

引用其主页上的一句话：

Boost.CMake (or alt.boost ) is the boost distribution that all the cool kids are using.

CMake + GIT +Spinx 确实够酷了。

编译起来可以充分利用强大的CMake了：

git clone git://gitorious.org/boost/cmake.git src
cd src
git checkout     //TAG==1.41.0.cmake0
mkdir bld
cd bld/
cmake ../

如果需要按需编译某些库，只需用make edit_cache修改cache即可。

skyscribe 2010-05-09 14:59 发表评论

Curl&SSL

skyscribe — Mon, 27 Jul 2009 14:29:00 GMT

源码编译libcurl的时候,由于使用的不是默认系统上的ssl库（开发服务器上有很多个版本），为了避免动态库链接问题，必须定制SSL。
根据其源码里边的说明，
只需要在./configure 后边加上 --with-ssl=即可。

开始的时候，没留意这个，因为粗略扫描了一下 --help, 后边这么说了：

  --with-libssh2=PATH     Where to look for libssh2, PATH points to the
                          LIBSSH2 installation (default: /usr/local/lib); when
                          possible, set the PKG_CONFIG_PATH environment
                          variable instead of using this option

我的目标库的确就是在/usr/local/ssl下边了，当时编译之后，链接起来总是提示找不到对应版本的libssl.so.0.9.7.

后来才发现(将环境变量做小幅调整、改动来探测)，这个default在Solaris上边并不是真的default,必须显示指定为/usr/local/ssl,否则找到的居然是/usr/sfw/。

skyscribe 2009-07-27 22:29 发表评论

CMake杂记

skyscribe — Sat, 04 Jul 2009 05:15:00 GMT

1> 尽量使用外部build而不是内部build.

所谓的内外，指的是make目录和CMakeLists.txt不在一个目录下。
好处是，所有的临时文件都会生成在当前运行cmake/make的目录。
譬如在项目根目录有一个CMakeLists.txt作为top-level file, 几个代码子目录，一个build目录，可以用：

cd build
cmake ..
make

此时中间文件不会污染项目的目录结构。

2> 可以用如下方式生成同名的静态库和动态库：

set(libname "mylib")

add_library(libname_static STATIC src1 src2)
set_target_properties(libname_static OUTPUT_NAME ${libname})

add_library(libname SHARED src1 src2)

3> 如何获取当前运行目录（working directory）:可以在根目录设置一个project_dir变量，设置为源代码目录，如下

set(project_top_dir ${CMAKE_CURRENT_SOURCE_DIR}/")

add_subdirectory(sub1)
add_subdirectory(sub2)

此时，各个子目录中可以应用project_top_dir.

4> 处理跨平台的第三方库：假设第三方库不是由CMake编译得来，但要检测依赖和变动，则可以用imported属性：

add_library(ssllib SHARED IMPORTED)
add_library(cryptolib SHARED IMPORTED)
#May have different dependent libraries
set(libsuffix ${CMAKE_SYSTEM_NAME}_${CMAKE_SYSTEM_PROCESSOR})
set_target_properties(ssllib PROPERTIES IMPORTED_LOCATION "${project_top_dir}contrib/openssl/lib/libssl-${libsuffix}.so")
set_target_properties(cryptolib PROPERTIES IMPORTED_LOCATION "${project_top_dir}contrib/openssl/lib/libcrypto-${libsuffix}.so")

........................
#other CMakeLists.txt
add_executable(myExe src1 src2)
target_link_libraries(myExe ssllib cryptolib)

skyscribe 2009-07-04 13:15 发表评论

利用cmake来搭建开发环境

skyscribe — Wed, 01 Jul 2009 13:51:00 GMT

对于经常在终端下写程序的non-windows程序员，Makefile绝对是最常用的工具，小到一个文件的简单的测试程序，大到数百个文件的商业软件，只需要有shell，一个make命令就可得到可运行的程序，Makefile绝对功不可没；可惜世界中不是那么太平，不但各个Posix系统的API千差万别，硬件平台各异，就连Makefile本身也有多个不兼容的格式，譬如GNU Makefile 拿到Solaris平台上就没法make下去，除非你有gmake，但gmake对并行编译的支持就没有solaris自带的dmake要好了。

GNU autotools提供了一个不错的选择，可以做到组织工具链来生成所需的Makefile，但缺陷是学习起来比较麻烦，而且模版文件写起来比较费劲。老实说我跟Makefile打了近3年的交道，几乎没有自己写过automake脚本，相反的工作倒是干了不少，譬如分析生成的Makefile运行过程，然后模拟自己手写Makefile；得到一个轻爽的定制环境。

除了autotools，其实也有不少其他的工具，譬如apache的ant，基于Python的scons；ant在java界是鼎鼎大名了，可惜对c++的支持确实让我感觉很不习惯；scons号称可以嵌入Python代码，用起来也算简单，但是想实现复杂的功能就很头疼了，而且运行速度让人挠头。

cmake则弥补了上述几个工具的诸多缺陷：
1> 易于学习，文档易懂，只需牢记以下两个命令即可：

cmake --help
cmake --help-command-list
cmake --help-command xxx
cmake --help-variable-list
cmake --help-variable yyy

2> 以文本文件组织，利用cache的方式，所有的自定义cache变量可直接用vim查看。
3> 生成的Makefile文件简洁易懂
4> 编译器选项可自己在ccmake中编辑，利于交叉编译
5> 支持集成ctest/cpack,前者可以方便的做单元测试，后者则可以打包生成tgz/rpm
6> 支持多个生成器，可以生成eclipse/codeblocks/gmake/unix make文件，甚至可以生成VC各个版本的dsw/sln.
7> 内嵌语言，可以自己写函数、宏等

对于经常写小测试程序的人来说，在test目录下加上个CMakeLists.txt，里边加上几行简单的语句就可以方便的以后重复使用了。对于这种情况，手工写的Makefile碰到依赖检测这种麻烦的事情往往力不从心，automake又太小题大作，而cmake则恰到好处了。

对于大型程序，cmake可以自己定制生成的中间文件和目标文件路径，有效避免了automake带来的每个目录下生成一大堆文件的弊端，也不需要手工写Makefile。
最有用的是可以生成多个知名IDE的工程文件，包括Windows下的vc6-vc9.

skyscribe 2009-07-01 21:51 发表评论

Log4cpp:为中小型C++项目加上log支持

skyscribe — Thu, 18 Jun 2009 14:22:00 GMT

对于一个上点规模的C++项目而言，Log的作用是毋庸置疑的，出问题的时候，看了Log，常见的问题处理起来自是方便不过，即使遇到麻烦的问题，也可以从ｌｏｇ总发现不少蛛丝马迹。因此一个严肃的项目应该从一开始就好好考虑如何打Log，便于分析、维护。

现实的情况却是很多项目都是从最初的数千行代码逐步庞大起来；开始的时候可能为了图方便，加log的方式大多是自己在iostream的基础上自己封装一下；等到项目扩大数十倍的时候，却发现这种方式很力不从心，Log文件凌乱复杂，难以管理。

现有的log工具，基本是分为两个阵营，经典的syslog和花哨强大的log4j，从而衍生出很多个变体。log4j基本已经成为复杂应用程序的log标准了，无奈C++的几个模仿者确各有千秋。我的情况是：
1>不需要复杂的配置，甚至不需要配置文件，但修改log消息格式又要很方便
2>支持自动备份功能
3>多线程安全
4>效率要尽量高
5>不要有其他依赖

log4cpp很轻易的满足了我的要求，只需要用已有的RollingFileAppender准备好后端，创建PatternLayout，一切就可以了；log级别的设置完全和syslog协议一样，很直观，打log地方，调用默认的Category管理器取得一个命名的Category,其他就是简单的调用了: log(), debug(), notice(), info(), notice()....

本来最感兴趣的是log4cxx, Apache的伟大项目，功能也最全，麻烦的是它自带了两个平台库，需要额外依赖；配置文件也要显示准备，感觉太臃肿了，估计大项目采用的吧。

效率上最高的应该是pantheiosle了，据说没开启Log的情况下，overhead几乎是0，作者自称效率是log4cxx的数倍，但也依赖于STLSoft（虽然只有头文件）,其打包方式也让人想避而远之，还要用作者自己写的版本选择器来选一个合适的库（Win的情况）。

还有一个是Boost的logging库，用尽了模板技巧，虽然很炫，当时没多少用，也没有通过boost 严格的review，虽然是专家写的，暂时也没时间评估和学习了。

skyscribe 2009-06-18 22:22 发表评论

GCC4.4.0 & C++0x 初体验

skyscribe — Sat, 16 May 2009 14:24:00 GMT

闲来无事，翻看GNU的邮件列表，发现4.4.0版本已经发布一个月有余，其中最大的改进莫过于c++了（也许是我对c++的部分最为关注的缘故），ChangeLog里边甚至专门列了一个网页描述针对C++0x的支持特性，忍不住体验一把。

第一步要做的自然是手动编译GCC的源代码了，因为我没有找到Debian版本的升级包，干脆自己下载，我只需要gcc-core和g++两个包就可以了，一个25M，一个7M，下载倒是挺顺利，几分钟就OK了，接下来就是编译了。常见的源码编译步骤就OK了：

./Configure
make
make install

我遇到的是有两个关于多处理器的开发库依赖，apt-get很容易就安装上去了。

编译的过程就比较漫长了，我的Pentium D 2.8G Dual Core活生生忙活了一个小午休的时间，起来发现还没编译完，不过十分钟之后就发现所有的就OK了。

TR1的库，boost的示例比较好，其中第21章有详细的列表和用法简要说明。参照那个查了一下GCC的头文件，在
/usr/local/include/c++/4.4.0/tr1/ 里边：

ls -lh | awk '$8 ~/^[a-z]+$/{print $8}'

array
ccomplex
cctype
cfenv
cfloat
cinttypes
climits
cmath
complex
cstdarg
cstdbool
cstdint
cstdio
cstdlib
ctgmath
ctime
cwchar
cwctype
functional
memory
random
regex
tuple
utility

我比较熟悉和期待的是bind, function, auto, shared_ptr, mem_fn这几个库了，写了个小例子验证之：

1// g++ -std=c++0x -o testC++0x testNewC++.cpp
2
3#include <tr1/memory>
4#include <tr1/functional>
5#include <tr1/tuple>
6#include <vector>
7#include <iostream>
8
9using namespace std;
10
11void func1(int i, int j, tr1::tuple<int, int, int> k)
12{
13    cout << "func1:" << i << ", " << j << ", "
14         << ", tuple param:[" << get<0>(k) << "," << get<1>(k)
15         << "," << get<2>(k) << "]" << endl;
16}
17
18
19void func2(int i, int j)
20{
21    cout << "func2: " << i << ", " << j << endl;
22}
23
24void func3(int k)
25{
26    cout << "func3: " << k << endl;
27}
28
29struct MyFunc1
30{
31    void memFun1(int i, int j)
32    {
33        cout << "MyFunc1::memFun1 :" << i << ", " << j << endl;
34    }
35
36    void memFun2(int i, int j, int k)
37    {
38        cout << "MyFunc1::memFun2 :" << i << ", " << j << ", " << k << endl;
39    }
40};
41
42int main()
43{
44
45    typedef tr1::function<void (int)> Func;
46    using std::tr1::bind;
47    using std::tr1::mem_fn;
48    using std::tr1::placeholders::_1;
49    using std::tr1::shared_ptr;
50
51    shared_ptr<MyFunc1> instPtr(new MyFunc1);
52    MyFunc1 functor;
53
54    vector<Func> funcs;
55    funcs.push_back(bind(&func1, _1, 2, tr1::make_tuple(3,  4, 5)));
56    funcs.push_back(bind(&func2, 1, _1));
57    funcs.push_back(&func3);
58    funcs.push_back(bind(&MyFunc1::memFun1, &functor, _1, 21));
59    funcs.push_back(bind(mem_fn(&MyFunc1::memFun2), &functor, 1, 2, _1));
60    funcs.push_back(bind(&MyFunc1::memFun1, instPtr, _1, 22));
61
62    for (auto it = funcs.begin(), itEnd = funcs.end();
63        it != itEnd; ++it)
64    {
65        (*it)(0);
66    }
67
68    return 0;
69}

编译之后，运行结果如下：

func1:0, 2, , tuple param:[3,4,5]
func2: 1, 0
func3: 0
MyFunc1::memFun1 :0, 21
MyFunc1::memFun2 :1, 2, 0
MyFunc1::memFun1 :0, 22

由于我的环境下，新版的litstdc++.so被安装在了/usr/local/lib64/下边，所以需要手工指定动态库的路径（export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH即可绕过/usr/lib/libstdc++.so）.

估计这么奇妙的特性，进入工业应用还得不少时间吧，麻烦的标准化...

skyscribe 2009-05-16 22:24 发表评论