« 重构 | 返回首页 | IDE 不是程序员的唯一选择(二) »

IDE 不是程序员的唯一选择(一)

我心目中,这篇文章的目标读者应该是在 Windows 下完全使用 Visual Studio 或 Borland C++ Builder (现在还有人在用么?)等系列 IDE 开发软件的 C/C++ 程序员。

我并不打算从 GNU Make 这种工具的使用写起,因为如果以上提到的这类同学如果都开始看 gmake 的文档(现在翻译工作已经有人做了),应当已经脱离了纯粹 IDE 开发的人群。本文只是一篇非常初步的入门文章,如果你已经使用过类似 gnu make 的工具构建自己的项目,那么完全不必看下去了。

不可否认,IDE 对于软件开发领域,是一项伟大的发明。它极大的降低了软件开发的门槛。但是另一方面,IDE 也限制了程序员们创造软件的手段。这些限制还包括了平台限制,工具选择,甚至新的编译技术,编程语言的选择。所以 IDE 绝对不是程序员的唯一选择,如果你现在作为一个程序员,完全不能离开 IDE 工作。那么,是时候接触一些新东西了。

如果你大约知道一点相关的知识,但是对用 make 工具去构建项目充满了鄙视和厌恶,云风不期望通过这篇文章改变你的想法。因为我不想花太多笔墨来介绍其好处。我个人认为,那些好处,一旦你认真的采用这种开发方式,是显而易见的。

阅读本文,云风假设你至少已经了解了下面这些知识:

会使用 Visual Studio 的某一个版本创建一个由 C/C++ 程序构建起来的工程,并正确编译运行它。

知道 Windows 里有一个叫做控制台(或终端)的程序,通常用 Win-R 然后输入 cmd 启动它。

知道最基本的 dir cd mkdir del copy 等 Windows 命令行指令,并了解 Windows 文件系统的基本结构。

基本了解 "环境变量" 这个概念,知道 PATH 这种常见环境变量的用途。

如果你对上述概念不甚了解,请运用你使用 google 的技能把它们弄清楚。然后,我们可以开始了。


读到这里还没有离开的同学,机器上应该装有一份 Visual Studio 。我的机器上就装了两个版本,但是差不多三年没怎么用它们做项目了。一份是 Visual Studio 6.0 ,早几年订购 MSDN 宇宙版送的。另一份是从微软网站免费下载的 Visual Studio 2005 Express Edition 。

我自己做项目现在是用 gcc ,并且向同学们推荐这款编译器。主要原因当然不是其免费,如上所述,我们现在也可以从微软免费获得编译器了。使用 gcc 最大的好处就是,一旦你打算切换到别的平台开发软件,可以不用更改你的使用习惯。就算你不离开 Windows ,也需要它来开发你的 psp ,nds ,手机,pda 等等。另外 gcc 一直在更新,它给你带来的好处是更强大的编译功能。如果你有一天像我一样放弃了 IDE ,Visual Studio 不断升级的 IDE 界面以及更华丽的工程管理方案对你也会毫无意义。

不过现在,我们暂时不要切换到 gcc 下。那样变化太大,反而难以接受。常年使用 vs 培养出来的习惯是很顽固的。等你学会了 make 这类工具,就会发现,其实切换编译器是再容易不过的事情了,到时候爱用啥用啥。


现在进入 cmd 控制台模式。输入 cl 回车。如果你的机器上安装了 vs 2005 ,你应该可以看到

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

如果是 vc 6 那么也大同小异,

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

如果没有出来,可能是环境变量没有配置好。进入 vs 的安装目录(C:\Program Files\Microsoft Visual Studio 8\VC 或 C:\Program Files\Microsoft Visual Studio\VC98\Bin),运行 vcvarsall.bat (vs2005) 或 VCVARS32.BAT (vc6) 即可。实在搞不定就重新安装 vs ,默认安装选项会帮你设置好所有的环境变量。

好了,如果你成功运行了 cl 这个程序,下面的一切都会很顺利。cl 是微软出品的 C/C++ 编译器,就是把 .c 或 .cpp 的源文件编译生成为 PE 文件的工具。常年使用 IDE 的同学也应该注意到它的存在,就是在你使用 vs ide 时,按下 build 的按钮,下面 output 窗口里也会蹦出正在运行 cl 的信息。


现在创建并进入一个工作目录,比如 C:\project\foo ,我们将在这个目录下进行今天的演示。

用你喜欢的文本编辑器在这个目录下编辑一个文件名为 foo.c C 程序。写点 hello world 之内的东西即可。

接下来使用 cl foo.c cl 将为你生成两个文件,一个是 foo.obj 一个是 foo.exe 。我们应该明白这些是什么了。

现在可以试着运行 foo.exe 了,看看是不是你预期的结果?

好吧,对于这种一个源文件就可以搞定的简单程序,我个人认为,无论从任何角度讲,直接使用 cl 都比用 ide 要来的方便。至少我不用构建一个新的工程项目不是?有时候需要写一些实验性的代码,可以把一堆这样的小程序放在一个目录下,只要它们的文件名各不相同就可以了。完全不必在硬盘上留下大堆复杂的目录结构。

但这离构建一个项目还远远不够。通常一个 C/C++ 项目都是由很多个 .c .cpp 源文件,以及若干 .h 构成的。

比如,我们再添加一个 bar.c ,希望把 foo.c 和 bar.c 编译链接到一起。

无论是 cl 还是 gcc ,都支持直接在一个命令行写上多个源文件,然后依次编译并链接成最终的 PE 文件。所以最简单的做法是直接

cl foo.c bar.c

我们会看到, cl 生成了三个文件, foo.obj bar.obj 以及 foo.exe

cl 将 foo.obj 与 bar.obj 链接成了 foo.exe ,这个文件名默认是以第一个输入源文件为参考的。

如果我们想换个最终目标文件名怎么办?查一下 cl 的帮助,输入 cl /? 看看。

/? 是微软风格的命令行求助选项,几乎所有的微软编译工具都支持。如果是用 gcc 则是 gcc --help 。

我们在帮助信息里可以找到,能够用 /Fe 来指定最终生成的 PE 文件名。

现在可以用 cl /Fefoobar foo.c bar.c 试试看了,主要 /Fe 和 foobar 间不要留空格。

现在则生成的是 foobar.exe 而不是 foo.exe 了。


调试怎么办?

我猜用惯 IDE 的同学们现在最想问的就是这个了。如果我再来推荐诸如写 log 这类 “原始“ 调试方法,怕是要被人嗤之以鼻了。vs 的用户们肯定习惯了单步跟踪、设置断点、监视变量,等等这种 ”高科技“ 的调试手段。其实我也喜欢,方便的工具为何不用呢?

调试器的选择并不多,尤其在 Windows 下。但也不是别无选择的。使用 cl 自然就要使用 vs 自家的调试器啦。正如你使用 gcc 就必然选择 gdb 一样。(btw, gdb 习惯后其实并不难用,何况还有 insight ddd 这样的图形界面的选择,只不过他们的表现不如在非 windows 平台上那么好罢了。)

要使用调试器,必须先生成调试信息。对于 cl ,这个编译开关是 /Zi 不太好记,但是用的多了就熟了,一旦忘记了,请用 cl /? 查询。如果以后换成 gcc 那么就是 -g 了。

试试

cl /Zi foo.c

除了原来生成的 obj 和 exe 文件外,cl 还生成了 pdb 文件,这里面就存放了调试信息。当然,如果你用 gcc 的话,是不会有额外的文件的,调试信息就放在 exe 文件内部。

现在开启熟悉的 ide 来调试这个程序,当然这次,我们只是把 ide 当成调试器在用。如果不想使用 VS 的 IDE ,也可以使用微软免费提供调试器 WinDBG ,不过使用稍微麻烦一点,需要自己设定源码以及调试符号文件的路径,这里就不介绍了。

如果是在使用 vs2005 express 版, 请输入 vcexpress foo.exe ;如果是 vc6 的话,输入 msdev foo.exe 。效果都是一样的,都是打开 vs 的 ide 并加载 foo.exe 。

如果你讨厌命令行操作(嘿,同学。你都打算学习怎样不使用 ide 开发项目了,怎么能讨厌命令行环境呢?), 可以先打开 vs 的 ide ,然后从菜单里选择 open ,打开 foo.exe 也可以。

接下来,按一下 F11 (vs ide 默认的 step into 的热键)。看到了什么?foo.c 被打开了,程序运行指示光标停在了 main 函数的第一行。:)


接下来,云风将传授一门关于调试的独门秘籍。

知道调试器是如何实现断点这个功能的吗?其实它偷偷的在你的程序要设置断点的位置放置了一条调试中断指令。在 x86 32 位系统上,这是一条单字节指令,汇编代码是 int 3 。cpu 运行程序的时候,碰到 int 3 就会把控制权交给调试器,当你在调试器中选择继续运行的时候,调试器再将被替换的程序机器指令换回去,让程序继续运行。

知道了这个细节,我们就可以自己提前设置调试断点了。我称它为硬断点。只要程序运行到,就一定会停下来。如果你想在运行期屏蔽硬断点,需要在源码上做一些工作了。

现在在你刚才的 foo.c 的程序入口处加一行 __asm int 3 ( 如果你在用 gcc 可以加 asm ("int $3"); ) 重新用 cl /Zi foo.c 编译一次。然后在命令行直接运行 foo.exe 。

马上,你将会看到一个熟悉的关于程序崩溃的对话框。没关系,它是由你插入的硬断点 (int 3) 造成的。如果你正确安装了 vs ,vs 应该已经把自己设置成系统默认的调试器了。点对话框上的按钮,便将启动 vs 的 ide ,我们会发现程序正好停在了 int 3 那行汇编的地方。现在你可以尽情的单步跟踪了。


写了这么多,似乎还没进入正题。我们一直在玩一些玩具代码和迷你工程。貌似离取代 ide 去工作还很远。只是我今天写累了,还是且听下回分解吧。今天这一篇,让一些完全没接触过命令行编译程序的同学们加深一下,一组源代码是如何生成最终的执行文件,这个过程的理解。达到这个目的就足够了。本质上,IDE 也在做这些事情,作为一个 C/C++ 程序员,怎能对一个天天在用的系统怎样在工作一点都不了解呢?

ps. 希望看到这里的同学不要为在命令行下输入了太多的指令而心烦意乱。或者担心那些命令行参数用完就忘。你知道 windows 下有个叫做批处理的好用的工具么?就是那些后缀为 .bat 的文件。可以把经常输入的指令放在里面,简化日常的命令行操作。如果不知道,那么还请 google 之。

虽然 windows 下的批处理比 *nix 的 shell 脚本弱了上万倍,但毕竟还是可以提高我们的生产力的。在没有介绍 make 工具前,同学们可以先用 bat 文件顶一下。比如将你的工程的编译指令一次性写到一个 .bat 文件里,就不需要每次重新编译都敲上长长的一串编译指令了。

事实上,云风最早从 ide 里出来,就是用批处理来管理自己的工程的。在下一回,本系列将隆重推出更加好用的工具来取代它。

Comments

确实太偏激了。其实我还是喜欢VS IDE 因为VS可以集成了 linux ios windows android 的编译打包功能。 我现在开发android也都是VS开发VS打包VS调试。
这个想法有点偏激,时间就是金钱,请问哪个方法更快,做上层应用的,需要去仔细了解那么多吗,大概了解一下、能解决部分问题就可以了,需要的时候再仔细研究。不然ide的出现是为什么?微软的操作系统有vs,难道其他操作系统就没有ide吗?切换过去还不是一两天就能熟悉的事
顺便说前辈你的这个评论系统有点晃眼啊。很容易分不清posted by xxx 到底指的上面的评论还是下面的评论
这是一个程序员之间广为讨论的悖论:偷懒vs不偷懒。 一面写代码的时候高呼great programmer steals, 一面又说使用别人的劳动成果(IDE也是啊)会变傻。。。 WTF
都是用GCC等工具了,为啥还要在微软的平台而不去linux呢?你不觉得CMD比SHELL更难用吗
IDE太庞大 - 使用命令行; 命令行太繁琐 - 使用脚本来自动化; 写代码不方面 - 脚本集成文本编辑工具(vim, emacs...); 结果是不是从头打造了一个自己的IDE呢? 其实我们本来想要的就是一个高效简洁的IDE而已~~~
vs2008的话,可以用: devenv foo.exe 另外power shell也很强的。
认真学习中,可是我是用vs2005 professional打开编写的foo.exe的时候,总是会报错“无法枚举可执行文件中的资源”,不知道应该如何是好。 如果加上了asm那个部分,确实可以中断,可是显示的是汇编,而不是c的源代码。
同样是效率工具,只是用的场合不一样而已.不过个人觉得先会makefile再用ide可能更好一点. 感觉IDE隐藏了makefile的过程
最近正研究这方面的问题,下了个cygwin用呢.以前感觉make挺酷的,现在感觉IDE效率真不是一般的高(代码的自动完成,智能提示). 虽vs然组织编译的时候比较傻(浪费时间).
以前没用过 windbg ,刚才下载用了一下,除了要手工设置一下符号路径,别的还行。我改改上文吧。 不过我对这个东西没太大兴趣 :)
“谁让微软没有提供单独的调试器呢?” 微软有单独的调试器的,而且非常优秀,那就是:windbg 参见: http://www.microsoft.com/whdc/devtools/debugging/default.mspx 知道vs是用什么调试出来的吗?就是windbg。
来支持一下
写小程序我会用EditPlus+CL,把CL作为EditPlus的外部工具,非常好用。不仅启动速度很快,编译速度也很快,爽毙。想不通为什么VS把编译拖得那么慢,无法忍受了。
如果我的项目里有M个CPP文件,N个H文件,某些CPP文件依赖于K个头文件……那这个MAKEFILE可够得你写。 对于用不用IDE,我觉得不是那么绝对,在Windows下面开发,我用IDE,在Linux下面自己写MakeFile。 有自动档的车干嘛还开手动档呢?有种观点是手动档有驾车乐趣,不过当你堵在市区一两个小时不停起步停车的时候,就会想要一辆自动档……而不是所谓的“驾车乐趣”了 Posted by: NoSound | (29) September 22, 2008 08:59 AM ----------------- ... ... 只能说很无语,拜托,你去看看linux 核心源代码,哪一个是把文件写到Makefile 里的? 不要总是以自己的想法来认为别人也是那么作的
我在win下用vs,用linux取代win后,因为没有舒适的IDE,我就改用vim了。 vim有vim的好处,某些方面是vs的编辑器比不了的。同时不用IDE的确就享受不到IDE带来的一些便捷。有的即使能实现,也不完善。但实际使用后,我感觉不用IDE并不会影响多少编码效率。写C/C++代码,一般一天也就几百行,大部分时间还是留给大脑思考和设计上。不用IDE,还不怕机器差经常卡住。我以前用Eclipse,就经常因为IDE卡住而影响心情。
@joe wulf: 其实很多编辑器都有自动完成功能 用不用IDE这个问题,本质上还是人月神化那个:没有银弹。IDE再方便对生产力的提高也是小的那个部分……
就像wulf所说:IDE有智能提示. IDE还是有很多好处,例如工程文件管理,快速定位函数,查看函数调用关系等. 不要说VIM也可以做到啊...VIM通过ctags对C++的各种语法(override,overload函数,模板)支持确实不好,提示信息太杂乱. IDE也有很多选择. 有钱可以用SlickEdit(非常棒,跨平台,有调试环境,工程管理,C++代码重构等). 没钱的用CodeBlocks,结合gcc+wxwidgets,确实是跨平台的好组合.但是CodeBlocks的智能提示做的也不是太好,论坛一直说要重构,到现在也没有推出. 推荐使用CodeLite.比较完善的智能提示,有简单的重构功能.还有一些小功能都挺不错.很多感觉是在学习SlickEdit,使用起来非常顺手.由于CodeLite本身就是wxWidgets编写的,跨平台性非常好. 上面提到的3个IDE都可以自动产生Makefile的,这样结合自动脚本做持续集成等都没有问题.
文章真的很易读,makefile这些我没自己写过,感觉比较麻烦,ide只是帮了很多懒人的忙,很期待这个系列的后续。 替代windows批处理用vbs,powershell,AHK...还有很多选择 这几天开始准备重温一下您的《我的编程感悟》,2年前读完第一遍,lua那部分根本没基础,现在重读一遍,一定会有新的感悟。
其实仔细想想……用emacs/vim配置出来的开发环境也算IDE(集成开发环境),而且也可能是图形GUI的,但是这些和VS这种有什么不同呢?那就是脚本化能力不同,灵活性不同。
在C/C++系语言里不用IDE也是一不错的选择。但在.Net/C#/VB.Net中不用IDE估计很少有人会写了。其原因我想大概现代IDE已经和为语言提供的类库,框架结合得更紧密了使得很多人不用IDE就写不出程序了。我个人认为C/C++作为系统级/跨平台语言不提倡使用IDE。当然你用C/C++做一般企业应用等快速开发类型的项目那也不必钻牛角尖。
用IDE唯一原因是因为:有智能提示。
@Zhe 我猜会是 automake
曾经尝试过自己写Makefile,不过很快就放弃了……因为现在CodeBlocks+gcc+wxWidgets已经形成了比较完整的开发环境,而且还都是开源、跨平台的,所以又有了偷懒的余地……
我上次实在受不了 Visual Studio 2005 Express Edition 的庞大安装硬盘占用,结果改用 wxdev c++(mingw,wx-widget).感觉非常好.
享受命令行下操作带来的快捷方便 IDE只不过是工具,大众化的工作,而且越来越庞大
说IDE不好不过是因为没有深入研究过,在VS里也可以用Custom Build来用其他编译器,想要代码生成器根本不需要用C写什么工具,直接用宏代码就可以实现。那些vim, emacs所常用的编辑功能如果你用心研究的话在VS里也基本都能找到。如果你还有什么不满意还可以给IDE写插件,实现任何你想要的功能,VS的插件机制具有很强的扩展性。如果你要在linux上工作,一样可以选用Eclipse, netbeans这类的IDE工具。 把你在命令行工具上所花的学习时间用到IDE的研究上,你一样可以把IDE运用到极至,实现任何你想要的特性。但是事实上很少有人这么做,花上很多时间在构建工具上对程序开发,实在是件投入产出比很低的事情,得不偿失。反过来推,在makefile上浪费大量的学习时间,一样不甚明智。
特别云风现在开发的是跨平台的游戏引擎,这种东西用IDE来做几乎是不可想象的。 btw:makefile系统还有一个最大的优势:解放右手,让左臂不会太酸痛:)
IDE仅仅不是唯一的选择嘛,这正是这个题目的妙处。makefile优点多多,但必要的时候并不需要排斥IDE,但同时我觉得保留一份兼容的makefile系统还是必要的。
我顶!
我又想了想,使用make文件的好处也许有一些: 1.你可以写一个程序来控制一个项目的生成(或者说在一堆文件的基础上做任何事情),把文件当变量玩.这个我觉得的确是有很大威力的,因为可以控制一切,也很灵活. 2.可以在不同平台下,进行方便的切换,就是可以在不同平台下使用接近的工作方式. 对于第一点,我觉得是比较高级的用法,的确很有诱惑力,不过不能因为这个放弃ide带来的种种好处,ide为大多数最常用的功能提供了最方便的方式,更加人性化,当然你可以寻找各种工具来作替代品,但它们毕竟不是整合的,我觉得应该在ide的基础上加一些对项目生成的脚本控制.也许vc的ide这方面还做得不够吧. 第二点,我没有写过跨平台的程序,这方面不太了解.也许linux下没什么太好的ide吧,所以也不损失什么.
不好意思,上一篇留言可能没写清楚,其实我只想表达一个意思:如果在Windows下面还非要用MakeFile来自己弄(而且用的还是VC的编译器),而舍弃VS不用,我觉得是本末倒置了。
如果我的项目里有M个CPP文件,N个H文件,某些CPP文件依赖于K个头文件……那这个MAKEFILE可够得你写。 对于用不用IDE,我觉得不是那么绝对,在Windows下面开发,我用IDE,在Linux下面自己写MakeFile。 有自动档的车干嘛还开手动档呢?有种观点是手动档有驾车乐趣,不过当你堵在市区一两个小时不停起步停车的时候,就会想要一辆自动档……而不是所谓的“驾车乐趣”了
呵呵,不会用IDE的人路过
以前看过一点make,坦白讲,觉得还是比较麻烦的。 即使是在linux下面,可能我还是会倾向于用eclipse这样的东西吧。
我是说,如何从cl的错误输出信息用简单的方法定位到出错的地方,ide下只要一个双击就可以了,你说的那些编辑工具可以做到这样吗.ide不是使人变傻,而是使编程变得方便.我觉得如果有各种需要的话,应该把它们集成到ide中去,楼主说的那些功能在ide里应该也能完成吧? 再举一些例子,我要新增加一个文件到编译队列里,我用make来做的话是不是需要手动的去修改make文件呢?ide里我可以方便的添加一个文件到工程里.使用make文件有没有办法让我快速找到其中的某一个source code文件呢,我要在所有需要编译的文件里搜索怎么办,除了make文件外,我还需要维护另外一个用来搜索的文件列表吗?
vc版本之间兼容性差有些是历史遗留问题,最近看chrome代码,有些感悟。经常遇到的是wchar_t问题,还有模板
用惯了IDE,想摆脱真是有点小痛苦,感谢云风!
VC的向下兼容性很差。有时在VC6sp6下能正常编译的,在VS2005或VS2008下编译的时候就会跳出一大堆的错误与警告。原因可能是VC对标准的C++语法支持不好,有很多它自己编译器的定义,很是头疼。但在Win32中写程序,还是用VC顺手。不用IDE环境写程序界面是很麻烦的事情。这又怎么解决?难道手动的去写?时间足够当然没关系。但工程进度会大大拖慢的吧?
你们在构建代码都用make吗? 有没有试过scons。http://www.scons.org/
貌似自己脱离了IDE啥都不会了,不能不说是一种悲哀吧!
呵呵,用windows的人,很多不喜欢命令行的! 幸亏我早从Ide中跑了出来, ide就是想把你变傻!
喜欢类似这样的文章,分享心得体会。辛苦了,写了这么多!:D
为了对它产生兴趣,我用IDE,为了,为了让自己彻底了解语言的核心,我脱离IDE,努力中... 呵呵
错误行定位,现在流行的编辑器都可以办到的。uedit 啊,editplus 啊,还有我们这很多人喜欢用的 vim , emacs 之类的。 没有碰到 ide 解决不了或不方便解决的问题,是因为你在 ide 给定的框架里思考怎么解决问题。 ide 不是万能的,make 更不是。但是不用 make 还可以用别的。而习惯了 ide 就不会去用别的了。 make 不是专门用来 build 项目的,只要你愿意,你拿它从仓库 check 代码,发 email ,定期清理硬盘,下载文件等等,随便做啥都可以。它只是一个工具,帮你拓展你想用计算机做的事情而已。合适就用,不合适就换个更合适的来。 btw, 用过 freebsd 同学都知道 freebsd 的 ports 机制,就是基于 make 的。我相信用过的人都能感受到方便。
我来举个例子吧,比如说你在用cl编译foo.cpp文件的时候有编译错误,cl报一堆错误出来,我怎么通过简单的方法定位到错误的地方呢,(这个ide可以比较方便的做到)
希望楼主能举一个实际一点的例子来体现一下使用命令行make工具到底比用ide好在哪里.比如说用ide如何如何不方便(甚至根本做不到),而make工具能轻松的解决这些问题.说实话,我到现在实在没碰到过什么情况非要使用make工具的,可能我写的程序比较少吧.
我比较喜欢用Qt的qmake。即使只是单纯的C++程序,在linux下用qmake也很方便,在Windows下则可以生成vc的工程。另外,现在做DSP开发,觉得如果没有CCS(IDE环境)的话根本没办法开发。当然,看了VC内部机制还是很有收获的 :)
挺好!IDE的确不是程序员唯一选择。 虽然不是目标读者,但还是强行读了下本文。平台切换,开发工具切换,抛弃IDE等造成的变化并不大,计算机本质是一样的,API调用无甚大区别,开发工具都非常的易学简单高效,熟练只是一个时间问题,本质上都非常的简单,工具琳琅满目,开发效率会更高,这是我做为一个Windows程序员切换到*nix上学开发时的感觉。 跑题了,谈谈对本文的看法。我觉得绝大部分Windows程序员并不是不知道IDE不是唯一选择,而是觉得不使用IDE进行开发会非常麻烦,很低效。本文举的例子相当的没有魅力,完全不能解决这个疑惑。 从Windows平台上来讨论本文的主题我觉得相当的难。
这一系列可以预见是十分有用的,娃哈哈
云风,你竟然这么有时间写这么多文章,我都好忙,想得多写得少。佩服你
感谢分享经验啊。正忙工作的人还肯花时间做分享的人不多了现在
应该说用make工具在自动构建大型项目时候作用非常大 希望云风能贡献一些代码组织方面的经验,特别是大型项目的代码组织和目录划分
这篇出来得相当快呢……不过,云风打算介绍GNUMake还是NMake啊? 可惜MS用Express版把Visual C++ Toolkit给替了,这个东西又小又好使。其实用vc的人可以给推荐试试icl(Intel C/C++ Compiler),优化超变态,自己性能也很好,想用吧?这玩意就是和Visual Studio整合超差,于是就和云风一路了。 btw,gcc不支的东西也多,特别是CodeWarrior系的(虽然cw也提供命令行),而且像psp nds之类,用过cw的都爱不释手,虽然那东西简直就是CodeWorrior……
十分感谢分享经验,期待下文。关注中。。。
真快 昨天我在网上google到了简单的gdb的操作,今天已经在gdb程序了,不过发现一个麻烦的地方,那就是好像设置断点必须在run比前,如果我step到一个地方,想增加一个断点,好像没有办法。
谢谢云sir,如果是做界面程序该怎么办呢?
其实面对黑屏幕,然后脱离鼠标的生活是很酷的。一直用UltraEdit当作IDE,在其中配置了很多调用编译器的命令和脚本
有两个要克服的吧,一个是习惯问题:国内的一般都是Windows,大多都是IDE吧,是一个环境习惯问题;二:*nix 刚开始确实是不好上手。PS.很讨厌MS,把一些简单的道理封装的很复杂!
不过,有的软件是绑IDE的,很麻烦。 像nVidia提供的CUDA on Windows,绑VS IDE,尤其自己去看又看不懂怎么呼叫nvcc.exe就很麻烦。 偏偏Linux环境又不熟,所以只能继续用VS 2005来写CUDA程式.....
哈哈,说写就写,这么快?虽说最近不怎么用VS了,还是先一睹为快!

Post a comment

非这个主题相关的留言请到:留言本