云风的 BLOG: 终于不用 VC 了

最近一年半做的主要项目是跨平台的。但是只是说说，还没真的去试着在别的平台上 run 起来。因为我们做的是二进制复用，目标模块文件是自定义格式，所以也不太在乎编译器。原计划是在 Windows 下开发，用 VC 编译的。

最近几天真正开始做跨平台了，想来想去，还是改用 gcc 的好。废弃 VC 倒不是因为它不好，而是想买一台 Mac mini 放在家里用用 :D 一直家里都没买电脑，我也不用笔记本，回家就是打游戏和睡觉。到时候有了机器，在 Mac OS 上自然是没有 VC 用了。

所以，我的跨平台目标就定在了 win32 、freebsd 、linux 和 macosx 。当然，目前我的测试环境只有 win32 和 freebsd ，这几天就在把这两个搞定。

原来的 build 工具是用的 bjam ，这个是 05 年之初选定的。前段时间反省了一下，又考察了最近两年新出的一些 build 工具后，最后还是决定改回 gmake 。到了今天，我在 windows 下的开发环境就成了 gcc(mingw) + gmake + insight 。

今天主要是试了下 insight ，这个 gdb 的图形外壳还是很好用的。唯一美中不足的是：我在注册表 HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug 中把它定为默认调试器后，似乎总不太对劲。 gdb 在 attach 到被调试进程上时老是不正确。反正不能正常工作，也定位不了 source code 。但如果直接用 insight 启动程序则可以顺利调试。

前两天则一直在折腾 gmake ，也是件很痛苦的事情。被折磨了几天后，我放弃了一开始就写出一个通用的 Makefile 模板，打算随着项目进展一点点改进。

gcc 倒是这半年一直在 freebsd 下用，只是用的不够深入。今天想把原来用 vc 编译的东西移植到 mingw 时，就好好研究了一下 gcc 的各种选项。对比 VC 的选项，gcc 要丰富和严谨的多。以前 vc 的命令行用的挺熟，一下子换到 gcc 还是有一点点不适应。

最后，留个自己的一个大工程：打算把项目已有的 C++ 代码全部拿 C 改写一遍。没办法啊，我又爱上 C 了 :D 谁叫我精力旺盛呢。

Comments

看了一下时间。写的时候很晚了。

Posted by: 福利工口姬 | (47) April 16, 2014 04:38 PM

著名的开源图形图像渲染引擎Blender 3D有一个分支项目BGE(Blender Game Engine),用Python做脚本就可以实现高级游戏逻辑.另外Blender是跨平台的,官方也有很多Demo,包括微电影和小游戏.好莱坞的一些大片比如变形金刚和2012都用到了这款引擎.

Posted by: 米奇 | (46) April 22, 2012 09:11 PM

终于明白了为是么云枫的团队开发游戏速度越来越慢，原来是因为放弃了c++改用c的缘故。说点让你丧气的话，对于个人来说用什么无所谓，作为一个团队领袖，你太爱钻技术了，你只适合作技术专家，作为开发一个游戏项目，选用c++比选c有1万个理由。

Posted by: arcnode | (45) April 29, 2009 11:59 PM

哈哈，我把java的胜利归功于eclipse。确实同样的功能java需要敲的东西少太多了。用java或者python做服务器端可以让人晚生好几年白发。

Posted by: serenade | (44) February 23, 2009 04:33 PM

没有为什么，mingw 对我来说显得轻量一点而已。我们的项目用 cygwin 也可以编译的。而且现在几个开发人员是直接在 linux 下编译调试，无所谓选 cygwin 还是 mingw 。要比开发工具之丰富，我想还是 linux 下更丰富一些。

Posted by: Cloud | (43) March 30, 2008 05:08 PM

云风，为了跨平台，您选择了MinGW，实际上还有Cygwin也是可以跨平台的，而且我个人感觉Cygwin工具更加丰富一些，能谈谈您为什么选择MinGW吗？

Posted by: perlma | (42) March 30, 2008 04:51 PM

我错了，我不应该指鹿为马。

Posted by: Atry | (41) September 11, 2007 07:11 PM

前段时间boost的mail list上面讨论要把boost迁移到cmake上面去。

Posted by: Atry | (40) June 28, 2007 01:14 AM

To Ricepig again: 之前的留言有失偏颇，作为一个框架，多少都是存在IoC的，asio也是如此，更不用说asio所采用的Proactor模式。不过，有鉴于你是.NET专家，看到你说IoC，第一反应就是spring之类IoC容器（.NET是否有好用的IoC容器我不大清楚）:D To Cloud: bjam的这些缺点确实令人恼火，尤其是邮件列表上的冷淡，跟asio列表上的热情实在是天壤之别。如果bjam能够包含持续构建支持（像cmake那样），可能会更实用和优秀。

Posted by: Rhythm | (39) June 4, 2007 10:06 AM

bjam 用了两年，虽然用熟了，但是还是放弃掉换用 gmake :D 这个东西初用起来很不错，理解后按自己的想法写点扩展也不难。但是想做更复杂的事情就非常头大了。绕了一圈回来，还是 make 最直接。 ps. bjam 的社区不太活跃，向 maillist 写过几次信都没什么人回应。除了 boost 自己，还真没看啥有名的项目用。所以目前的一切功能都是为 boost 自己服务的。

Posted by: Cloud | (38) June 3, 2007 12:39 PM

To Ricepig: 没想到在这里也看到你 :D C++和Java/C#之争基本上就是宗教战争，不同场合不同结论。我不是很清楚为什你会得出Asio有IoC的结论，但是asio确实是一套相当精巧的C++网络库，最近一直在用它做项目，感觉非常好，性能也很能满足需求。但是C++确实是我所熟悉的最复杂的语言，如果要求整个团队都使用C++，尤其是使用boost这样的库来进行开发的话，对团队成员的C++素养要求相当得高，恐怕要在一个公司里凑齐十几个石老师这样的“模教”教众，还是相当有困难的 :D To 云风：若干次搜索bjam的内容，都找到你的blog，因为我在用vim+bjam+boost+asio进行服务器项目的开发。前面几位的评论很对，vim是相当好的IDE，只要用户找对了各种插件并且乐意熟记各种组合键 :D

Posted by: Rhythm | (37) June 3, 2007 12:18 PM

我机器里装有NOTEPAD++和VIM，但是VIM一直没有用上手。

Posted by: func | (36) May 3, 2007 05:23 PM

notepad ++ ，我也喜欢。

Posted by: cofyc | (35) May 3, 2007 10:25 AM

这跟编译器对C++标准支持得怎么样没什么关系，你要是把《Programming Windows》里的代码都用MinGW编译运行一把，就能体会到我说的什么了

Posted by: missdeer | (34) May 3, 2007 01:38 AM

我是俗人，用 notepad ++ :D

Posted by: Cloud | (33) May 2, 2007 10:17 PM

VC下开发的程序在MinGW下编译运行有问题，应该不是MinGW的错吧。反过来问题一样存在;-) 主要原因是大部分编译器并不完全遵循C/C++语言标准。好像VC不遵循的更多些。

Posted by: phoolimin | (32) May 2, 2007 09:26 PM

vim确实不是试试就行的，它需要一定的时间才能上手。不过一旦用熟了它，你就会发现它非常强，甚至会使你对其他编辑器不屑一顾，呵呵。

Posted by: phoolimin | (31) May 2, 2007 09:17 PM

另外再抱怨一下，MinGW很难用啊，不是说它没有好用的IDE，而是用它写出来的程序运行时总是出现莫名其妙的问题，一模一样的代码在VC下面编译完运行时都好好的，呼呼

Posted by: missdeer | (30) May 1, 2007 10:54 PM

C也有很高质量的库，但是风格不一样。ARP也很简洁，我感觉质量比ACE高。

Posted by: Atry | (29) May 1, 2007 12:51 PM

用C++是因为想用STL和Boost，呵呵，C没有这样强劲的库 ACE就算了，太大太复杂

Posted by: missdeer | (28) May 1, 2007 11:42 AM

vim不是试试就行的，我试过，不行。 vim更像是劲乐团那样的游戏，需要手指很强。

Posted by: Atry | (27) April 30, 2007 11:50 PM

另外写跨平台的Makefile 还是用automake+autoconf+M4方便些。

Posted by: liang | (26) April 30, 2007 08:28 PM

IDE试试vim。不比eclipse,vc差。

Posted by: liang | (25) April 30, 2007 08:27 PM

做普通的应用，二进制复用真的那么重要么？

Posted by: Alex | (24) April 30, 2007 04:47 PM

云风做二进制复用干的是重复发明轮子的事情。自己写LoadLibrary…… 不知道为什么不直接用wine

Posted by: Boost的支持者 | (23) April 29, 2007 10:23 AM

1. Boost.Asio没有用IoC模式，恰恰相反，Boost.Asio把代码的主逻辑交给用户来决定，Boost.Asio尽量只作为一个非常轻量级的功能库而不是框架。 2. 把ACE这种庞大臃肿的糟糕东西和Boost相提并论简直是对Boost的侮辱。 3. 标准库+Boost的确不够完整。语言相关的库虽然很完善了，但功能则不足。没有logging库，没有XML DOM库，没有GUI库，没有像OpenGL那样的底层3D处理库，没有像Java3D那样的高层3D引擎，没有Web Server库。 4. 模板使用有两种，一种是进行编译时运算，这个调试主要靠static_assert，依靠编译时编译器错误来调试。另一种是把模板参数作为一个编译时的接口来使用。执行时的接口叫interface，编译时的接口叫concept。基于concept编程和云风所说的二进制复用是两种截然不同的思路，concept只是源码的附庸。基于concept编程的调试和不用模板是一样的，至少在VC和Eclipse的CDT里面是一样的。

Posted by: Boost的支持者 | (22) April 29, 2007 10:20 AM

云风，请教一下，如何做到二进制复用？不同平台的可执行文件格式和动态链接库的格式都不同啊~~~

Posted by: Ricepig | (21) April 29, 2007 04:38 AM

to boost fan: 从你的叙述来看，boost:asio的精妙就在于它的IoC机制？另外，好而完整的库是可以减少代码量的，但是C++有个问题就是标准库太小，标准库+ACE+Boost还是比Java或者.net提供的类库小得多得多。另外，使用boost，可以减少代码量，但是增加了调试难度。C++的模板机制是在编译器展开，不太好调试，尤其用了很多模板技巧的情况下。另外，Eclipse的代码感知和代码完成提都别提，速度极慢，做的也不完全。vs2005和vs2003+va做的就很好。

Posted by: Ricepig | (20) April 29, 2007 04:36 AM

使用vc + csm 是宿主语言和脚本语言的最佳拍档,网址是csm.zg66.com

Posted by: waynezhang | (19) April 29, 2007 03:03 AM

二进制模块的复用机制直接用Java不是更好吗？一直想不明白为什么C/C++程序员总是不接受Java。极端情况下，C++的代码长度有可能比Java更短，但是击键次数Java一定比C++少，因为Java的IDE（我说的就是Eclipse）能帮你少击很多次键。

Posted by: Boost的支持者 | (18) April 29, 2007 01:02 AM

to Alex: 看到他最后也提到asio，感到很欣慰。Boost.Asio代码质量之高简直是前所未闻的。衡量代码质量的标准是什么？简洁。接口简洁，实现简洁。Boost.Asio之简洁简直到了无法再减少一行代码的程度。 Boost.Asio代码本身不涉及线程。一个低层网络库不涉及线程是正常的，但是一个高层网络库不涉及线程就不得不惊叹其设计之精妙了。尤其是Boost.Asio本身还是一个线程池的实现，不涉及线程但是却实现了一个线程池。实质是把线程这种资源的分配和使用交给外部用户，这种做法和C语言的原则不是也是一致的吗？再有，Boost.Asio本身也不涉及缓冲区的管理，作为一个高层网络库，其本身却根本不分配不管理任何缓冲区。这又是既带来了简洁又带来了灵活度。底层C语言常常一个指针加长度传递缓冲区，的确是简洁，但这是危险又麻烦的简洁。而boost::asio::buffer并没有让接口更复杂（甚至还减少了一个参数），但是却安全以及减少了代码量。使用boost这样的高质量库一定是可以减少代码长度的，敲键次数少就是代码质量高（这一点我和云风观点完全不同）。boost确实有额外的复杂度，但是并不是单个接口的复杂度，而是学习一些通用的知识的复杂度。模板的知识学习一次就可以用一辈子，而单个接口的复杂度则有一部分可以转移到语言特性，而语言特性是通用的。所以我坚持认为高质量的C++接口是比高质量的C接口更简洁的。

Posted by: Boost的支持者 | (17) April 29, 2007 12:58 AM

原来的 build 工具是用的 bjam ，这个是 05 年之初选定的。前段时间反省了一下，又考察了最近两年新出的一些 build 工具后，最后还是决定改回 gmake 。前段时间反省了一下？从C++反省C，可以说是C简单易懂，C++的确有些东西需要学习成本。而从bjam反省到gmake。这个爱屋及乌到了这种程度实在令人费解。

Posted by: Boost的支持者 | (16) April 29, 2007 12:39 AM

我目前的倾向重点不在于 C 还是 C++ 或是脚本语言。更为看中的是二进制模块的复用机制。至于里面是 C 还是 C++ 实现的是次要的。但是写了这些年程序后，觉得用 C 会比用 C++ 设计出更为简洁的接口，而实现多出来只会是一些键击次数罢了。而用 C 去模拟 C++ 已有的东西，并非一个正确的方向。

Posted by: Cloud | (15) April 28, 2007 08:17 PM

MingGW好像可以让GCC用%I64d，而GCC好像只能long long，感觉还是有点点不“兼容”:-)

Posted by: 极光炫影 | (14) April 28, 2007 07:46 PM

在另外一篇文章中(http://op.closedformodification.com/2006/09/21/game-developer-rant)，记载了2005年GDC上的一些对话，提到了为什么游戏开发越来越困难，周期越来越长。然后就说那是因为程序员们太不称职了，大家不知道如何正确写代码。然后半开玩笑的说，要是让老板在代码里搜一搜"fuck", "shit", "god", "“oh .. this sucks but I put it here”等等，就可以知道代码质量如何了。 gamedev.net上，有关语言之争也很多，有人甚至做了一个列表，以后每次有人问“哪个语言好啊”，然后就把这个列表贴在那里: http://www.gamedev.net/community/forums/topic.asp?topic_id=445201 Original post by Promit Here's some reading material. 1) Professional Games Made In C#? 2) Java for game development? 3) Java----C/C++ 4) c++ or c# 5) Question about Java Vs. C# Vs. C++ 6) Java Games? 7) Java is fast? 8) Secondary Language:VB or Java? 9) What makes C++ so powerful? 10) C# games and cheating... 11) Is C# good enough for system utility programming 12) MC++ vs. C# 13) Which language is best for a 3d Games Engine? 14) C# vs C++ as a choice for development 15) Is Java the Future? 16) why C# and not Java? 17) What do you think of the D language? 18) my c++ d c# benchmark! 19) The Definitive Guide to Language Selection 20) Sharp Java 21) C++ or C#? (p.s. 这个列表最先是Promit搞的，这哥们原来是gamedev.net的一个普通成员，后来加到staff里了) 最后，引用wow里10多级在十字路口一个牛头撒满NPC给我任务时说的: “我们所处的这个时期如风云般变化无常”

Posted by: Alex | (13) April 28, 2007 07:30 PM

晕，上篇文章可能太长了，说放服务器去了。这里拆开好了。关于是否应该用C++作为游戏开发的主语言，也有很多争论。下面列举一二: The Software Crappiness Factor (http://aigamedev.com/Blog/2006/09/30/the-software-crappiness-factor) 这篇文章的作者认为C++的确太复杂了，即使是商业上卖的很好的C++游戏引擎都十分难易理解和使用。而开源的一些c++引擎似乎好用些，但功能有欠缺。这哥们在文章中还引用了其它一些文章，也介绍一下： Why C++? (http://gamearchitect.net/Articles/WhyC++.html) 这篇文章的老兄认为，相比C来说，C++的确十分复杂，但如此复杂是有道理的。而且，据他看过的一些用C实现的游戏项目，无一实现了C++本身就有的一些机制，例如虚函数等等，未必比直接用c++来得简单清晰。C并不比C++更加高效、强大和安全。除此之外，很多游戏相关的厂商都提供C++的工具包，使得使用其它语言的弟兄们日子难过。他甚至据了个例子，说有个游戏工作室自己实现了一套类LISP的语言，甚至编译器都有。结果被sony收购后，不得不转到c++去，因为大家都用c++。当然，这篇文章的作者并不否认C++不适合快速迭代，所以和脚本配合再好不过了。

Posted by: Alex | (12) April 28, 2007 07:29 PM

关于是否应该用C++作为游戏开发的主语言，也有很多争论。下面列举一二: The Software Crappiness Factor (http://aigamedev.com/Blog/2006/09/30/the-software-crappiness-factor) 这篇文章的作者认为C++的确太复杂了，即使是商业上卖的很好的C++游戏引擎都十分难易理解和使用。而开源的一些c++引擎似乎好用些，但功能有欠缺。这哥们在文章中还引用了其它一些文章，也介绍一下： Why C++? (http://gamearchitect.net/Articles/WhyC++.html) 这篇文章的老兄认为，相比C来说，C++的确十分复杂，但如此复杂是有道理的。而且，据他看过的一些用C实现的游戏项目，无一实现了C++本身就有的一些机制，例如虚函数等等，未必比直接用c++来得简单清晰。C并不比C++更加高效、强大和安全。除此之外，很多游戏相关的厂商都提供C++的工具包，使得使用其它语言的弟兄们日子难过。他甚至据了个例子，说有个游戏工作室自己实现了一套类LISP的语言，甚至编译器都有。结果被sony收购后，不得不转到c++去，因为大家都用c++。当然，这篇文章的作者并不否认C++不适合快速迭代，所以和脚本配合再好不过了。在另外一篇文章中(http://op.closedformodification.com/2006/09/21/game-developer-rant)，记载了2005年GDC上的一些对话，提到了为什么游戏开发越来越困难，周期越来越长。然后就说那是因为程序员们太不称职了，大家不知道如何正确写代码。然后半开玩笑的说，要是让老板在代码里搜一搜"fuck", "shit", "god", "“oh .. this sucks but I put it here”等等，就可以知道代码质量如何了。 gamedev.net上，有关语言之争也很多，有人甚至做了一个列表，以后每次有人问“哪个语言好啊”，然后就把这个列表贴在那里: http://www.gamedev.net/community/forums/topic.asp?topic_id=445201 Original post by Promit Here's some reading material. 1) Professional Games Made In C#? 2) Java for game development? 3) Java----C/C++ 4) c++ or c# 5) Question about Java Vs. C# Vs. C++ 6) Java Games? 7) Java is fast? 8) Secondary Language:VB or Java? 9) What makes C++ so powerful? 10) C# games and cheating... 11) Is C# good enough for system utility programming 12) MC++ vs. C# 13) Which language is best for a 3d Games Engine? 14) C# vs C++ as a choice for development 15) Is Java the Future? 16) why C# and not Java? 17) What do you think of the D language? 18) my c++ d c# benchmark! 19) The Definitive Guide to Language Selection 20) Sharp Java 21) C++ or C#? (p.s. 这个列表最先是Promit搞的，这哥们原来是gamedev.net的一个普通成员，后来加到staff里了) 最后，引用wow里10多级在十字路口一个牛头撒满NPC给我任务时说的“我们所出的这个时期如风云般变化无常”来结束上面那长长的文字。

Posted by: Alex | (11) April 28, 2007 07:27 PM

上篇回复中的一个链接不全。这个是完整的: http://redmonk.com/sogrady/2005/04/26/javac-to-c-from-one-complex-language-to-another

Posted by: Alex | (10) April 28, 2007 06:57 PM

关于C到C++再回到C，前两天发现国外也有一哥们这么干过，不同的是，这家伙最近又从C回到了C++。我在网上找到了他的一些历史记录，可以看到他在不同时期的想法。挺有趣的： Christopher Baus 2005年，他在一篇文章的回复中说：Our opinions aren’t as far apart as you might think. Complex doesn’t explain what is going on in the language right now. Core language constructs are being redefined via libraries. Some people see this as the future. I feel it is hurting my productivity as C++ becomes more read only. Throw in what MS is doing with C++/CLR and you have a recipe for a language that nobody really understands. What I see happening is developers such as myself are going to go in two directions. 1) C for low level stuff where performance matters (eg implementing language run times). 2) Scripting languages like Python, Ruby, and PHP for everything else. 在稍后的回复中，他补充道: Here’s Google’s Joe Beda’s take on C++ http://www.eightypercent.net/Archive/2005/03/26.html#a237 I tend to agree with most of it. (原文:http://redmonk.com/sogrady/2005/04/26/javac-to-c-from-one-complex-language-to-another/) 那时候，他觉得C++过于复杂，倾向于C+脚本的方式。 2007年4月，在他的网站上，他说: (标题是Chris Kohloff's Thinking Asynchronously) I found Chris Kohloff's blog last night: Thinking Asynchronously in C++. Not too many entries there yet, but I have a lot of respect for the work Chris has done on Boost asio, so I hope to see more. Asio is a well researched and implemented cross platform network library which I believe is the best chance for C++ to regain its position as a first class network programming language. I've come full circle and I'm back working in C++. I started to lose my C++ religion a couple years back when template mania was at its height. The new found acceptance of type erasure (a fancy way a of saying fewer types is sometimes preferable) and the current work being done by the standard's committee on concept checking (as a language feature) are starting to win me back. I enjoy working in C++. When I'm working in C++ I feel like a craftsman. Languages like Python (which I also enjoy) often leave me feeling like a hacker (which isn't always bad). C++ is the language in which I can best express myself. Plus deterministic destruction makes a whole lot of sense when working with network resources. Anyways, if you are into C++ network programming I highly recommend taking a look at asio, and encouraging Chris to update his blog. 可以看出，这哥们又回到C++的怀抱了。。。

Posted by: Alex | (9) April 28, 2007 06:54 PM

恭喜云风大哥,GCC的确比VC爽.又回到开源阵营啦 hoho

Posted by: Shawn the ROck | (8) April 28, 2007 04:30 PM

使用C编译的话至少可以觉得速度很爽。而且包装一个好的跨平台库之后就可以“一次编写，到处编译”。

Posted by: zelor | (7) April 28, 2007 04:21 PM

code::blocks 已经比当初刚推出的时候完善很多了，可以看看。

Posted by: yayv | (6) April 28, 2007 01:12 PM

现在很少熬夜，正常作息。11 点半起床。我觉得用什么编译器都好，习惯就行。

Posted by: Cloud | (5) April 28, 2007 12:11 PM

IDE试试Eclipse

Posted by: 不空 | (4) April 28, 2007 10:54 AM

云风好像有在12点到2点之间写blog的习惯，不知道早上几点起床……