e*********6 发帖数: 3453 | 1 【 以下文字转载自 Apple 讨论区 】
发信人: ericzhang86 (eric), 信区: Apple
标 题: 被苹果给惊呆了!!
发信站: BBS 未名空间站 (Fri Oct 23 17:06:50 2015, 美东)
int main(){
vector a(10, 5);
a[11] = 100;
}
这个程序,苹果自带编译器居然给不出正确的结果来。
应该是vector越界,runtime error,但是苹果的g++照样能用给出结果来。
真是给苹果跪了。 |
f*******t 发帖数: 7549 | 2 如何吐槽?
楼主还是用java吧,c艹不适合你
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 【 以下文字转载自 Apple 讨论区 】 : 发信人: ericzhang86 (eric), 信区: Apple : 标 题: 被苹果给惊呆了!! : 发信站: BBS 未名空间站 (Fri Oct 23 17:06:50 2015, 美东) : int main(){ : vector a(10, 5); : a[11] = 100; : } : 这个程序,苹果自带编译器居然给不出正确的结果来。 : 应该是vector越界,runtime error,但是苹果的g++照样能用给出结果来。
|
N***m 发帖数: 4460 | 3 It is undefined behavior (say, in non-debug mode) , so Apple g++ is not
wrong in this sense.
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 【 以下文字转载自 Apple 讨论区 】 : 发信人: ericzhang86 (eric), 信区: Apple : 标 题: 被苹果给惊呆了!! : 发信站: BBS 未名空间站 (Fri Oct 23 17:06:50 2015, 美东) : int main(){ : vector a(10, 5); : a[11] = 100; : } : 这个程序,苹果自带编译器居然给不出正确的结果来。 : 应该是vector越界,runtime error,但是苹果的g++照样能用给出结果来。
|
e*********6 发帖数: 3453 | 4 如果我想Mac下的g++和linux下的有同样的性质,应该怎么改flag?
【在 N***m 的大作中提到】![](/moin_static193/solenoid/img/up.png) : It is undefined behavior (say, in non-debug mode) , so Apple g++ is not : wrong in this sense.
|
t***t 发帖数: 6066 | |
e*********6 发帖数: 3453 | 6 为何,这里很明显,linux是好的,mac的不好,因为改了不属于这个vector的地址
【在 f*******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 如何吐槽? : 楼主还是用java吧,c艹不适合你
|
e*********6 发帖数: 3453 | 7 请明示。
这里边肯定库和定义不一样,但是Mac用了g++的命令却给出不一样的结果,很奇怪
【在 f*******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 如何吐槽? : 楼主还是用java吧,c艹不适合你
|
C********n 发帖数: 150 | |
T******7 发帖数: 1419 | 9 try to understand what is undefined behavior. |
e*********6 发帖数: 3453 | 10 谢谢。
这算是个undefined的behavior,相当于法律没有规定,但是GNU g++已经有实践了,相
当于其他法院已经有了判例,为什么苹果不遵守呢
【在 T******7 的大作中提到】![](/moin_static193/solenoid/img/up.png) : try to understand what is undefined behavior.
|
|
|
e*********6 发帖数: 3453 | 11 谢谢推荐.
我所诧异的是【】的操作,尽管是undefined,但是为了后来的苹果不跟着前边的GNU一
样走呢
【在 C********n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : http://stackoverflow.com/questions/3056597/are-vectors-more-rig
|
f*******t 发帖数: 7549 | 12 GNU怎么做跟apple有什么关系?为什么apple一定要follow? |
e*********6 发帖数: 3453 | 13 gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自
立山头当大哥,所以才说被苹果惊呆了
【在 f*******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : GNU怎么做跟apple有什么关系?为什么apple一定要follow?
|
f*******t 发帖数: 7549 | 14 行业标准是undefined。另外apple我行我素多年了,有什么好纠结的?
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
e*********6 发帖数: 3453 | 15 这就好比红灯停绿灯行是行业标准,红灯右转没定义。大家通行办法是按照stop sign
处理,唯独苹果是直接走
【在 f*******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 行业标准是undefined。另外apple我行我素多年了,有什么好纠结的?
|
g*****g 发帖数: 34805 | 16 Undefined就是undefined,写了undefined出了bug 都是骂程序员,没有骂编译器的。
这就如绿灯过马路不看路可以,红灯右转你也不看,撞死活该。
sign
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这就好比红灯停绿灯行是行业标准,红灯右转没定义。大家通行办法是按照stop sign : 处理,唯独苹果是直接走
|
c***r 发帖数: 4631 | 17 装个gcc不就得了。
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 如果我想Mac下的g++和linux下的有同样的性质,应该怎么改flag?
|
l*****z 发帖数: 3022 | 18 果家自己是用clang+llvm 不用gcc 或 g++
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这就好比红灯停绿灯行是行业标准,红灯右转没定义。大家通行办法是按照stop sign : 处理,唯独苹果是直接走
|
e*********6 发帖数: 3453 | 19 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
【在 l*****z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 果家自己是用clang+llvm 不用gcc 或 g++
|
h******n 发帖数: 2795 | 20 其实,Apple C(C++)编译器跟GNU GCC几乎是一样的。
你这段代码,很可能在Linux下也能通过。但在,MS Visual Studio C++上就通不过。
我前几天遇到很类似的代码(是别人写的),其中的一个subroutine,在一个特例情况
下(i=0),给开的1D数组大小是0,但程序默认给a[0]赋值。这个程序在RHEL 6.7下成
功运行。但是,我搬到Windows下来,则运行出错。通过debug,发现此处出错。
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
|
|
i*****r 发帖数: 265 | 21 又不是java,为啥要报错。segfault或者过了都可以。 |
b***i 发帖数: 3043 | 22 这个应该和操作系统对内存的保护有关,和g++无关
用at可以查边界
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
y*j 发帖数: 3139 | 23 C++的原则是allow shooting his own foot. 这里gcc的处理是不符合标准的,
[在 ericzhang86 (eric) 的大作中提到:]
:【 以下文字转载自 Apple 讨论区 】
:发信人: ericzhang86 (eric), 信区: Apple
:........... |
d****i 发帖数: 4809 | 24 这个不能怪Apple,C++的标准对于vector的operator[],如果越界的话,就是
undefined behavior。看一下C++的manpage:
http://www.cplusplus.com/reference/vector/vector/operator%5B%5D
Portable programs should never call this function with an argument n that is
out of range, since this causes undefined behavior.
在Linux下就会seg fault, 而在OS X下,苹果就仁慈的给了个垃圾数值的结果,只能说
苹果的implementation太委婉了一点。
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
d****i 发帖数: 4809 | 25 很好奇如果用Mac OS X下的Clang编译后运行的结果是怎样的?哪个装了Clang编译器的
来说说? |
f*****r 发帖数: 754 | 26 选择不同的dialect就会有不同的结果
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 谢谢。 : 这算是个undefined的behavior,相当于法律没有规定,但是GNU g++已经有实践了,相 : 当于其他法院已经有了判例,为什么苹果不遵守呢
|
d********g 发帖数: 10550 | 27 Clang/LLVM才是趋势吧。本来BSD系的就不怎么鸟GNU/Linux,FreeBSD不久前也全线抛
弃GCC了
OS X:
$ g++ --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx
-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix
FreeBSD:
$ clang --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
GPL不是啥灵丹妙药,open source也并非GNU的天下
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 【 以下文字转载自 Apple 讨论区 】 : 发信人: ericzhang86 (eric), 信区: Apple : 标 题: 被苹果给惊呆了!! : 发信站: BBS 未名空间站 (Fri Oct 23 17:06:50 2015, 美东) : int main(){ : vector a(10, 5); : a[11] = 100; : } : 这个程序,苹果自带编译器居然给不出正确的结果来。 : 应该是vector越界,runtime error,但是苹果的g++照样能用给出结果来。
|
d********g 发帖数: 10550 | 28 GNU不是啥行业标准,Linux才是BSD的小弟,Clang/LLVM相比GCC是长江后浪推前浪。
GCC爱怎么玩是它自己的事,就好像MS、Intel的编译器也一直夹带私货
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
k***0 发帖数: 1381 | 29 井底之蛙,c++这块gnu算个鸟蛋行标,鬼才follow gnu呢
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 谢谢推荐. : 我所诧异的是【】的操作,尽管是undefined,但是为了后来的苹果不跟着前边的GNU一 : 样走呢
|
k***0 发帖数: 1381 | 30 谁告诉你gnu是行业标准的。你知道当初#pragma在gn下是啥么
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
|
|
t*********r 发帖数: 2431 | 31 什么神经病逻辑,undefined就是undefined,怎么implement都可以。g++照你说的这么
牛逼有本事把它改成defined
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 谢谢。 : 这算是个undefined的behavior,相当于法律没有规定,但是GNU g++已经有实践了,相 : 当于其他法院已经有了判例,为什么苹果不遵守呢
|
d****i 发帖数: 4809 | 32 FreeBSD把它的默认的cc从GCC改成clang是有原因的,主要是GCC采用GPL license,和
FreeBSD的BSD license的完全自由随便自个儿改的理念不一样。而并非clang比gcc好。
实际上gcc还是比clang要成熟稳定很多。
gxx
【在 d********g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : Clang/LLVM才是趋势吧。本来BSD系的就不怎么鸟GNU/Linux,FreeBSD不久前也全线抛 : 弃GCC了 : OS X: : $ g++ --version : Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx : -include-dir=/usr/include/c++/4.2.1 : Apple LLVM version 7.0.0 (clang-700.1.76) : Target: x86_64-apple-darwin15.0.0 : Thread model: posix : FreeBSD:
|
d********g 发帖数: 10550 | 33 FreeBSD之前一直被困在GPLv2,导致GCC不能升级到最新的用GPLv3的版本。而Clang直
接把那个旧版的GCC秒成渣了
FreeBSD不愿意随便用GNU的东西,虽然有些东西GNU做得好一点比如GNU grep就比较快
【在 d****i 的大作中提到】![](/moin_static193/solenoid/img/up.png) : FreeBSD把它的默认的cc从GCC改成clang是有原因的,主要是GCC采用GPL license,和 : FreeBSD的BSD license的完全自由随便自个儿改的理念不一样。而并非clang比gcc好。 : 实际上gcc还是比clang要成熟稳定很多。 : : gxx
|
v*****r 发帖数: 1119 | 34 背楼主的逻辑惊呆了,还是转行吧,你不适合当程序员
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
v*****r 发帖数: 1119 | 35 背楼主的逻辑惊呆了,还是转行吧,你不适合当程序员
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
n******7 发帖数: 12463 | 36 别这么说
他本来就不是程序员
大家再这么嘲讽的话,楼主又要自删主贴了。。。
【在 v*****r 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 背楼主的逻辑惊呆了,还是转行吧,你不适合当程序员
|
C********n 发帖数: 150 | |
c***r 发帖数: 4631 | 38 #include
int main(int argc, const char * argv[]) {
std::vector a(10, 5);
a[11] = 100; //Program ended with exit code: 0
//a.at(11) = 10;//libc++abi.dylib: terminating with uncaught exception
of type std::out_of_range: vector::_M_range_check Program ended with exit
code: 9
return 0;
}
【在 d****i 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 很好奇如果用Mac OS X下的Clang编译后运行的结果是怎样的?哪个装了Clang编译器的 : 来说说?
|
k****z 发帖数: 550 | 39 行业惯例就是undefined,意思是编译器不应该做边界检查。
如果gcc真的每次作边界检查,那是完全错误的行为,因为增加代码白白浪费了cycle,
也可能跟某种假定不做边界检查的代码会有兼容问题。(在历史上有很多代码用这种那
种trick作系统级别的行为)
正确的做法是不做边界检查,由程序员自己负责。
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
g*********e 发帖数: 14401 | 40 lol
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
|
|
e*********6 发帖数: 3453 | 41 【 以下文字转载自 Apple 讨论区 】
发信人: ericzhang86 (eric), 信区: Apple
标 题: 被苹果给惊呆了!!
发信站: BBS 未名空间站 (Fri Oct 23 17:06:50 2015, 美东)
int main(){
vector a(10, 5);
a[11] = 100;
}
这个程序,苹果自带编译器居然给不出正确的结果来。
应该是vector越界,runtime error,但是苹果的g++照样能用给出结果来。
真是给苹果跪了。
update 问题自己解决,也知道怎么回事。问题就是apple在一些非硬性标准的惯例不跟
着行业老大gnu走 |
f*******t 发帖数: 7549 | 42 如何吐槽?
楼主还是用java吧,c艹不适合你
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 【 以下文字转载自 Apple 讨论区 】 : 发信人: ericzhang86 (eric), 信区: Apple : 标 题: 被苹果给惊呆了!! : 发信站: BBS 未名空间站 (Fri Oct 23 17:06:50 2015, 美东) : int main(){ : vector a(10, 5); : a[11] = 100; : } : 这个程序,苹果自带编译器居然给不出正确的结果来。 : 应该是vector越界,runtime error,但是苹果的g++照样能用给出结果来。
|
N***m 发帖数: 4460 | 43 It is undefined behavior (say, in non-debug mode) , so Apple g++ is not
wrong in this sense.
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 【 以下文字转载自 Apple 讨论区 】 : 发信人: ericzhang86 (eric), 信区: Apple : 标 题: 被苹果给惊呆了!! : 发信站: BBS 未名空间站 (Fri Oct 23 17:06:50 2015, 美东) : int main(){ : vector a(10, 5); : a[11] = 100; : } : 这个程序,苹果自带编译器居然给不出正确的结果来。 : 应该是vector越界,runtime error,但是苹果的g++照样能用给出结果来。
|
e*********6 发帖数: 3453 | 44 如果我想Mac下的g++和linux下的有同样的性质,应该怎么改flag?
【在 N***m 的大作中提到】![](/moin_static193/solenoid/img/up.png) : It is undefined behavior (say, in non-debug mode) , so Apple g++ is not : wrong in this sense.
|
t***t 发帖数: 6066 | |
e*********6 发帖数: 3453 | 46 为何,这里很明显,linux是好的,mac的不好,因为改了不属于这个vector的地址
【在 f*******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 如何吐槽? : 楼主还是用java吧,c艹不适合你
|
e*********6 发帖数: 3453 | 47 请明示。
这里边肯定库和定义不一样,但是Mac用了g++的命令却给出不一样的结果,很奇怪
【在 f*******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 如何吐槽? : 楼主还是用java吧,c艹不适合你
|
C********n 发帖数: 150 | |
T******7 发帖数: 1419 | 49 try to understand what is undefined behavior. |
e*********6 发帖数: 3453 | 50 谢谢。
这算是个undefined的behavior,相当于法律没有规定,但是GNU g++已经有实践了,相
当于其他法院已经有了判例,为什么苹果不遵守呢
【在 T******7 的大作中提到】![](/moin_static193/solenoid/img/up.png) : try to understand what is undefined behavior.
|
|
|
e*********6 发帖数: 3453 | 51 谢谢推荐.
我所诧异的是【】的操作,尽管是undefined,但是为了后来的苹果不跟着前边的GNU一
样走呢
【在 C********n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : http://stackoverflow.com/questions/3056597/are-vectors-more-rig
|
f*******t 发帖数: 7549 | 52 GNU怎么做跟apple有什么关系?为什么apple一定要follow? |
e*********6 发帖数: 3453 | 53 gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自
立山头当大哥,所以才说被苹果惊呆了
【在 f*******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : GNU怎么做跟apple有什么关系?为什么apple一定要follow?
|
f*******t 发帖数: 7549 | 54 行业标准是undefined。另外apple我行我素多年了,有什么好纠结的?
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
e*********6 发帖数: 3453 | 55 这就好比红灯停绿灯行是行业标准,红灯右转没定义。大家通行办法是按照stop sign
处理,唯独苹果是直接走
【在 f*******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 行业标准是undefined。另外apple我行我素多年了,有什么好纠结的?
|
g*****g 发帖数: 34805 | 56 Undefined就是undefined,写了undefined出了bug 都是骂程序员,没有骂编译器的。
这就如绿灯过马路不看路可以,红灯右转你也不看,撞死活该。
sign
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这就好比红灯停绿灯行是行业标准,红灯右转没定义。大家通行办法是按照stop sign : 处理,唯独苹果是直接走
|
c***r 发帖数: 4631 | 57 装个gcc不就得了。
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 如果我想Mac下的g++和linux下的有同样的性质,应该怎么改flag?
|
l*****z 发帖数: 3022 | 58 果家自己是用clang+llvm 不用gcc 或 g++
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这就好比红灯停绿灯行是行业标准,红灯右转没定义。大家通行办法是按照stop sign : 处理,唯独苹果是直接走
|
e*********6 发帖数: 3453 | 59 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
【在 l*****z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 果家自己是用clang+llvm 不用gcc 或 g++
|
h******n 发帖数: 2795 | 60 其实,Apple C(C++)编译器跟GNU GCC几乎是一样的。
你这段代码,很可能在Linux下也能通过。但在,MS Visual Studio C++上就通不过。
我前几天遇到很类似的代码(是别人写的),其中的一个subroutine,在一个特例情况
下(i=0),给开的1D数组大小是0,但程序默认给a[0]赋值。这个程序在RHEL 6.7下成
功运行。但是,我搬到Windows下来,则运行出错。通过debug,发现此处出错。
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
|
|
i*****r 发帖数: 265 | 61 又不是java,为啥要报错。segfault或者过了都可以。 |
b***i 发帖数: 3043 | 62 这个应该和操作系统对内存的保护有关,和g++无关
用at可以查边界
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
y*j 发帖数: 3139 | 63 C++的原则是allow shooting his own foot. 这里gcc的处理是不符合标准的,
[在 ericzhang86 (eric) 的大作中提到:]
:【 以下文字转载自 Apple 讨论区 】
:发信人: ericzhang86 (eric), 信区: Apple
:........... |
d****i 发帖数: 4809 | 64 这个不能怪Apple,C++的标准对于vector的operator[],如果越界的话,就是
undefined behavior。看一下C++的manpage:
http://www.cplusplus.com/reference/vector/vector/operator%5B%5D
Portable programs should never call this function with an argument n that is
out of range, since this causes undefined behavior.
在Linux下就会seg fault, 而在OS X下,苹果就仁慈的给了个垃圾数值的结果,只能说
苹果的implementation太委婉了一点。
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
d****i 发帖数: 4809 | 65 很好奇如果用Mac OS X下的Clang编译后运行的结果是怎样的?哪个装了Clang编译器的
来说说? |
f*****r 发帖数: 754 | 66 选择不同的dialect就会有不同的结果
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 谢谢。 : 这算是个undefined的behavior,相当于法律没有规定,但是GNU g++已经有实践了,相 : 当于其他法院已经有了判例,为什么苹果不遵守呢
|
d********g 发帖数: 10550 | 67 Clang/LLVM才是趋势吧。本来BSD系的就不怎么鸟GNU/Linux,FreeBSD不久前也全线抛
弃GCC了
OS X:
$ g++ --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx
-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix
FreeBSD:
$ clang --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
GPL不是啥灵丹妙药,open source也并非GNU的天下
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 【 以下文字转载自 Apple 讨论区 】 : 发信人: ericzhang86 (eric), 信区: Apple : 标 题: 被苹果给惊呆了!! : 发信站: BBS 未名空间站 (Fri Oct 23 17:06:50 2015, 美东) : int main(){ : vector a(10, 5); : a[11] = 100; : } : 这个程序,苹果自带编译器居然给不出正确的结果来。 : 应该是vector越界,runtime error,但是苹果的g++照样能用给出结果来。
|
d********g 发帖数: 10550 | 68 GNU不是啥行业标准,Linux才是BSD的小弟,Clang/LLVM相比GCC是长江后浪推前浪。
GCC爱怎么玩是它自己的事,就好像MS、Intel的编译器也一直夹带私货
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
k***0 发帖数: 1381 | 69 井底之蛙,c++这块gnu算个鸟蛋行标,鬼才follow gnu呢
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 谢谢推荐. : 我所诧异的是【】的操作,尽管是undefined,但是为了后来的苹果不跟着前边的GNU一 : 样走呢
|
k***0 发帖数: 1381 | 70 谁告诉你gnu是行业标准的。你知道当初#pragma在gn下是啥么
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
|
|
t*********r 发帖数: 2431 | 71 什么神经病逻辑,undefined就是undefined,怎么implement都可以。g++照你说的这么
牛逼有本事把它改成defined
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 谢谢。 : 这算是个undefined的behavior,相当于法律没有规定,但是GNU g++已经有实践了,相 : 当于其他法院已经有了判例,为什么苹果不遵守呢
|
d****i 发帖数: 4809 | 72 FreeBSD把它的默认的cc从GCC改成clang是有原因的,主要是GCC采用GPL license,和
FreeBSD的BSD license的完全自由随便自个儿改的理念不一样。而并非clang比gcc好。
实际上gcc还是比clang要成熟稳定很多。
gxx
【在 d********g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : Clang/LLVM才是趋势吧。本来BSD系的就不怎么鸟GNU/Linux,FreeBSD不久前也全线抛 : 弃GCC了 : OS X: : $ g++ --version : Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx : -include-dir=/usr/include/c++/4.2.1 : Apple LLVM version 7.0.0 (clang-700.1.76) : Target: x86_64-apple-darwin15.0.0 : Thread model: posix : FreeBSD:
|
d********g 发帖数: 10550 | 73 FreeBSD之前一直被困在GPLv2,导致GCC不能升级到最新的用GPLv3的版本。而Clang直
接把那个旧版的GCC秒成渣了
FreeBSD不愿意随便用GNU的东西,虽然有些东西GNU做得好一点比如GNU grep就比较快
【在 d****i 的大作中提到】![](/moin_static193/solenoid/img/up.png) : FreeBSD把它的默认的cc从GCC改成clang是有原因的,主要是GCC采用GPL license,和 : FreeBSD的BSD license的完全自由随便自个儿改的理念不一样。而并非clang比gcc好。 : 实际上gcc还是比clang要成熟稳定很多。 : : gxx
|
v*****r 发帖数: 1119 | 74 背楼主的逻辑惊呆了,还是转行吧,你不适合当程序员
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
v*****r 发帖数: 1119 | 75 背楼主的逻辑惊呆了,还是转行吧,你不适合当程序员
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : gnu是大哥,是公认行业标准。apple是后来者是小弟。apple不follow就是apple打算自 : 立山头当大哥,所以才说被苹果惊呆了
|
n******7 发帖数: 12463 | 76 别这么说
他本来就不是程序员
大家再这么嘲讽的话,楼主又要自删主贴了。。。
【在 v*****r 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 背楼主的逻辑惊呆了,还是转行吧,你不适合当程序员
|
C********n 发帖数: 150 | |
c***r 发帖数: 4631 | 78 #include
int main(int argc, const char * argv[]) {
std::vector a(10, 5);
a[11] = 100; //Program ended with exit code: 0
//a.at(11) = 10;//libc++abi.dylib: terminating with uncaught exception
of type std::out_of_range: vector::_M_range_check Program ended with exit
code: 9
return 0;
}
【在 d****i 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 很好奇如果用Mac OS X下的Clang编译后运行的结果是怎样的?哪个装了Clang编译器的 : 来说说?
|
k****z 发帖数: 550 | 79 行业惯例就是undefined,意思是编译器不应该做边界检查。
如果gcc真的每次作边界检查,那是完全错误的行为,因为增加代码白白浪费了cycle,
也可能跟某种假定不做边界检查的代码会有兼容问题。(在历史上有很多代码用这种那
种trick作系统级别的行为)
正确的做法是不做边界检查,由程序员自己负责。
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
g*********e 发帖数: 14401 | 80 lol
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 他用可以理解,规则上没问题,就是他不按照行业惯例follow gnu
|
|
|
i****k 发帖数: 668 | 81 瞎扯,按stop sign处理是交规规定,没吃过这个ticket吧?
sign
【在 e*********6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这就好比红灯停绿灯行是行业标准,红灯右转没定义。大家通行办法是按照stop sign : 处理,唯独苹果是直接走
|
k**********g 发帖数: 989 | 82 use vector.at, which has bounds check.
index operator has no bounds check.
Bookmark this website: http://en.cppreference.com
If you program in C++, you can't rely on your memory. You must check the
reference documentation often.
http://en.cppreference.com/w/cpp/container/vector/at
http://en.cppreference.com/w/cpp/container/vector/operator_at |