删帖吧

insmile

沙壁，整天说这些无聊的东西

oooooxxxxx

回复 1# xyfree


    就是你与我的差别

kasabranca

什么都看不到啊

幻の上帝

回复 72# OwnWaterloo

其实
#define __cplusplus 1 //不够遵守C++98
或者
#if __cplusplus >= 199711L //依赖于C++98或以上
都没什么错，只是无条件假定 __cplusplus 总会是1就不靠谱了。

xyfree

滚

幻の上帝

回复  幻の上帝

终于找到一个有gcc 4.5以上的了……  有*nix环境下的gcc 4.5+吗？
帮忙做个测试~~~

...
OwnWaterloo 发表于 2011-10-14 22:00

今天RP真那啥，等了半天没升完11.10网络连接失败给取消了，然后装个编译器又用了半天orz...
Ubuntu64 GCC 4.6.1
pic.tar (50 KB, 下载次数: 4)

2011-10-15 21:59 上传

点击文件名下载附件

OwnWaterloo

回复 84# 幻の上帝

我觉得一旦使用这些宏去判断 C or C++ 以及具体版本，至少得对其他版本做一个简单的交代吧？
比如

1. 
   
2. void f(int x, int y
   
3. #ifdef __cplusplus
   
4. = 12
   
5. #endif
   
6. );
   

复制代码

若是C++就给y提供一个默认值；若是C，那用户显然必须传递全部参数。

1. 
   
2. union max_align {
   
3. ...
   
4. #if _ _STDC_VERSION_ _>=199901L
   
5.       long long ll;
   
6.       intmax_t mi;
   
7. #endif
   
8. };
   

复制代码

如果是C99或更高，尽可能多定义一些成员；否则就算了。


#if __cplusplus >= 199711L
至少得对#else 作一个交代吧？
比如若此条件不满足，代码也没什么问题，也算交代了。
或者压根没考虑此条件不满足的情况， 在 #else 放一个 #error 什么的也行啊。

究竟是怎样的代码产生的兼容性问题才需要10年时间修复……
而且是这么简单的一个问题……  而且还是C++标准库（通常C++标准库的作者对C++标准会更熟悉吧？）

OwnWaterloo

回复 86# 幻の上帝

我的错……  忘记说i386了……  只懂i386汇编的说……
印象中x86/64有相对程序指针寻址的指令，所以位置无关代码的效率损失应该没有x86这么严重。
反正，虽然只懂一些x86的汇编，没有其他作为比较，也能隐隐感觉到x86的各种蛋疼……


我也悲剧了……  在同学的vps上编译gcc……   没有开启链接时优化支持……  一个多小时白编译了……
我的确有留心的看文档 http://gcc.gnu.org/install/configure.html

--enable-lto
--disable-lto
Enable support for link-time optimization (LTO). This is enabled by default, and may be disabled using --disable-lto.

现在想来这应该是较新的gcc的文档……
而我下载的是4.5.1的代码……


有i386+*nix+gcc4.5+ with -flto 的平台吗{:3_201:}

OwnWaterloo

回复 86# 幻の上帝

终于再次编译完了……
测试完毕~ 可以将无用代码消除掉~
不过vc的话……  2005就有链接时代码生成的说……   而gcc…… 这都快2012了……
而且对数据的位置无关访问依然有一个多余的指令……  算了……  这下使用pic的so完全没有压力了~

幻の上帝

回复 87# OwnWaterloo


>>   若是C++就给y提供一个默认值；若是C，那用户显然必须传递全部参数。
可行性没问题，也能说明你的观点。
（不过实际上如果不止一个就太麻烦了。另外这样的风格恐怕大部分人看起来会感觉很糟糕，#ifdef在这里会扰乱视线，倒不如干脆声明两次……）
>> 如果是C99或更高，尽可能多定义一些成员；否则就算了。
这倒是典型用法。
>> 至少得对#else 作一个交代吧？
对。这是库的作者保证他的作品的稳健性的责任。
>> 究竟是怎样的代码产生的兼容性问题才需要10年时间修复……
>> 而且是这么简单的一个问题……  而且还是C++标准库（通常C++标准库的作者对C++标准会更熟悉吧？）
我想这方面应该归咎于当年libstdc++的作者失误，在这方面没有付出足够的注意（毕竟10年前C++98已经有了，显然需要预见到这个问题）。（不过说实话我没有搞过这样大的东西，多少看起来有些站着说话不腰疼。）然而因为一个平台的兼容性导致拖了10年才修复也太夸张了点。
（我突然有点好奇，不知道商业产品中有多少这样的案例呢……）