很久以前发现的 vc2008 的一个bug(关于模板匹配)

阅读更多关于《很久以前发现的 vc2008 的一个bug(关于模板匹配)》

使用操作符重载时,出现模板匹配错误,bug 的出现很简单,下面是代码:

vc2008 比 gcc4.3 真是差太多了

阅读更多关于《vc2008 比 gcc4.3 真是差太多了》

项目地址:http://code.google.com/p/febird

 

用gcc4.3重新编译了一下febird,出现了很多错误,仔细观察,这些错误都是因为不符合C++标准,重新改成符合标准的,比想象的改动量要大。
又测试了一下纯 C 实现的 algorithm: febird.c,是从VC2008的stl代码改过来的,在VC2008中测试比std::sort快20%,但是一到gcc中,却比std::sort慢了一倍还不止!不知到dinkware怎么写的。他有没有和sgi的比较过。重新研读了一下 gcc4.3 的 algorithm代码,gcc.stl.sort把insertion_sort放到sort的最后一个阶段,而ms.stl.sort把insertion_sort放到小区间内,就仅从这点上讲,gcc.stl.sort就少了很多函数调用的开销,ms又做了一些看似聪明的优化,比如递归层次按log(1.5,n)来计算,partition时又“跳过”连续相等的一段序列,等等,它的这些“优化”的结果就是速度只有gcc的1/3。

 

vc 鲜为人知的 __if_exists

阅读更多关于《vc 鲜为人知的 __if_exists》

msdn 中有这样一个示例:

 

但是不能检测某个变量是否有某个成员,象下面这样的代码是不能编译的:

 

 

或许是因为本质上,可以通过其它方法实现这个功能,也就是依据目前的这种机制,也可以达到目的,但是繁琐一些,需要加一个中间层,例如:

检查序列化声明的顺序和成员定义的顺序

阅读更多关于《检查序列化声明的顺序和成员定义的顺序》

DataIO_is_realdump用来推断一个对象是否可以直接通过dump内存来完成序列化,如果可以,在load/save时会有极大的性能提高。 继续阅读

febird.dataio vs boost.serialization 运行性能对比

阅读更多关于《febird.dataio vs boost.serialization 运行性能对比》

代码表示的是数据格式,DATA_IO_LOAD_SAVE 在 <febird/io/DataIO.h> 中定义

对于 boost.serializationDATA_IO_LOAD_SAVE 的定义相当于: 继续阅读

febird.DataIO 和 boost.serialization 编译性能对比

阅读更多关于《febird.DataIO 和 boost.serialization 编译性能对比》

C++ 程序的性能,重要的不光是运行性能,还有编译性能。运行性能就不多说了,编译性能往往被大家忽略,但是,想一下,如果编译一次要花一小时,那每天能编译几次?

和 boost.serialization 相比,febird.DataIO 的运行性能和编译性能都压倒性地胜出: 继续阅读

febird.dataio 优化技术

阅读更多关于《febird.dataio 优化技术》

优化技术主要有两点:

1.         优化的inline

a)         频繁调用的函数都使用inline,但是值得注意的是,在inline的时候,只inline最频繁的分支,很少走到的分支使用非inline函数,例如:

继续阅读