引用:

原帖由 zy_zlj 于 2012-11-18 22:31 发表
用完mac以后你才会体会到windows有多好，虽然要做mac开发，但是比起狗屎的xcode我宁愿在windows下写好，直接拿过去编译，调试，单位的mac基本没什么人用

哈哈哈哈我这正好相反，windows上连make都没法用，vs连c++即时编译报错都没有，再加上巨硬加编译器跟llvm比简直就是龟速

引用:

原帖由 刘泪 于 2012-11-19 13:06 发表

nmake又不是放那做摆设的，你非要用gnu或其它的make那是真没法用(假定你不知道GNU这东西的话)。
话说你还没用过08之后的vs吧……从08开始每个版本c++部分都进步巨大，2010开始目测语法错误90%已经能在编译前提示了 ...

我要编译的库make限定，cmake都不行，更别说什么nmake，我自己写东西都用rake,说到这我又要说windows连个rvm都没有了
我用的就是10和12，我指的是即时编译，类似vs里面c#的效果，这个你比较一下就知道区别了
llvm编译速度是无可争议的快，至于生成目标码效率，llvm-gcc和clang是两个世界，其次不同平台下也不好比较，要知道Mac的llvm早已经到4了，官方的release还在3.2，就算是在windows平台下比较，2.x的llvm-gcc也只是略逊msvc10，比gcc要好
最后要说的是，对于llvm来说，编译速度和优化质量都是浮云，llvm真正的优势的可扩展性和模块化设计，跟webkit是一个道理。
大门牌不开源的不说什么扩展性了，Gcc这货连后端跟优化都是绑一起的，不彻底重构的话随着clang日益成熟劣势只会越来越大

[ 本帖最后由 mayokaze 于 2012-11-19 14:45 编辑 ]

我现在的毕设就是跟llvm打交道，前端用Haskell的happy和Alex，运行时用ruby写编译成llvmbc，代码生成全部用llvm Haskell binding. 这个世界上有且仅有llvm有这样的flexibility和rubustness

引用:

原帖由 刘泪 于 2012-11-19 15:12 发表

呃……等等，这和mac的工作效率有什么关系？而且……真的对实际项目有帮助？为什么不全程采用ruby或haskell

没关系...只是前面有人提到Mac下的（C/C++）开发环境糟糕，我看不下去就说几句
前端用Haskell的原因是Haskell语法天生对应ast，不用再写语法树,对应的lexer和parser很成熟，llvm-bindings很活跃，支持最新版本的llvm
代码生成用llvm是因为没有比llvm更方便的（跨平台）后端优化＋本地代码生成解决方案
运行时用ruby是因为ruby是一个很方便的快速原型语言，而且基于llvm的rubnius非常成熟，我不用花大量时间用c++构建运行时
全程用Haskell或ruby只适合快速原型，无法成为一个严肃的项目，全程用c/c++又过于繁琐

引用:

原帖由 arcam 于 2012-11-19 16:53 发表


那个人只是说Xcode比较糟糕吧。和你说的有点偏题了。

相对于win本装linux，mac好在不用折腾驱动之类，不用为散热，待机时间，桌面环境这些搞得头疼。

而且本子本身质量也好。

我说的就是xcode和vs.我不做iOS开发，大家常批的Xcode崩溃我没遇到过，所以还真没觉得Xcode不好用，一个是我前面说了的即时编译报错和智能补完，还有就是Xcode下你拖进去一个库就自动链接了，不用再写pragma或是配置ld参数,类似的小细节有很多，可以看出vs对c++不上心.语言规范上，从vs2012支持c++11看得出微软在进步，但是这个年月了还不支持c99是要闹哪样。还有启动速度，简直就是chrome和装了几百个插件的firefox的区别。编译速度和从makefile导入工程我前面已经说了。

引用:

原帖由 arcam 于 2012-11-19 21:54 发表


用的啥机器？ 最近想从linux换到os x下，为了mbp 13 or 15纠结。

（不要推荐rmbp，预算不足)

15才是真pro,13就算是rmbp也是玩具，hd4000现在连opencl都不支持

引用:

原帖由 lijgame 于 2012-11-20 00:56 发表

给个编译速度比较的网页看看
为毛别人都说是VS的快
http://stackoverflow.com/questions/3752988/gcc-vs-ms-c-compiler
http://www.g-truc.net/post-0372.html

第一个链接说的是gcc，gcc本来就慢，况且人家主要也是说生成的代码执行快，msvc在自家平台后端优化如果比不过gcc的话那vs team早该解散了
第二个链接比的也是生成指令的执行速度，平台是windows，llvm是用的llvm-gcc，版本是2.8
现在Mac的llvm是4.0，c和objc的clang已经非常成熟，这货跟llvm-gcc完全不是一个重量级的对手，不过c++因为历史遗留问题多数情况还是得用llvm-gcc，优化我前面说了平台不同不好比（不过即使是第二个链接msvc占尽好处的情况下也只是略胜），但是编译速度是人都能看出哪个快，不用试别的，就编译个llvm试试吧

引用来源前自己先看明白内容啊....

[ 本帖最后由 mayokaze 于 2012-11-20 01:22 编辑 ]

引用:

原帖由 lijgame 于 2012-11-20 01:33 发表
posted by wap, platform: iPhone

懒得打字而已，用这两个链接说明我的疑问
我自己没感觉编译速度的区别也没留意过，llvm比gcc优秀是公认的，但是没觉得llvm编译速度比vs快，网上也没比较数据，代码优化也没vs高
...

你见过有在windows上用llvm-clang做正经项目的吗？
同理Mac有可能用msvc吗?
关于性能的我勉强找到这个跑分 http://solarianprogrammer.com/2012/10/24/cpp-11-sort-benchmark/，要严格测试不同平台生成代码的执行效率是不可能的，这种测试看看就好
至于编译速度，这么显而易见的东西实在找不到有人蛋疼到拿msvc和clang严格来测试一遍，普遍认为clang是gcc的三倍，你自己试试windows上vs有没有gcc三倍速就清楚了
llvm的优势不是跑分，llvm的优势在哪里看看这几年llvm和相关生态圈的进化速度就知道了，其他编译器要赶上llvm除非推导重来

[ 本帖最后由 mayokaze 于 2012-11-20 02:02 编辑 ]

http://lists.cs.uiuc.edu/piperma ... October/011524.html

关于编译速度的，客官您要的数据，不过都是老版本，凑合看看呵呵算了

引用:

原帖由 karsus 于 2012-11-20 08:08 发表

呵呵，调试上，VS甩xcode一条街松松的

对，这个是真的，不过只论c/c++逐行调试和反汇编调试的话其实从xcode4开始已经没多大差别了，vs强在功能全集成好，例如c++amp可以直接在vs内调试，Mac上写opencl只能手动拷显存过来看数据暴力调试....简直回到60年代....
我个人因为混合编程占绝大多数不tdd会死，剩下的局部调试直接命令行下搞定了对这个需求不大所以才前面没有提这个.

引用:

原帖由 sumeru 于 2012-11-20 16:22 发表

你的工程太小了，Xcode在工业级开发上差不少，慢，卡，死是家常便饭，4比3的稳定性好了一些，不过还是一泡污，所谓llvm那点优势根本可以忽略不计

明显是3比4稳定太多了好吗  3的问题是整体架构还是上个世纪的ide，4总算是现代了，但是（据说）稳定性一直没解决.从c/c++开发来看我所遇到的唯一问题是智能提示吃内存无止尽，但是这个在最新的版本已经改善了，以前16g内存都不够，现在4g内存也勉强能用了，因为这个原因导致的“卡”“慢”关掉这个功能就是了，vs根本就没这个功能，除此之外说xcode比vs卡慢一定是你打开方式不对

引用:

原帖由 刘泪 于 2012-11-21 11:03 发表

别的我还都觉得是嘴炮，毕竟环境不同，我也自己主观的一面。智能提示这东西我已经忍不住了……
你说的vc没有的智能提示到底是什么神奇东西……

vs里面应该叫intellisense，不仅仅是指Auto Completion，vs里面cli和非cli的intellisense根本不是一个东西，装了VA也一样

引用:

原帖由 刘泪 于 2012-11-21 13:36 发表

就说有什么不同吧，实话说，我这个非专业代码工用gcc+vim或其它乱七八糟的各种编辑器东西多，语法提示之类很少享受到（VIM倒确实用Clang配置了自动补全，不过电脑不好所以很少用这东西，你也不喜欢一个点下去硬盘灯 ...

举个例子吧，vs2010里面你头文件写了类的定义，写实现的时候写完函数名没法自动补完参数列表，还有就是文件稍微多点就会变的很卡（与c#相比）.
对c++来说用编辑器＋插件也能实现自动补全，配合自动化脚本＋gdb很多时候确实比ide好用.ide的优势无非就是图形化调试＋智能提示＋一些杂七杂八的自动化配置和集成，对比编辑器的劣势是启动和运行速度，从这四个方面来看只考虑c++我觉得vs对比xcode只能算各有所长.有人不需要代码提示，有人不需要图形化调试，有人不在乎内存泄漏，有人不在乎启动慢编译慢，有人就喜欢把链接写到头文件里面，这么争下去没结果.这个话题就到这里吧.