Windows 支持 DirectX 和 OpenGL，为什么大多数 PC 游戏还是 DirectX 开发？
我的图书馆
Windows 支持 DirectX 和 OpenGL，为什么大多数 PC 游戏还是 DirectX 开发？
【村之姑的回答(75票)】:
事实上在早年即使在领域也是对压倒性的优势。John Carmack曾嘲讽DirectX是“horribly broken” 的API。
直到DirectX6时代OpenGL都被认为是比DirectX更加优秀的API，即使那个时候DirectX已经有《CS》《极品飞车5》等大作的支持，却依然不受当时FPS游戏霸主id Software的待见。作为那个时代的显卡杀手，《Quake III》都仅仅只支持OpenGL。
DirectX7发布之后DirectX和OpenGL开始逐渐平起平坐。直到2000年DirectX8的发布才使DirectX在游戏领域完全确立了自己的优势 —— 支持革命性的programmable GPU rendering pipeline来代替原有的fixed function pipeline，引入了Vertex Shader和Pixel Shader。而OpenGL的核心正式支持programmable rendering pipeline已经是四年之后OpenGL 2.0发布的时候了。想想这中间会有多少游戏公司/游戏引擎公司会倒向DirectX吧。
说到OpenGL衰落的原因，不得不提到OpenGL开发的机制。OpenGL早期一直是由ARB (
OpenGL Architecture Review Board，成员包括Nvidia, ATI, Intel, Apple, IBM, SGI等等）成员共同维护。每个成员可以为了支持自己硬件新的feature来开发OpenGL enxtension, 所有成员一致通过的extension才能加入到下个版本OpenGL核心中。这就造成了不同成员为了各自利益互相斗争，拖慢了开发进度。微软曾经也是ARB的成员之一，后来因为受不了这种机制退出专心搞自己的DirectX去了。
如果一个API越流行，那么去学习这个API的人就会越多，游戏公司会越容易招到掌握这个API的图形程序员，也就会更多的基于这个API开发游戏。用这个API的游戏越来越多，就会更多的得到
硬件厂商的支持，为面向这个API的驱动做更多的优化，然后这个API就会更加流行。如此进入一个良性循环，这就造成了DirectX现在称霸游戏领域，OpenGL几乎绝迹的局面。
在06年从ARB交由Khronos Group掌管之后, OpenGL最近几年也迎头赶上，从性能，易用性来说其实和DirectX已经相差不大。但是在相比DirectX没有突出优点的情况下（除了跨平台），已经习惯使用DirectX的游戏厂商也不可能重新投出OpenGL的怀抱。
最后一点，OpenGL只是一个单纯的图形库，而DirectX是包含图形(Direct3D), 声音(DirectSound), 输入(DirectInput), 网络(DirectPlay)的一整套解决方案。对开发者来说使用DirectX显然要方便的多。
/*******************************************************************************************************/
下面是我之前一个同事看完我的回答的评论，也贴上来吧。
“还有很重要的一点, GL从不淘汰任何老的API. DX10相对于DX9,是个全新的API,革命性的更新,彻底推倒重来. 但GL为了向后兼容,保留了很多对硬件和驱动都不友好的API.除了跨平台和早期对精度的要求比DX高,其他简直是一无是处”
【XanaHopper的回答(9票)】:
你要知道，至少到vs2008，vs自带的opengl头文件都只是1.1版本的，你这叫人如何用？微软为了发展DX抑制OpenGL几乎每一本OpenGL书籍都会提到。-------分割更新--------再有就是DX的SDK属于虽然要自己下而且很大但是可以开箱即用，OpenGL就不一样了，glew,glext,glut等等一大堆各式版本的头文件，还要自己保证兼容等等问题……不说了，都是泪
【MiloYip的回答(4票)】:
补充一下Windows的限制。
在Direct3D在9.0c后就不支持Windows XP了，Direct3D 11.1也只有限度支持Windows 7。那么即使有SM 4.0或以上的硬件也无法在较早版本的Windows中使用。
而OpenGL只需要显卡厂商继续提供驱动，便可以在各Windows版本里使用最新的硬件功能。
【知乎用户的回答(5票)】:
效率不敢多说，至少DirectX的api手感用起来特别舒服。OpenGL总觉得各种设计得莫名其妙……
【张静vinjn的回答(5票)】:
很重要的历史原因 已经提到了。
对于从游戏开发者角度而言，OpenGL 曾经是个没人用的东西，Windows / Xbox 上可以用 DirectX，PS3 和 Wii 则又是另外的图像API。
直到iPhone的兴起，OpenGL 居然又活了过来，你看现在连 WebGL 都出现了，有一种统一天下的感觉。
游戏开发者又开始重视 OpenGL 了，当然主要还是 OpenGL ES。
对于显卡公司而言，Windows 上的 D3D 驱动特别重要，会针对各种流行游戏进行定制、优化、hack……至于 OpenGL 驱动，似乎只要满足 CAD 大厂的需求即可，毕竟几乎没有 Windows 上的 OpenGL 游戏啊……
现阶段，从性能考虑（D3D 驱动会特别优化），大型的游戏还是以 D3D 的形式发布，不排除 OpenGL 的优化上去以后也会有大型的桌面 OpenGL 游戏。
对于微软而言，他对于OpenGL的限制非常多，比如WindowsRT，Windows Phone是不支持OpenGL，Windows商店里的应用也必须是DirectX的。
【刘金鑫的回答(0票)】:
移动时代已然来临，现状正改变。而且windows专有游戏渐渐会出人们的视野。再看API状况会大不同。
【vczh的回答(6票)】:
近10年来，opengl追赶dx就跟java追赶C#一样。opengl原本是一种设计来做CAD的api，后来被用来搞游戏，火了之后不思进取，造成了计算模型落后到爆炸，后面才慢慢改成了dx11现在的样子的。
而且opengl煞笔还要怪那些A开头公司的编译器。众所周知，一个公司一旦以A开头，那他自主研发的编译器就跟垃圾一样。opengl（和opencl一样）标准要求驱动程序自己去写编译器，就别说linux了，在windows上不同的卡都有互相不兼容的bug。而directx的标准要求驱动程序解释一个指令集的中间语言，不兼容的情况就少了好多，虽然还有，但是已经没什么所谓了。
不过由于底子不好，opengl的api用起来始终没有dx11那么舒服。
P.S.，由于opencl也是一个德行，在windows上的A卡定义一个struct都会导致驱动程序崩溃什么的，让人怎么用啊，只能选cuda或directcompute了。
馆藏&62188
TA的推荐TA的最新馆藏&>&&>&&>&&>&VS2010+AMD+OPENCL开发环境配置详细教程
VS2010+AMD+OPENCL开发环境配置详细教程
上传大小：1.66MB
VS2010+AMD+OPENCL开发环境配置详细教程
嵌到我的页面
<input type="text" value="">
综合评分：4.6（16位用户评分）
收藏（(1)）
所需积分：0
下载次数：139
审核通过送C币
创建者：zang
创建者：nigelyq
创建者：nigelyq
课程推荐相关知识库
上传者其他资源上传者专辑
开发技术热门标签
VIP会员动态
android服务器底层网络模块的设计方法
所需积分：0
剩余积分：720
您当前C币：0
可兑换下载积分：0
兑换下载分：
兑换失败，您当前C币不够，请先充值C币
消耗C币：0
你当前的下载分为234。
VS2010+AMD+OPENCL开发环境配置详细教程
会员到期时间：
剩余下载次数：
你还不是VIP会员
开通VIP会员权限，免积分下载
你下载资源过于频繁，请输入验证码
你下载资源过于频繁，请输入验证码
您因违反CSDN下载频道规则而被锁定帐户，如有疑问，请联络:!
若举报审核通过，可奖励20下载分
被举报人：
carrotshuan
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：查看: 4006|回复: 6
openCl开发环境目前有IDE的吗最好打包下载就安装的
论坛徽章:0
openCl开发环境目前有IDE的吗最好打包下载就安装的，要不写个打包安装方法
论坛徽章:0
论坛徽章:0
没有阿，可以现在马上编写的吗
论坛徽章:0
编译器Clang介绍& & & & & & & & & & & & & & & & & & & & 收藏 & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & LLVM 与 Clang 介绍{ 撰文/guest }
是 Low Level Virtual Machine 的简称，这个库提供了与编译器相关的支持，能够进行程序语言的编译期优化、链接优化、在线编译优化、代码生成。简而言之，可以作为多种语言编译器的后台来使用。如果这样还比较抽象的话，介绍下
就知道了：Clang 是一个 C++ 编写、基于 LLVM、发布于 LLVM BSD 许可证下的 C/C++/Objective C/Objective C++ 编译器，其目标（之一）就是超越 GCC。
Clang 开发事出有因，Wiki 介绍如下：
Apple 使用 LLVM 在不支持全部 OpenGL 特性的 GPU (Intel 低端显卡) 上生成代码(JIT)，令程序仍然能够正常运行。之后 LLVM 与 GCC 的集成过程引发了一些不快，GCC 系统庞大而笨重，而 Apple 大量使用的Objective-C 在 GCC 中优先级很低。此外 GCC 作为一个纯粹的编译系统，与 IDE 配合很差。加之许可证方面的要求，Apple无法使用修改版的 GCC 而闭源。于是 Apple 决定从零开始写 C family 的前端，也就是基于 LLVM 的 Clang 了。
Clang 的特性：
快：通过编译 OS X 上几乎包含了所有 C 头文件的 carbon.h 的测试，包括预处理 (Preprocess)，语法(lex)，解析 (parse)，语义分析 (Semantic Analysis)，抽象语法树生成 (Abstract SyntaxTree) 的时间，Clang 是 Apple GCC 4.0 的 2.5x 快。()内存占用小：Clang 内存占用是源码的 130%，Apple GCC 则超过 10x。诊断信息可读性强：我不会排版，推荐去观看。其中错误的语法不但有源码提示，还会在错误的调用和相关上下文的下方有~~~~~和^的提示，相比之下 GCC 的提示很天书。GCC 兼容性。设计清晰简单，容易理解，易于扩展增强。与代码基础古老的 GCC 相比，学习曲线平缓。基于库的模块化设计，易于 IDE 集成及其他用途的重用。由于历史原因，GCC是一个单一的可执行程序编译器，其内部完成了从预处理到最后代码生成的全部过程，中间诸多信息都无法被其他程序重用。Clang将编译过程分成彼此分离的几个阶段，AST 信息可序列化。通过库的支持，程序能够获取到 AST 级别的信息，将大大增强对于代码的操控能力。对于IDE 而言，代码补全、重构是重要的功能，然而如果没有底层的支持，只使用 tags 分析或是正则表达式匹配是很难达成的。当然，GCC 也有其优势：
支持 JAVA/ADA/FORTRAN当前的 Clang 的 C++ 支持落后于 GCC，参见 。（近日 Clang 已经可以自编译，见 ）GCC 支持更多平台GCC 更流行，广泛使用，支持完备GCC 基于 C，不需要 C++ 编译器即可编译相信介绍到这里大家能够对 Clang 和 LLVM 有所了解了。除去 Clang 之外，LLVM 还被用在 Gallium3D 中进行 JIT 优化，Xorg 中的 pixman 也有考虑使用 LLVM 来优化执行速度， 使用 LLVM 来编译 Lua 代码，使用 LLVM 可以令 CUDA 程序无需重新编译即可运行在多核 X86CPU、IBM Cell、支持 OpenCL 的设备之上...我个人感觉 Apple 在开源界口碑较差（也许是我的错觉？），不过 Apple也为开源界贡献了不少，Webkit，OpenCL（虽说只是个标准），Clang。我最为佩服的是虽然出身于命令行之上的 Unix族系统，但有魄力写出自成体系的图形栈，其图形界面优美而人性化，可谓也为开源界贡献了自己的精神与思想。对于 Clang这个很有潜力的项目，我希望其 C++ 支持（尤其是 template 支持）能够早日完善。因为 GCC 在 template出错时的诊断信息如同小说一般...
{ Thanks guest. }
雪豹的心脏：LLVM和Clang来源：
& &&&Mac OS X 10.6即所谓的Snow Leopard操作系统已正式发售。一如既往，Apple产品光鲜的外表下凝聚了太多艰辛的劳作。ArsTechnic的John Siracusa以其独特的、专业的、全面的视角深入翔实地体验这款最新的操作系统。& &
将对该综述进行翻译整理并独家连载。欢迎关注。
译注：为了帮助您更加顺畅地理解本文的内容，这里补充了文中一些相关概念的背景资料。
& && &编译器(compiler)：是一种能够将源代码(通常由高级别的程序语言编写而成)转换为低级别机器语言的程序。源码转换最重要的一个目的在于创建可执行文件。。
& && &LLVM(Low Level Virtual Machine，低级虚拟机)：是构架编译器(compiler)的框架系统，以C++编写而成，用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(run-time)以及空闲时间(idle-time)，对开发者保持开放，并兼容已有脚本。LLVM计划启动于2000年，最初由University of Illinois at Urbana-Champaign的ChrisLattner主持开展。2006年Chris Lattner加盟AppleInc.并致力于LLVM在Apple开发体系中的应用。Apple也是LLVM计划的主要资助者。以及。
& && &GCC(GNU Compiler Collection，缩写为GCC)：是GNU计划推出的支持多种程序语言的编译器系统。GCC是GNUToolchain的主要组件。同时作为GNU操作系统的官方编译器，GCC已被作为很多现代操作系统的标准编译器，如GNU/Linux，BSD以及Mac OS X；同时也可用于很多嵌入式平台，如Symbian，AMCC等；还可用于一些游戏机平台如Playstation和SegaDreamcast等。以及。
& && &IDE(Integrated development environment)：是一种能够为程序员和软件开发提供广泛支持的软件程序。IDE通常由源码编辑器、编译器、自动化构建工具以及调试器组成。。
& && &早在几年以前，Apple就在LLVM开源计划上做出了重要的战略性投资。我曾在一篇介绍Mac OS XLeopard的文章中简要介绍了LLVM的一些基本情况，Leopard利用LLVM技术为JIT编译软件的OpenGL功能提供了高效的执行支持。在那篇综述的最后，我这样结尾：对于LLVM，Apple拥有相当宏伟的计划：逐步摒弃Mac OS X中现有的GCC编译器集合(compliercollection)，并采用全新的基于LLVM的编译器系统。该计划称为&Clang&，并且已有了一些可喜的进展。& && &&&
& && &随着Snow Leopard的推出，这一切开始逐渐浮出水面：Clang和LLVM已成为Apple现行的编译策略。LLVM甚至还有一个全新的帅气的标志：
& && &目前，Apple为Mac OS X总共提供了四种编译器：GCC 4.0，GCC4.2，LLVM-GCC 4.2，以及Clang。这里是一个图表：
& && &所有这些编译器在Mac OSX上均具有二进制兼容性(binary-compatible)，这就意味着您可以使用一种编译器创建一个资源库并与使用另一个编译器创建的可执行文件相链接。并且，理论上讲，这些都是命令行编辑器并且都具有资源兼容性。然而，Clang目前暂不支持GCC的一些复杂功能，同时Clang只支持C、Objective-C和一点点C++(而GCC支持的相对较多)。Apple承诺，Clang未来将会为C++提供全方位支持，并且希望能够在SnowLeopard的“服役期间”内解决GCC的不兼容问题。
& && &Apple为Clang带来了两条引人注目的特性，那就是：更短的编译时间和更快的可执行文件。Apple用其自身的软件如iCal，AddressBook，Xcode，以及一些第三方软件如Adium和Growl进行了测试，Clang编译器比GCC4.2快了近乎3倍。而对于编译的可执行文件运行速度，由Clang生成的可执行文件则比GCC 4.2生成的可执行文件快5~25%。
& && &同时，与其前任GCC相比，Clang提供了更为友好的开发环境。我承认这和多核CPU等新技术的优势并无很大关联，但这确实开发者在使用Clang时首先面对的。
& && &对于新手来说，Clang具有可嵌入性，因此Xcode可以在IDE的一些交互功能中使用和最终的可执行文件相同的编译器结构。在编译过程中，Clang创建并保留了大量详细的元数据(metadata)，从而有利于调试和错误报告。例如，如果GCC返回如下错误：
& && &这时候很难说清问题究竟在哪，对于编程新手来说尤为如此。好吧，牛人或许已经看出来问题在哪了(如果您在WWDC上看到了这个例子的话)，但是我相信大家都会认为Clang返回的错误报告更有用：
& && & 可能个别菜鸟仍然不知所措，但是至少可以清晰地看到问题究竟出在哪里了：与GCC含糊其辞的回应相比，Clang明明白白告诉你，哥们儿我不认识“NSString”这个类型…
& && & 而且，有时候即使错误信息很明确，具体细节却未必如此，譬如GCC返回的这个错误提示：
& && &很明显，“无效的运算符号+”，但是这条语句中有4个“+”，究竟哪一个有问题呢？多亏这些相近的元数据(metadata)，Clang可以明确地为您指出问题所在：
& && &更进一步抬杠。有时候错误一目了然，譬如这个GCC的例子，在报错行以上的语句中丢失了一个分号“；”：
& && &而Clang则更进一步，指出了究竟哪里丢失了这个分号：
& && &楼下同学说了，这些都是“小事儿”，完全是鸡蛋里头挑骨头没事儿找事儿，然而对于程序员来说，Clang提供的这种更为细致和细心的提示是相当贴心的。当然，还有一些细节对于程序员来说则意义重大了，譬如这个基于LLVM的静态分析器(staticanalyzer)。下图显示了静态分析器发现并指出了一处可能的bug：
& && &图中高亮的部分明确地指出了任何一位程序员都有可能犯的bug。静态分析器检测到，这一系列嵌套条件中，“myName”变量在至少一条路径里中未被初始化，从而使得在最后一行发送“mutableCopy”时存在潜在的危险。
& && &我相信Apple一定在其所有应用程序和操作系统上运行过静态分析器，以检查一些潜在的bug。而对程序员来说，能够在庞大的代码库中自动监测潜在的bug，无疑是一件非常爽的事情，对于自己开发平台的程序员来说更是如此。某种程度上来讲，Mac OS X10.6.0中存在的bug比先前的任何一个10.x.0系统的bug都要少，无疑这将归功于LLVM。
& && &通过Clang/LLVM的进一步推广和完善，Apple终于能够完全掌控其自己的开发平台了。CodeWarrior的经验显然使Apple更加清晰地认识到，依赖于第三方平台开发工具是相当不明智的。尽管花费了许多年的时间，但我认为即使最顽固的Metrowerks支持者也会认为，SnowLeopard提供的Xcode确实是个相当不错的IDE。
& && &许多年以来Apple一直纠结于GCC计划与Apple自身的编译需求之间的脱节，现在Apple终于痛下决心另辟蹊径。诚然，GCC4.2仍然是SnowLeopard的默认编译器，但是很显然Apple已进入的过渡期。Clang自然是推荐的编译器，并且在可预见的将来，Apple的焦点将集中于此。
llvm/clang将把FreeBSD带向何方？
对于FreeBSD最近的发展，最引人注目、最让人有所期待、最让人遐想的就是在将来的某个版本里将引入llvm/clang。这是一个什么东西？为什么值得期待？请听我慢慢地扯。
llvm/clang是一个编译器，llvm是类似虚拟机的东西（），这个虚拟机不是类似java或者说python的VM，llvm的目的不是运行而是编译生成代码。也就是说这个llvm是编译器的后端。clang呢，（）简单来说就是llvm一个C语言家族的前端，它的责任就是把C家族语言翻译成llvm认识的中间代码，然后再由llvm后端生成具体架构的汇编代码，最后由系统中的汇编器、连接器生成某一个架构下的可执行文件。
说实话，任何编译器不都是这个套路吗？分前端后端，代码生成，也许还有代码优化，llvm到底有什么不同？最主要的是llvm提供的是函数库，一组较好定义的接口，使得编译器前端的设计相当的傻瓜。我们可以为Perl写一个llvm的前端，它就可以把perl脚本编译成本地二进制代码运行；给python写个前端，它一样可以编译。不要以为这个前端有多么的复杂，通过llvm比较合理的接口，这个工作不是很难。
所以总得来说llvm/clang的架构要优于GCC的架构（其实写个GCC的语言前端也不是什么大事，但是你必须了解GCC内部的机制和细节，并不能像llvm那样调用几个库函数就把事情给搞定。），就因为这个优势，FreeBSD准备迁移到llvm/clang上面。怎么可能？不要太天真了。一个庞大的操作系统要迁移到另外一个还在开发之中的编译器上，不是一件容易的事情。这么做的原因其实是GNU把后续开发的GCC变成GPLv3了，BSD的人本来就对GPL不感冒，这个V3影响到了使用FreeBSD做商业运作的公司的核心利益。其实如果使用FreeBSD的商业公司愿意对FreeBSD贡献一下力量的话（确实已经贡献了不少力量），llvm/clang不用多久就可以引入FreeBSD的base，而且llvm/clang本身还能有长足的发展。但是人嘛，总是只想得到不想付出的，商业公司做事的唯一考量就是做这件事情有没有利益。所以llvm/clang要真正实用不是近期的事情，虽然FreeBSD的svn中有了clangbsd这个项目。
有人也曾经提出一个Unix的source base里面只能有C语言写的程序，所以FreeBSD只需要PCC()。PCC也是一个老壶装新酒的编译器，它是UNIX的research版本的编译器，后来有人重新修改、重写了一遍，变成一个经典的分2个pass的C编译器，并支持C99标准。这个没有能进入FreeBSD其实一方面是在目前的工业界是回避不了C＋＋的（llvm/clang是使用C＋＋写的，clang对C＋＋的全面的支持是一定的，不然clang自己都不能bootstrap啊。），除非做个理想的操作系统如Plan9那样，设计的好不好，当然好，就是20多年还没有被大众接受。要让一个Unix系统中只用C语言就像让现在的中国走社会主义道路一样，好不好？当然好，就是现实做不到。第二个方面用PCC编译FreeBSD的事情没有人肯去做，我也在maillinglist上呼吁过，说什么可以使用PCC啊，多么经典啊，多么简单啊，自己就是不想去修改一个Makefile，不想去查看一行代码。嗨。。人嘛，就设个本性，牛都是要吹的，事情最好都人家做。（BTW：一直想修改FreeBSD的msdosfs让其支持UTF-8的中文文件名的，就是一直没做，其实是想等别人来做或者允许我找个借口－－忙啊！！囧）
革命呢，还是要充满乐观主义情绪的，所以我相信llvm/clang最终会进入FreeBSD的base。那个时候我们刚装完FreeBSD后，第一个要干的事情是到ports中安装最新的gcc。因为大量的ports中的软件是非gcc不可编译的，当然有些简单的软件是可以用clang编的，比如shell/bash(我试过，编出来的可执行文件比gcc编出来的小，但是编译时间比gcc长，执行性能就不知道了)。
革命呢，也是要认清人民群众的本性的。如果想要在近年内完全脱离GNU编译器族，那也不太可能。llvm/clang就是个C/C＋＋编译器，最后还要使用系统中的汇编器和连接器来生成可执行文件的，在FreeBSD中这些as和ld可都是GNU的。虽然BSD的binutils早就在开发了，除了有个ar，nm之类的东西开发完成，as，ld估计是八字没有一瞥呢。当然，我也理解啊，有的用就先用着，何必为了licence去重造轮子呢？对于assembler估计llvm项目自己会出一个，好像叫“mc”（也是听人家在maillinglist上吹的），至于linker嘛，虽说不是什么复杂的软件，估计要等GNU把它的ld变成GPLv3才有希望看到BSD的linker了。
最后，这个新的编译器将把FreeBSD带向哪里？也不能带向哪里（我承认我是个标题党。。。），不就是个编译器嘛，再说近期还不可能实用。倒是FreeBSD-8的新东西比较吸引人，新的TTY层、增强的kernel SMP、ULE、Gaint lock进一步去除，特别是网络栈中Gaintlock的去除，我就等待着FB-8的性能测试报告，估计在多CPU的情况下，网络栈的性能要上个档次！还有新的USB代码（我没有觉得老代码有什么不好，新代码估计是架构上的改进，具体还没看。。），增加amd64上kernel内存的极限，这下使用ZFS更加啦风了。新的AHCI(SATA)driver，进入了CAM子系统，终于把SATA当作SCSI处理了，（是不是落后与Linux了？无所谓，稳定了的东西我们才用）。
等着FreeBSD-8吧，就在近期了。（要习惯于跳票哦，呵呵）
论坛徽章:0
这个文章里面有OPENCL的文字，
这个编译器我第一次听说，用不用得自己看
论坛徽章:0
Code::Blocks
Code::Blocks百科名片本词条主要介绍 Code::Blocks
Code::Blocks 是一个开放源码的全功能的跨平台C/C++集成开发环境.Code::Blocks是开放源码软件。Code::Blocks由纯粹的C++语言开发完成，它使用了蓍名的图形界面库wxWidgets(2.6.2 unicode)版。对于追求完美的C++程序员，再也不必忍受Eclipse的缓慢，再也不必忍受VS.NET的庞大和高昂的价格。
历史　　虽然Code::Blocks从一开始就追求跨平台目标，但是最初的开发重点是Windows系统下的版本，从06年3月21日版本：1.0revision2220开始，Code::Blocks在它的每日构建中正式提供Linux版本（分两个版本：ubuntu.deb和fc4.rpm）。这样Code::Blocks在1.0发布时就会是跨越平台的C/C++IDE，它将支持Windows和Linux的主要版本。长期以来C++开发员在Linux没有好用、通用的C++IDE的局面就要结束。而这个IDE对于Windows下的用户同样重要，由于它开放源码的特点，Windows用户可以不依赖于VS.NET，编写跨平台C++应用。
主要特点　　Code::Blocks提供了许多工程模板，这包括：控制台应用、DirectX应用、动态连接库、FLTK应用、GLFW应用、Irrlicht工程、OGRE应用、OpenGL应用、QT应用、SDCC应用、SDL应用、SmartWin应用、静态库、Win32GUI应用、wxWidgets应用、wxSmith工程，另外它还支持用户自定义工程模板。在wxWidgets应用中选择UNICODE支持中文。　　Code::Blocks支持语法彩色醒目显示，支持代码完成（目前正在重新设计过程中）支持工程管理、项目构建、调试。　　Code::Blocks支持插件，目前的插件包括代码格式化工具AStyle；代码分析器；类向导；代码补全；代码统计；编译器选择；复制字符串到剪贴板；调试器；文件扩展处理器；Dev-C++DevPak更新/安装器；DragScroll，源码导出器，帮助插件，键盘快捷键配置，插件向导；To-Do列表；wxSmith；；wxSmithMIME插件；wsSmith工程向导插件；WindowsXP外观。　　Code::Blocks具有灵活而强大的配置功能，除支持自身的工程文件、C/C++文件外，还支持AngelScript、批处理、CSS文件、D语言文件、Diff/Patch文件、Fortan77文件、GameMonkey脚本文件、Hitachi汇编文件、Lua文件、MASM汇编文件、Mathlab文件、NSIS开源安装程序文件、OgreCompositor脚本文件、Ogre Material脚本文件、OpenGLShading语言文件、Python文件、Windows资源文件、XBase文件、XML文件、nVidiacg文件。识别Dev-C++工程、MS VS 6.0-7.0工程文件，工作空间、解决方案文件。　　Code::Blocks基于wxWidgets开发，正体现了wxWidgets的强大。以前Borland C++ Builder X宣称基于wxWidgets开发跨平台、兼容性好、最优秀的C++IDE环境，但没有实现；现在Code::Blocks+GNUGCC正在实现这个理想。让我们拭目以待。国内的Code::Blocks爱好者和跨平台开发员应该尽快建立中文Code::Blocks网站，提供Code::Blocks中文化支持，促进Code::Blocks在国内的发展。
安装　　2.1安装Code::Blocks发行版 8.02　　8.02版是必须安装的，然后才能升级。 　　2.11 下载安装文件　　Code::Blocks的发行版版本号就是它的发行年月，所以8.02版，就是08年2月份发布的，其实地相当于1.0版。　　Code::Blocks网站：其下载页面（）提供了windows,Linux(多个发行版)，及MacOS X 的安装文件或源文件包。 不过我们暂时只讲Windows下的安装。所以您可以将下面的链接，复制到迅雷之类的工具下载。　　 　　或者 　　2.12 卸载可能的mingw32先前版本　　Code::Blocks支持多种编译器，但我们主要讲Windows下的mingw32g++编译器。因此需要安装mingw32。前面下载的安装程序已经自带有完整的mingw32环境。mingw32是g++环境在windows下的一个实现。为了避免版本与路径冲突，最好不要在一台机器上安装两个mingw32。所以本步要求检查一下。　　如果您以前有用过Dev C++之类也采用mingw32的IDE，那您最好先卸载了它们。如果您不懂什么叫mingw32,那估计你的机器就是没能安装过吧。那这一步跳过。　　2.13 开始安装
双击下载的文件，就可以开始完装了，主要就两个注意点：　　第一、选择“Full/完整”安装，免得一些插件没有被安装上。　　第二、安装目录最好不要带有空格或汉字。　　这一点并不是Code::Blocks的限制，而是因为mingw32里的一些命令行工具，似乎对长目录或带空格的目录支持有点小问题，我估计汉字目录也会出问题，但没试过。一句话，就装在根目录下的X:\CodeBlocks即可。比如我是安装在E:\CodeBlocks下。　　2.2 升级Code::Blocks到最新svn版　　Code::Blocks是开源的软件，它们源代码管理采用subversion管理，因此它的编译版本就直接采用svn的版本了。　　code::blocks的网站看上去不怎么更新，其实程序的主要都在它的BBS（）的nightly builds子论坛中更新。　　2.2.1 下载升级文件，并覆盖原有文件 　　这里给出同样给出截至今天（北京时间日半夜3点）的最新升级包下载地址：　　　　或者： 。 　　下载的是.7zip的文件，可以用WinRAR或开源7zip软件解压全部文件，覆盖原目录下的文件，比如，我需要把它们解压:E:\CodeBlocks\ 目录下。　　要持续跟踪最新版本，请关注本网站，或者直接到前述官方论坛查看。　　2.2.2 试运行　　双击桌面上的Code::Blocks启动图标——如果没有，那就到开始菜单里找找。启动时，能看到一个启动界面，右
下若有显示“svn 5142”,那就说明安装及升级成功了。　　当然，你也可以在启动完成后，像其他软件一样，到“Help”菜单下找“About”查看详细版本信息。　　现在Code::Blocks还是英文界面的，接下来我们谈谈如何安装它的语言包。　　2.3 使用本地语言包　　首先，请在 X:\CodeBlocks\share\CodeBlocks\ 建立一个子文件夹：locale，注意 locale 全为小写字母。　　我对简体汉字的语言包做了较大改进，不过仍然没改完，另外，一些插件在当前版本本来就无法汉化的，所以还有一部分内容是英语的。繁体部分我没有改动。
d2school版Code::Blocks语言包下载。　　下载后，请解压到前述的locale目录下，则locale目录下，应出现zh_CN和zh_TW两个子目录。　　重新启动Code::Blocks，点击主菜单的“Settings”，选择“Enviornment”。出现的对话框中，左边选中“View”，右边打勾“Internationalization (needsrestart)”，并在后面的复合框中选中“Chinese (Simplified)”。确认退出本对话框。　　重启Code::Blocks。再看到的应该是中文简体界面了。
配置基本配置　　一款编程用的IDE，一定要不断根据自己的需要进行配置，才会变得好用起来。不过本文仅仅讲那些必选项。也就是如果没配置好，这个Code::Blocks就干不了活的选项。有关其它的选项，因为太多，我不可能现在就开始写，以后我会慢慢整理一些放在本站。需要的人，请多关注。主要会是一些常用的快捷键等配置，给不熟悉的人带个头，最终还是靠自己去配置。配置g++编译器及调试器　　2.41 配置g++编译器及调试器
请大家首先到 X:\CodeBlocks\MinGW\bin下，检查一下有没有以下文件：　　mingw32-gcc.exe 这是C的编译器。　　mingw32-g++.exe 这是C＋＋的编译器，同是地DLL（动态库）的连接器。　　ar.exe 这是静态库的连接器。　　gdb.exe 这里调试器。　　windres.exe windows下资源文件编译器。　　mingw32-make.exe 制作程序。　　都没有问题，请点击c::b主菜单“设置”（汉化前的&Settings&），这次选中“编译器和调试器设置...”。，出现的对话框中，右边选中“全局编译器设置”，然后对照下图，检查左边配置是否正确无误：　　现在我们就可以拿Code::Blocks来写课程里的很多C++代码了。　　对于Linux的使用者，由于GCC原生于Linux,所以只需下载Code::Blocks网站的.tar.gz即可。Code::Blocks对Debian系提供了更好的支援。对于Fedora的用户，只需要以root身份运行命令：yum install codeblocks 即可安装Code::Blocks。Code::Bolcks在Linux下运行
配置VC编译器　　先确定系统中已经安装 VC 的编译器。然后在编译和调试选项里选择 Microsoft Visual C++ xxx 之类。
我发现这个可以运行D3D的软件，OPENCl理论上可以做到，需要熟练者做试验，据说LINUX也可以通吃的
论坛徽章:0
Code::Blocks提供了许多工程模板，这包括：控制台应用、DirectX应用、动态连接库、FLTK应用、GLFW 应用、Irrlicht工程、OGRE应用、OpenGL应用、QT应用、SDCC应用、SDL应用、SmartWin应用、静态库、Win32 GUI应用、wxWidgets应用、wxSmith工程，另外它还支持用户自定义工程模板。在wxWidgets应用中选择UNICODE支持中文。
itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：　广播电视节目制作经营许可证：编号（京）字第1149号