删帖吧

namelij

赞一个话题，菜鸟飘过

OwnWaterloo

回复 69# 幻の上帝

gcc4.7……  口水……
终于找到一个用gcc4.5以上的了……
别跑啊……  帮我测试点东西……   我整理一下先……

其实我举 __cplusplus 的例子其实是想说明：
稍微大点的软件或者规范有太多细节、被忽略是很常见的事…… 尤其是该细节不太重要的时候，即使修复再简单，可能也没人想花功夫去修复……
没想到就这地方也会产生兼容性问题！
那个写下 #if __cplusplus >= 1997...L 的家伙是想闹哪样！ 费解……

OwnWaterloo

回复 69# 幻の上帝

先请教一个Windows/i386/mingw下的问题吧……
gcc的mangling不包含调用约定信息……

1. 
   
2. void __cdecl f() {}
   
3. void __stdcall f() {}
   

复制代码

不算重载，而是重定义……

但gcc会认为它们是不同的类型

1. 
   
2. typedef int diff[is_same_type<void(__cdecl*)(), void(__stdcall*)()>::value? -1: 1];
   

复制代码

于是

1. 
   
2. void __cdecl f0(int) {}
   
3. void __stdcall f1(int) {}
   
4. vector<int> v;
   
5. for_each(v.begin(), v.end(), f0);
   
6. for_each(v.begin(), v.end(), f1);
   

复制代码

两处for_each就重定义了……


而且这问题……
不解决吧，实际使用中遇见了查出原因不容易 —— 需要对C++实现细节有所了解
解决吧，难道要改mangling的方式？ 哦也，兼容性问题又来了……


有人报告这个"bug"么？ gcc打算处理么？


其实我觉得这也不全是gcc的责任…… Windows搞出什么__stdcall（而且大量采用！）,__fastcall 也脱不了关系。
C++没有"调用约定"的概念吧？ 或者说有类似概念，但没有描述"多种调用约定同时使用时"该怎么怎么……
btw： 类似的，git在Windows上对non-ascii字符的支持也很差，但同样说不清究竟是git不太重视Windows用户呢，还是Windows那套A/W函数作茧自缚了……

三月廿七

我发现 windows下用git 真的挺不错的,.  很漂亮的说{:3_182:}
先前真是无知啊，...

OwnWaterloo

回复 74# 三月廿七

"是否有GUI"不是检验工具是否好用的唯一标准啊……
一直在命令行下使用git的说……

真不是我zhuangbility什么的。
git最原始的界面毕竟是CLI，因此GUI界面提供的功能会滞后于CLI。
事实上，是大量的CLI功能没在GUI里面提供。

而且，真的不需要担心git的功能过于强大。
当git基本使用有了了解之后，可以试试直接了解git仓库的构成 —— 格式其实是非常简单的，并不需要花多少时间。
之后，git就是一个可以信任与依赖的工具了。
有时间就翻番manual，如果发现了需要的功能以后就可以直接用。
如果没时间翻，或者有什么需要的功能还没来得及翻到，或者压根被git实现 —— 自己动手丰衣足食即可……

zylthinking

回复  三月廿七

"是否有GUI"不是检验工具是否好用的唯一标准啊……
一直在命令行下使用git的说……

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

国庆研究git了7天， 终于绕过了 nothing to commit 提示{:3_189:}

OwnWaterloo

回复 76# zylthinking

git commit --allow-empty？  这个在手册中有。
如果没时间翻手册，但也想完成这个功能，只需要手工构造一个commit即可……

zylthinking

回复  zylthinking

git commit --allow-empty？  这个在手册中有。
如果没时间翻手册，但也想完成这个 ...
OwnWaterloo 发表于 2011-10-14 19:17

就是手工构造。。。。。。说明一定程度上， 我也知道这玩艺怎么用了。。。。。还没有在工作中接触过呢

OwnWaterloo

回复 78# zylthinking

反正我喜欢这样的可以让自己参与到其中，而不是被当作傻瓜对待的工具

OwnWaterloo

回复 69# 幻の上帝

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

生成位置无关的共享库且绑定内部符号的 -Wl,-Bsymbolic 只是一个链接时而非编译时参数，也许编译时编译器并不知道符号需要被绑定吧，就会产生一些无用代码。
测试的目： 测试链接时代码优化(-flto)是否会消除这些无用代码。

测试方法： 在bash里跑一跑下面的命令：

1. 
   
2. mkdir  pic
   
3. cd pic
   
4. 
   
5. echo '
   
6. #ifndef V
   
7. #define V default
   
8. #endif
   
9. #define STR(x) STR_(x)
   
10. #define STR_(x) #x
    
11. 
    
12. int __attribute__((__visibility__(STR(V)))) x_;
    
13. int* x(void) { return &x_; }
    
14. 
    
15. int __attribute__((__visibility__(STR(V)))) *f_(void) { return &x_; }
    
16. int* f(void) { return f_(); }
    
17. 
    
18. ' > pic.c
    
19. 
    
20. echo '
    
21. gcc -Wall $LTO -c -fPIC -O2 -fomit-frame-pointer ../pic.c -o public.o
    
22. gcc -Wall $LTO -c -fPIC -O2 -fomit-frame-pointer ../pic.c -o hidden.o -DV=hidden
    
23. gcc -Wall $LTO -shared -nostartfiles public.o -o public-free.so
    
24. gcc -Wall $LTO -shared -nostartfiles public.o -o public-bind.so -Wl,-Bsymbolic
    
25. gcc -Wall $LTO -shared -nostartfiles hidden.o -o hidden-free.so
    
26. gcc -Wall $LTO -shared -nostartfiles hidden.o -o hidden-bind.so -Wl,-Bsymbolic
    
27. ' > pic.sh
    
28. chmod +x pic.sh
    
29. 
    
30. (mkdir -p 0 && cd 0 && env -u LTO ../pic.sh)
    
31. (mkdir -p flto && cd flto && env LTO=-flto ../pic.sh)
    
32. 
    
33. find -name '*.o' -or -name '*.so' | xargs tar -cf pic.tar
    
34. 
    

复制代码

我需要最后生成的 pic.tar ~  论坛附件或者同名gmail邮箱都可以~ 多谢多谢~