亚洲国产综合在线,亚洲国产婷婷,亚洲激情av

GCC4.5的profile mode

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

GCC最�q�发布了4.5版本�Q�对于C++的支持除了更��Z��富的0x�Ҏ��支持外�Q�参�?a >�q�里�Q�，
�q�增加了一个新的profile模式�Q�尚处于试验阶段�Q�，可以�Ҏ��E�序�q�行状态给出关于STL使用的一些优化徏议�?br>
参看如下的描�q�ͼ�

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.

�q�个profile mode的主要作用就是根据代码实际运行状�늻�出关于STL的��用优化徏议。有炚w��憄��是，该profile�Ҏ��是intrusive的，必须��d��-D_GLBCXX_PROFILE来重新编译所有的代码�?br>
Profile mode的提出源�?9�q�CGO的一��?a >paper�Q�作者里边出��C��华�h的名字（�Ҏ��拼音来判断）;作者地址填的昄��是Purdue大学的：
Dept. of Comput. Sci., Purdue Univ., West�?br>
GCC的Profiler对C++的支持一贯停留在和C同样的水�q�I��׃��C++模板机制和OO的存在��得很多时候分析profiling�l�果的意义被大大削弱�?br>�q�个针对STL的profile mode�q�是很值得期待的�?br>

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

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

以前常用boost的一些库�Q�由于项目自�w�用cmake�l�织build�?br>boost每次升��之后�Q�重新用bjam�~�译一�ơ都很是不便�Q�某些��^収ͼ�用默认选项�~�译有些问题�Q�基本安装不成功�Q��?br>
最�q�才发现boost的cmake版本已经独立出来了，对于使用cmake的用戯��言�Q�这里是个不错的选择�?br>��目主页的文��很是清晎ͼ�最新的版本�?.41 (版本号对应的基本��是其upstream的boost版本�?�?br>源代码是用git�l�织的，对于Linux用户而言更加方便�?br>
引用其主��上的一句话�Q?br>

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

CMake + GIT +Spinx ��实够酷了�?br>
�~�译��h��可以充分利用强大的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卛_���?br>

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

CMake杂记

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

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

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

cd build
cmake ..
make

此时中间文�g不会污染��目的目录结构�?br>

2> 可以用如下方式生成同名的静态库和动态库�Q?/li>

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> 如何获取当前�q�行目录�Q�working directory�Q?可以在根目录讄��一个project_dir变量�Q�设�|��ؓ源代码目录，如下

set(project_top_dir ${CMAKE_CURRENT_SOURCE_DIR}/")

add_subdirectory(sub1)
add_subdirectory(sub2)

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

4> 处理跨��^台的�W�三方库�Q�假讄��三方库不是由CMake�~�译得来�Q�但要检��依赖和变动�Q�则可以用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 发表评论

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

对于�l�常在终端下写程序的non-windows�E�序员，Makefile�l�对是最常用的工��P��到一个文件的��单的��试�E�序�Q�大到数百个文�g的商业��Y�Ӟ��只需要有shell�Q�一个make命��o��可得到可运行的�E�序�Q�Makefile�l�对功不可没�Q�可惜世界中不是那么太��^�Q�不但各个Posix�pȝ��的API千差万别�Q�硬件��^台各异，��p��Makefile本��n也有多个不兼容的格式�Q�譬如GNU Makefile 拿到Solaris�q�_��上就没法make下去�Q�除非你有gmake�Q�但gmake对�ƈ行编译的支持��没有solaris自带的dmake要好了�?br>
GNU autotools提供了一个不错的选择�Q�可以做到组�l�工具链来生成所需的Makefile�Q�但�~�陷是学习�v来比较麻烦，而且模版文�g写�v来比较费劌Ӏ�老实说我跟Makefile打了�q?�q�的交道�Q�几乎没有自己写�q�automake脚本�Q�相反的工作倒是�q�了不少�Q�譬如分析生成的Makefile�q�行�q�程�Q�然后模拟自己手写Makefile�Q�得��C��个轻爽的定制环境�?br>
除了autotools�Q�其实也有不��其他的工具�Q�譬如apache的ant�Q�基于Python的scons�Q�ant在java界是鼎鼎大名了，可惜对c++的支持确实让我感觉很不习惯；scons��L��可以嵌入Python代码�Q�用��h��也算��单，但是惛_��现复杂的功能��很头疼了，而且�q�行速度让�h挠头�?br>
cmake则��I补了上述几个工具的诸多缺��P��
1> 易于学习�Q�文档易懂，只需牢记以下两个命��o卛_��Q?br>

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

2> 以文本文件组�l�，利用cache的方式，所有的自定义cache变量可直接用vim查看�?br>3> 生成的Makefile文�g��z�易�?br>4> �~�译器选项可自己在ccmake中编辑，利于交叉�~�译
5> 支持集成ctest/cpack,前者可以方便的做单元测试，后者则可以打包生成tgz/rpm
6> 支持多个生成器，可以生成eclipse/codeblocks/gmake/unix make文�g�Q�甚臛_��以生成VC各个版本的dsw/sln.
7> 内嵌语言�Q�可以自己写函数、宏�{?br>
对于�l�常写小��试�E�序的�h来说�Q�在test目录下加上个CMakeLists.txt�Q�里边加上几行简单的语句��可以方便的以后重复使用了。对于这�U�情况，手工写的Makefile��到依赖��这�U�麻烦的事情往往力不从心�Q�automake又太��题大作�Q�而cmake则恰到好处了�?br>
对于大型�E�序�Q�cmake可以自己定制生成的中间文件和目标文�g路径�Q�有效避免了automake带来的每个目录下生成一大堆文�g的弊端，也不需要手工写Makefile�?br>最有用的是可以生成多个知名IDE的工�E�文�Ӟ��包括Windows下的vc6-vc9.

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