64,637
社区成员
发帖
与我相关
我的任务
分享G++编译器中的一个优化,还是不够标准?
#include <string>
#include <iostream>
using namespace std;
class A
{
public:
A()
{
cout<<"A()"<<endl;
}
A(const A& a)
{
cout<<"A(const A& a)"<<endl;
}
A& operator=(const& a)
{
cout<<"operator=(const& a)"<<endl;
return *this;
}
~A()
{
cout<<"~()"<<endl;
}
};
A getA()
{
A a;
return a;
}
int main()
{
A a = getA();
return 0;
}
这段代码理论是运行结果是
A()
A(const A& a)
~()
~()
可是今天用g++编译器一测试,运行结果为
A()
~()
其中的拷贝构造函数并没调用
然后在vc上运行以下
结果和理论上相同
一直以为g++标准是非常高的,不过也有些地方确实引如了不标准的东西
不过总体看来,g++是对代码进行了优化,不知道各位有何高见?
#include <iostream>
using namespace std;
class A
{
public:
A()
{
cout<<"A()"<<endl;
}
A(const A& a)
{
cout<<"A(const A& a)"<<endl;
}
A& operator=(const& a)
{
cout<<"operator=(const& a)"<<endl;
return *this;
}
~A()
{
cout<<"~()"<<endl;
}
};
A getA()
{
A a;
return a;
}
int main()
{
A a = getA();
return 0;
}
这段代码理论是运行结果是
A()
A(const A& a)
~()
~()
可是今天用g++编译器一测试,运行结果为
A()
~()
其中的拷贝构造函数并没调用
然后在vc上运行以下
结果和理论上相同
一直以为g++标准是非常高的,不过也有些地方确实引如了不标准的东西
不过总体看来,g++是对代码进行了优化,不知道各位有何高见?
...全文
请发表友善的回复…
发表回复
myknight 2009-12-30
- 打赏
- 举报
[Quote=引用 7 楼 winnuke 的回复:]
理论结果应该是：
A()
A(const A& a)
~（）
A()
A operator=
~()
~()
[/Quote]
A a = XXX这个地方是只调用拷贝构造函数的吧...
理论结果应该是：
A()
A(const A& a)
~（）
A()
A operator=
~()
~()
[/Quote]
A a = XXX这个地方是只调用拷贝构造函数的吧...
jackyjkchen 2009-11-13
- 打赏
- 举报
[Quote=引用 27 楼 do_fork 的回复:]
引用 23 楼 jackyjkchen 的回复:
我用的是老邓编译的那一套gcc 4.4.1，不清楚他是不是取消了动态链接crt的库
你用gcc编译时用的什么编译参数?
[/Quote]
编译boost？编译dll时，运行库和生成库都是动态的，编译lib时，运行库和生成库都是静态的，VC7、VC8、VC9、GCC的编译我只动了编译器和路径，其余选项都一样
bjam stage --toolset=msvc-9.0 --without-python --stagedir="R:\boost_1_40_0_VC9" link=shared runtime-link=shared threading=multi debug release
bjam stage --toolset=msvc-9.0 --without-python --stagedir="R:\boost_1_40_0_VC9" link=static runtime-link=static threading=multi debug release
引用 23 楼 jackyjkchen 的回复:
我用的是老邓编译的那一套gcc 4.4.1，不清楚他是不是取消了动态链接crt的库
你用gcc编译时用的什么编译参数?
[/Quote]
编译boost？编译dll时，运行库和生成库都是动态的，编译lib时，运行库和生成库都是静态的，VC7、VC8、VC9、GCC的编译我只动了编译器和路径，其余选项都一样
bjam stage --toolset=msvc-9.0 --without-python --stagedir="R:\boost_1_40_0_VC9" link=shared runtime-link=shared threading=multi debug release
bjam stage --toolset=msvc-9.0 --without-python --stagedir="R:\boost_1_40_0_VC9" link=static runtime-link=static threading=multi debug release
jackyjkchen 2009-11-13
- 打赏
- 举报
gui调用算法dll，测的是算法性能还是gui性能?
最好在控制台上测试下算法性能差异，再测试整合到gui后的性能差异，看看区别
------------------------------------------------------------------
我测的是gui对于算法性能的影响，如果完全整合，会稍慢，我以前做过代码级的整合，也做过静态库的整合，速度上动态>静态>源码，但是总的差距也不过5%。但毕竟是慢了，所以我放弃了后两种。后两种测试都是MFC环境的。gcc没有测试过。
Windows下gui程序的效率极其重要，这是Windows用户体验的“基础”。
最好在控制台上测试下算法性能差异，再测试整合到gui后的性能差异，看看区别
------------------------------------------------------------------
我测的是gui对于算法性能的影响，如果完全整合，会稍慢，我以前做过代码级的整合，也做过静态库的整合，速度上动态>静态>源码，但是总的差距也不过5%。但毕竟是慢了，所以我放弃了后两种。后两种测试都是MFC环境的。gcc没有测试过。
Windows下gui程序的效率极其重要，这是Windows用户体验的“基础”。
do_fork 2009-11-13
- 打赏
- 举报
[Quote=引用 24 楼 daidodo 的回复:]
引用楼主 vcrwx 的回复:
一直以为g++标准是非常高的,不过也有些地方确实引如了不标准的东西
不过总体看来,g++是对代码进行了优化,不知道各位有何高见?
给g++加参数 -O0，去掉优化即可。
不提供-O参数的情况下，g++会进行基本的优化。
参考：
http://blog.csdn.net/daidodo/archive/2008/03/15/2185222.aspx
[/Quote]
-O0
Reduce compilation time and make debugging produce the expected results. This is the default.
-O0是默认行为，不需要手工加上
引用楼主 vcrwx 的回复:
一直以为g++标准是非常高的,不过也有些地方确实引如了不标准的东西
不过总体看来,g++是对代码进行了优化,不知道各位有何高见?
给g++加参数 -O0，去掉优化即可。
不提供-O参数的情况下，g++会进行基本的优化。
参考：
http://blog.csdn.net/daidodo/archive/2008/03/15/2185222.aspx
[/Quote]
-O0
Reduce compilation time and make debugging produce the expected results. This is the default.
-O0是默认行为，不需要手工加上
do_fork 2009-11-13
- 打赏
- 举报
[Quote=引用 23 楼 jackyjkchen 的回复:]
我用的是老邓编译的那一套gcc 4.4.1，不清楚他是不是取消了动态链接crt的库
[/Quote]
你用gcc编译时用的什么编译参数?
我用的是老邓编译的那一套gcc 4.4.1，不清楚他是不是取消了动态链接crt的库
[/Quote]
你用gcc编译时用的什么编译参数?
do_fork 2009-11-13
- 打赏
- 举报
[Quote=引用 22 楼 jackyjkchen 的回复:]
假设win版跟Linux版差距很小，我认为这个假设本身就有问题
---------------------------------------------------
应该没什么大问题，你说的体积问题在于VC默认是动态链接CRT的，所以生成的dll非常小（我编译boost比你的夸张，我用gcc4.4.1编译出来的dll普遍是VC编译的10~20倍！而静态.a文件反而比VC的.lib小）。
速度上慢10%是差不多的，因为非图形界面的大工程上gcc for win相对于VC的效率差距也就是10%多，我不相信linux下的gcc在相同硬件下跑算法能反比VC快许多。
GUI程序性能测试拿什么测? 大量重复计算看总时间? 人的主观判断，是很不精确的。
------------------------------------------------------------------
我有一个gui程序的测试方法——纯C写算法dll，图形界面调用，MFC和wxwidget用VC基本可以做到比控制台简单调用慢5%，这种调用能把图形界面的速度影响最小化。
[/Quote]
两者都是static link，所以体积大小排除了运行库的原因。
gui调用算法dll，测的是算法性能还是gui性能?
最好在控制台上测试下算法性能差异，再测试整合到gui后的性能差异，看看区别
假设win版跟Linux版差距很小，我认为这个假设本身就有问题
---------------------------------------------------
应该没什么大问题，你说的体积问题在于VC默认是动态链接CRT的，所以生成的dll非常小（我编译boost比你的夸张，我用gcc4.4.1编译出来的dll普遍是VC编译的10~20倍！而静态.a文件反而比VC的.lib小）。
速度上慢10%是差不多的，因为非图形界面的大工程上gcc for win相对于VC的效率差距也就是10%多，我不相信linux下的gcc在相同硬件下跑算法能反比VC快许多。
GUI程序性能测试拿什么测? 大量重复计算看总时间? 人的主观判断，是很不精确的。
------------------------------------------------------------------
我有一个gui程序的测试方法——纯C写算法dll，图形界面调用，MFC和wxwidget用VC基本可以做到比控制台简单调用慢5%，这种调用能把图形界面的速度影响最小化。
[/Quote]
两者都是static link，所以体积大小排除了运行库的原因。
gui调用算法dll，测的是算法性能还是gui性能?
最好在控制台上测试下算法性能差异，再测试整合到gui后的性能差异，看看区别
jackyjkchen 2009-11-13
- 打赏
- 举报
修正一下，用bjam编译的boost，gcc也会生成.lib文件，应该是gcc的lib比VC的lib小。
daidodo 2009-11-13
- 打赏
- 举报
[Quote=引用楼主 vcrwx 的回复:]
一直以为g++标准是非常高的,不过也有些地方确实引如了不标准的东西
不过总体看来,g++是对代码进行了优化,不知道各位有何高见?
[/Quote]
给g++加参数 -O0，去掉优化即可。
不提供-O参数的情况下，g++会进行基本的优化。
参考：
http://blog.csdn.net/daidodo/archive/2008/03/15/2185222.aspx
一直以为g++标准是非常高的,不过也有些地方确实引如了不标准的东西
不过总体看来,g++是对代码进行了优化,不知道各位有何高见?
[/Quote]
给g++加参数 -O0，去掉优化即可。
不提供-O参数的情况下，g++会进行基本的优化。
参考：
http://blog.csdn.net/daidodo/archive/2008/03/15/2185222.aspx
jackyjkchen 2009-11-13
- 打赏
- 举报
我用的是老邓编译的那一套gcc 4.4.1，不清楚他是不是取消了动态链接crt的库
jackyjkchen 2009-11-13
- 打赏
- 举报
假设win版跟Linux版差距很小，我认为这个假设本身就有问题
---------------------------------------------------
应该没什么大问题，你说的体积问题在于VC默认是动态链接CRT的，所以生成的dll非常小（我编译boost比你的夸张，我用gcc4.4.1编译出来的dll普遍是VC编译的10~20倍！而静态.a文件反而比VC的.lib小）。
速度上慢10%是差不多的，因为非图形界面的大工程上gcc for win相对于VC的效率差距也就是10%多，我不相信linux下的gcc在相同硬件下跑算法能反比VC快许多。
GUI程序性能测试拿什么测? 大量重复计算看总时间? 人的主观判断，是很不精确的。
------------------------------------------------------------------
我有一个gui程序的测试方法——纯C写算法dll，图形界面调用，MFC和wxwidget用VC基本可以做到比控制台简单调用慢5%，这种调用能把图形界面的速度影响最小化。
---------------------------------------------------
应该没什么大问题，你说的体积问题在于VC默认是动态链接CRT的，所以生成的dll非常小（我编译boost比你的夸张，我用gcc4.4.1编译出来的dll普遍是VC编译的10~20倍！而静态.a文件反而比VC的.lib小）。
速度上慢10%是差不多的，因为非图形界面的大工程上gcc for win相对于VC的效率差距也就是10%多，我不相信linux下的gcc在相同硬件下跑算法能反比VC快许多。
GUI程序性能测试拿什么测? 大量重复计算看总时间? 人的主观判断，是很不精确的。
------------------------------------------------------------------
我有一个gui程序的测试方法——纯C写算法dll，图形界面调用，MFC和wxwidget用VC基本可以做到比控制台简单调用慢5%，这种调用能把图形界面的速度影响最小化。
do_fork 2009-11-13
- 打赏
- 举报
[Quote=引用 18 楼 jackyjkchen 的回复:]
引用 17 楼 do_fork 的回复:
引用 15 楼 jackyjkchen 的回复:
引用 14 楼 do_fork 的回复:
引用 10 楼 jackyjkchen 的回复:
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
被你猜对了，linux下VC跑不起来，没法测试，也就是gcc跨平台，win版gcc优化肯定不如linux，操作系统本身也会有影响。
不过，如果用上图形界面的话，gcc不如VC倒没说错。
图形界面怎么比呢，关公战秦琼?
windows图形界面在非windows平台根本跑不起来，
总不能把windows的GUI拿去跟GTK跟QT比吧。
gcc只为linux做较多优化，跑到aix下，也是慢的很，虽然aix也是UNIX一员
mingw不过是众多ports中的一个，Mono不怎么样，是不是也可以说微软.net不怎么样?
跨平台确实不好比，我们暂且假设win版gcc比linux慢不了太多，在10%以内，在Windows下分别用gcc和VC编译Wxwidget工程，wxwidget是调用win32 api本地窗口的，没有qt自绘窗口的开销，老邓测试过，效率差别比较大了，应该不单是win版gcc优化能力减弱的问题
[/Quote]
我用vc编译的QT库，体积只有win版gcc编译的一半左右，
假设win版跟Linux版差距很小，我认为这个假设本身就有问题，mingw本身就不是官方搞的东西，
GUI程序性能测试拿什么测? 大量重复计算看总时间? 人的主观判断，是很不精确的。
引用 17 楼 do_fork 的回复:
引用 15 楼 jackyjkchen 的回复:
引用 14 楼 do_fork 的回复:
引用 10 楼 jackyjkchen 的回复:
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
被你猜对了，linux下VC跑不起来，没法测试，也就是gcc跨平台，win版gcc优化肯定不如linux，操作系统本身也会有影响。
不过，如果用上图形界面的话，gcc不如VC倒没说错。
图形界面怎么比呢，关公战秦琼?
windows图形界面在非windows平台根本跑不起来，
总不能把windows的GUI拿去跟GTK跟QT比吧。
gcc只为linux做较多优化，跑到aix下，也是慢的很，虽然aix也是UNIX一员
mingw不过是众多ports中的一个，Mono不怎么样，是不是也可以说微软.net不怎么样?
跨平台确实不好比，我们暂且假设win版gcc比linux慢不了太多，在10%以内，在Windows下分别用gcc和VC编译Wxwidget工程，wxwidget是调用win32 api本地窗口的，没有qt自绘窗口的开销，老邓测试过，效率差别比较大了，应该不单是win版gcc优化能力减弱的问题
[/Quote]
我用vc编译的QT库，体积只有win版gcc编译的一半左右，
假设win版跟Linux版差距很小，我认为这个假设本身就有问题，mingw本身就不是官方搞的东西，
GUI程序性能测试拿什么测? 大量重复计算看总时间? 人的主观判断，是很不精确的。
VCRWX 2009-11-13
- 打赏
- 举报
[Quote=引用 8 楼 jackyjkchen 的回复:]
另外，楼主是不是用的gcc的ide？VC默认的debug是没有优化的，而gcc的许多ide是默认开了优化的
[/Quote]
直接用的vi , linux系统
另外，楼主是不是用的gcc的ide？VC默认的debug是没有优化的，而gcc的许多ide是默认开了优化的
[/Quote]
直接用的vi , linux系统
winnuke 2009-11-13
- 打赏
- 举报
这个帖子收获真大，nrvo。
对象初始化的一些细节。
对象初始化的一些细节。
jackyjkchen 2009-11-13
- 打赏
- 举报
[Quote=引用 17 楼 do_fork 的回复:]
引用 15 楼 jackyjkchen 的回复:
引用 14 楼 do_fork 的回复:
引用 10 楼 jackyjkchen 的回复:
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
被你猜对了，linux下VC跑不起来，没法测试，也就是gcc跨平台，win版gcc优化肯定不如linux，操作系统本身也会有影响。
不过，如果用上图形界面的话，gcc不如VC倒没说错。
图形界面怎么比呢，关公战秦琼?
windows图形界面在非windows平台根本跑不起来，
总不能把windows的GUI拿去跟GTK跟QT比吧。
gcc只为linux做较多优化，跑到aix下，也是慢的很，虽然aix也是UNIX一员
mingw不过是众多ports中的一个，Mono不怎么样，是不是也可以说微软.net不怎么样?
[/Quote]
跨平台确实不好比，我们暂且假设win版gcc比linux慢不了太多，在10%以内，在Windows下分别用gcc和VC编译Wxwidget工程，wxwidget是调用win32 api本地窗口的，没有qt自绘窗口的开销，老邓测试过，效率差别比较大了，应该不单是win版gcc优化能力减弱的问题
引用 15 楼 jackyjkchen 的回复:
引用 14 楼 do_fork 的回复:
引用 10 楼 jackyjkchen 的回复:
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
被你猜对了，linux下VC跑不起来，没法测试，也就是gcc跨平台，win版gcc优化肯定不如linux，操作系统本身也会有影响。
不过，如果用上图形界面的话，gcc不如VC倒没说错。
图形界面怎么比呢，关公战秦琼?
windows图形界面在非windows平台根本跑不起来，
总不能把windows的GUI拿去跟GTK跟QT比吧。
gcc只为linux做较多优化，跑到aix下，也是慢的很，虽然aix也是UNIX一员
mingw不过是众多ports中的一个，Mono不怎么样，是不是也可以说微软.net不怎么样?
[/Quote]
跨平台确实不好比，我们暂且假设win版gcc比linux慢不了太多，在10%以内，在Windows下分别用gcc和VC编译Wxwidget工程，wxwidget是调用win32 api本地窗口的，没有qt自绘窗口的开销，老邓测试过，效率差别比较大了，应该不单是win版gcc优化能力减弱的问题
do_fork 2009-11-13
- 打赏
- 举报
[Quote=引用 15 楼 jackyjkchen 的回复:]
引用 14 楼 do_fork 的回复:
引用 10 楼 jackyjkchen 的回复:
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
被你猜对了，linux下VC跑不起来，没法测试，也就是gcc跨平台，win版gcc优化肯定不如linux，操作系统本身也会有影响。
不过，如果用上图形界面的话，gcc不如VC倒没说错。
[/Quote]
图形界面怎么比呢，关公战秦琼?
windows图形界面在非windows平台根本跑不起来，
总不能把windows的GUI拿去跟GTK跟QT比吧。
gcc只为linux做较多优化，跑到aix下，也是慢的很，虽然aix也是UNIX一员
mingw不过是众多ports中的一个，Mono不怎么样，是不是也可以说微软.net不怎么样?
引用 14 楼 do_fork 的回复:
引用 10 楼 jackyjkchen 的回复:
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
被你猜对了，linux下VC跑不起来，没法测试，也就是gcc跨平台，win版gcc优化肯定不如linux，操作系统本身也会有影响。
不过，如果用上图形界面的话，gcc不如VC倒没说错。
[/Quote]
图形界面怎么比呢，关公战秦琼?
windows图形界面在非windows平台根本跑不起来，
总不能把windows的GUI拿去跟GTK跟QT比吧。
gcc只为linux做较多优化，跑到aix下，也是慢的很，虽然aix也是UNIX一员
mingw不过是众多ports中的一个，Mono不怎么样，是不是也可以说微软.net不怎么样?
winnuke 2009-11-13
- 打赏
- 举报
[Quote=引用 13 楼 yutaooo 的回复:]
引用 11 楼 winnuke 的回复:
引用 9 楼 yutaooo 的回复:
引用 7 楼 winnuke 的回复:
理论结果应该是：
A()
A(const A& a)
~（）
A()
A operator=
~()
~()
operator= 你确定 ？
可能错了。
忽然想如果这样写
explicit A(const A& a)
{
cout < <"A(const A& a)" < <endl;
}
A a = getA()
会不会有operator=()?
哦 。我的意思是，这是一次初始化还是一次赋值。
[/Quote]
你讲这句话使我意识到这是一次初始化。在这之前我觉得会先用默认构造函数初始化，然后赋值。但是又一想既然存在explicit关键字，那这里应该仅仅是一个初始化，只是平常很少写这样的代码。倘若加了explicit的话，那这里可能会编译失败。
引用 11 楼 winnuke 的回复:
引用 9 楼 yutaooo 的回复:
引用 7 楼 winnuke 的回复:
理论结果应该是：
A()
A(const A& a)
~（）
A()
A operator=
~()
~()
operator= 你确定 ？
可能错了。
忽然想如果这样写
explicit A(const A& a)
{
cout < <"A(const A& a)" < <endl;
}
A a = getA()
会不会有operator=()?
哦 。我的意思是，这是一次初始化还是一次赋值。
[/Quote]
你讲这句话使我意识到这是一次初始化。在这之前我觉得会先用默认构造函数初始化，然后赋值。但是又一想既然存在explicit关键字，那这里应该仅仅是一个初始化，只是平常很少写这样的代码。倘若加了explicit的话，那这里可能会编译失败。
jackyjkchen 2009-11-13
- 打赏
- 举报
[Quote=引用 14 楼 do_fork 的回复:]
引用 10 楼 jackyjkchen 的回复:
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
[/Quote]
被你猜对了，linux下VC跑不起来，没法测试，也就是gcc跨平台，win版gcc优化肯定不如linux，操作系统本身也会有影响。
不过，如果用上图形界面的话，gcc不如VC倒没说错。
引用 10 楼 jackyjkchen 的回复:
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
[/Quote]
被你猜对了，linux下VC跑不起来，没法测试，也就是gcc跨平台，win版gcc优化肯定不如linux，操作系统本身也会有影响。
不过，如果用上图形界面的话，gcc不如VC倒没说错。
do_fork 2009-11-13
- 打赏
- 举报
[Quote=引用 10 楼 jackyjkchen 的回复:]
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
[/Quote]
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
[/Quote]
在win32和Linux下分别测试的?
别告诉我用的是win版的gcc
yutaooo 2009-11-13
- 打赏
- 举报
[Quote=引用 11 楼 winnuke 的回复:]
引用 9 楼 yutaooo 的回复:
引用 7 楼 winnuke 的回复:
理论结果应该是：
A()
A(const A& a)
~（）
A()
A operator=
~()
~()
operator= 你确定 ？
可能错了。
忽然想如果这样写
explicit A(const A& a)
{
cout < <"A(const A& a)" < <endl;
}
A a = getA()
会不会有operator=()?
[/Quote]
哦 。我的意思是，这是一次初始化还是一次赋值。
引用 9 楼 yutaooo 的回复:
引用 7 楼 winnuke 的回复:
理论结果应该是：
A()
A(const A& a)
~（）
A()
A operator=
~()
~()
operator= 你确定 ？
可能错了。
忽然想如果这样写
explicit A(const A& a)
{
cout < <"A(const A& a)" < <endl;
}
A a = getA()
会不会有operator=()?
[/Quote]
哦 。我的意思是，这是一次初始化还是一次赋值。
jackyjkchen 2009-11-13
- 打赏
- 举报
[Quote=引用 10 楼 jackyjkchen 的回复:]
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
[/Quote]
如果是界面代码那就更没有悬念了……
引用 6 楼 do_fork 的回复:
引用 3 楼 jackyjkchen 的回复:
gcc的小逻辑上的优化更激进……VC的大工程优化更好。
这个结论从何得出?
实验得出……工程越大，VC越快，如果你有疑问，编译一个crypt++或者tomcrypt试试加密解密速度就知道……密码学的库从循环、移位、位运算、四则运算、随机数生成……几乎包含了所有整数运算，能充分显示出编译器的整数运算处理能力……
[/Quote]
如果是界面代码那就更没有悬念了……
加载更多回复（11）
