首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    boost编译

    经历了将近半年多的时间boost终于发布了1.35.0版本(前版本1.34.1发布于2007/7), 其编译方法和原来的编译方法基本上是一致的,主要改变包括1.34.0以来bjam的toolset所 提供的参数名称的改变(具体参见《boost1.34.0编译日志》)外,还包括bjam的编译默认 选项的变化,在1.35.0之前的版本默认编译时会自动编译各种版本的库,包括静态库、 动态库、debug库和release库等全部的版本,但是到了1.35.0时默认的选择仅仅编译release 版本的库,这样一来在开发的时候就不能进行必要的调试了,为了能够使其编译全部的版本 需要在bjam的命令行参数中添加一个–build-type=complete类型的参数来指明需要编译全 部的版本,所需要编译同时为了使得regex库能够通过ICU库支持Unicode,在编译上需要有 一些特殊的选择。我在Visual Studio 2005 Pro + SP1环境下编译了该库,为了避免走弯路 所以将其编译的方法进行说明,以方便大家编译。 由于boost是采用其自己的bjam工具通过命令行进行编译的,所以必须在Windows下开启console窗口,同时必须将Visual Studio中C++目录下的环境vcvarsall.bat配置脚本运行一遍,以设置好VC的编译器环境变量。 1. 编译不带ICU支持的boost库 此种情况下的boost库编译起来比较的简单,在准备好的console窗口中输入:

    03

    Improving Stability with Private C/C++ Symbol in Android N

    As documented in the Android Nbehavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: theNDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES,libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.

    02

    CEGUI学习

    大家好,又见面了,我是你们的朋友全栈君。先来个引子,CEGUI是一个游戏UI库,开源,使用XML作资源定位,支持lua脚本,支持多字节语言的显示,其功能可以说是十分强大的,而且非常灵活,目前的稳定版本是0.5,可见其离发布还有一段距离,bug和未完成的东西都不少,然而这也是它的魅力之一,我们可以对其进行修改和扩充。使用CEGUI完全可以制作出一流水准的游戏UI来。 其次,也是比较主要的,它有几款指定的编辑器,其实UI库都差不多,关键就是看这个东西有没有编辑器,没有编辑器再好的戏也出不来,虽然它的这几个编辑器的bug比它本身还多,呵呵。 在对游戏引擎的支持上,Orge和CEGUI整合得非常好,是Orge的官方指定特约UI库。在更换接口部分之后,CEGUI理论上可以支持所有引擎。 其整个代码实现相当复杂,刚开始会觉得有点乱,但是捋一捋之后就会发现其实还是比较清晰的,只不过是因为其要实现的东西有点多,没办法,代码的复杂度也就上来了。 相关链接: CEGUI: http://www.cegui.org.uk/ WxWidgets: http://www.wxwidgets.org/ 简介 CEGUI(Crazy Eddie’s GUI http://www.cegui.org.uk)是一个自由免费的GUI库,基于LGPL协议,使用C++实现,完全面向对象设计。CEGUI开发者的目的是希望能够让游戏开发人员从繁琐的GUI实现细节中抽身出来,以便有更多的开发时间可以放在游戏性上。 CEGUI的渲染需要3D图形API的支持,如OpenGL或Direct3D。另外,使用更高级的图形库也是可以的,像是OGRE、Irrlicht和RenderWare,关键需求可以简化为二点: 1. 纹理(Texture)的支持 2. 直接写屏(RHW的顶点格式、正交投影、或者使用shader实现) 本文截止日时,CEGUI的最新版本是0.4.1(本文的讨论也是基于此版本),提供了SDK和全部源码的下载,同时为了适应不同的使用需求,还根据STL的使用区分为Native(VC自带的P.J. 版STL)和STLport(基于SGI STL实现的跨编译器版本,详细见http://www.stlport.org),以及VC6.0、VC7.0、VC7.1和VC8.0几种。 除此之外,CEGUI还同步提供了官方界面编辑器LayoutEditor,以方便UI的制作,下载地址:http://www.2dgame-tutorial.com/d … itorSetup_0.4.1.exe。作为界面编辑器,它需要系统级界面以提供编辑器操作,在此之前的0.3.0版是基于MFC实现的;而在0.4.1版本中,改为基于wxWidgets(跨平台的本地UI框架,这里的UI指Window操作系统底层,如:Windows、Unix和Mac,详见http://www.wxwidgets.org)实现。 OGRE作为目前最活跃的开源3D引擎,许多公司开始使用它进行游戏开发,原因也是其功能非常得全面和强大。在最初,OGRE曾经实现过一版UI,但是最后却放弃自己的实现而选择了CEGUI。 CEGUI的文件结构 CEGUI从根本上说,是由图片支持的,也就是说,这么庞大的系统说白了就是要正确地操作图片,抛弃了原来惯用的ini文件,CEGUI使用了更加先进的xml文件作为其配置文件,使用tga图片,这个是内嵌的,当然如果有需要,可以使用其它解码器。其文件结构很简单,共定义了四种格式的xml文件:scheme,looknfeel,imageset和layout。在CEGUI给的例子当中,其组织形式是这样的。 datafiles schemes looknfeel imageset layout 这样可以基本保证文件井然有序,建议就用这个结构,在你的游戏工程资源目录下增加这么一个datafiles文件夹。 这里首先介绍一下这几种文件的作用。 Scheme,它是CEGUI首先调用的一个文件,内容包括要使用的imageset文件、所对应的looknfeel文件,以及将要在looknfeel定义的控件的类型、工厂、渲染器和在looknfeel中的名字。 Looknfeel。它定义了控件的细节,我觉得在CEGUI自己给的那个例子looknfeel(TaharezLook)中写的就不错,很多时候可以模仿它来写。 Imageset,这个东西很简单,就是要把tga图片上的位置信息记录下来,位置信息由左上角横纵坐标,长宽信息组成。 另外,在Imageset文件夹下,还存放tga图片。 以上就是CEGUI的文件结构,多数情况下是不用动它的。 你的第一个CEGUI程序强烈建议仔细研究CEGUISample程序!因为那里介绍了它的一些基本用法,其实最后在游戏当中出现的,也就是这些例子的变化而已。 这里我会引导你写一个第一个自己的简单

    03

    侃侃哈希表

    说到哈希表,相信初通数据结构的人士应该耳熟能详,其相关的结构细节虽然并不繁复,但就快速查找数据而言,该结构优异的性能表现绝对可算一枝独秀,平均情况下O(1)的时间复杂度更是令人心旷神怡 :),这不,在近几天编写的一个简短程序中,我自己便遇到了需要使用哈希表的情况,由于自己惯于使用MinGW,其中的STL(SGI版本)刚好提供了一个优雅的哈希表的模板实现,名曰hashtable,并在此基础之上进一步构建起了hash_map、hash_multimap、hash_set以及hash_multiset,正好与标准模板库中的map与set容器一一对应,此番作为的确大快人心,可惜的是,作为SGI单独的扩展模块,哈希表现今仍然不在C++标准之列,这不能不令人扼腕叹息,所以即便我在MinGW中将hashtable用的生龙活虎,但只要稍稍转变一下编程环境,譬如转至MS的VS,那么等待我的大抵也就是一大堆的未定义错误,而上述的什么hashtable则更是踪迹全无……虽然有心人士早已提供了很多第三方库(如STLPort)用以解围,但这般编程境况仍然给我带来了些许不和谐之感,总觉着不是太合乎标准正道( 在此严重期待C++新一代标准的早日降临 :) ),没办法,最后想想还是决定走一走重造车轮的荆棘路,自己来实现一个简单的hashtable,当然,追求如STL库中那般的通用性并不是我的编程初衷,相反,简单够用倒是我的编写原则,既然如此,那么事不宜迟,就让我马上动手吧 :)。

    01

    Effective STL笔记

    #estl 第50条:熟悉与STL相关的web站点。三个:www.sgi.com/tech/stl、www.stlport.org 和 www.boost.org。 #estl 第49条:学会分析与STL相关的编译器诊断信息。嗯,第一招是替换大法,然后介绍了一下与容器、插入迭代器、绑定器、输出迭代器或算法相关的错误大概有什么套路看。 #estl 第48条:总是包含(#include)正确 的头文件。因为C++标准没有规定头文件的互相包含关系,所以不同的STL实现有所不同。要记住容器基本上声明在同名文件中,算法是algo..和 num..,迭代器在iterator中,函数子和配接器在functional中。 #estl 第47条:避免产生“直写型”(write-only)的代码。即所谓容易编写,但难以阅读和理解的代码,比如一行调用函数12次,其中 10 个是互不相同的。 #estl 第46条:考虑使用函数对象而不是函数作为STL算法的参数。嗯,因为函数对象更容易让编译器乐于内联,所以速度会快一些。从代码被编译器接受的程度而言,它们更加稳定可靠。 #estl 第45条:正确区分count、find、binary_search、lower_bound、upper_bound和equal_range。嗯,这与传入的区间是否已经排序有关,与你的目的有关,与容器有关,总之复杂,要自己去看这一小节两次。 googollee 我一直认为这个应该由重载来完成 RT @laiyonghao: #estl 第44条:容器的成员函数优先于同名的算法。原因:速度更快,且与容器结合得更加紧密,更能够与容器的行为保持一致。 #estl 第44条:容器的成员函数优先于同名的算法。原因:速度更快,且与容器结合得更加紧密,更能够与容器的行为保持一致。 #estl 第43条:算法调用优先于手写的循环。三个理由:效率更高,更不容易出错,和更好的可维护性。 #estl 第42条:确保less<T>与operator<T>具有相同的语义。真理总是如此平淡……还能说啥呢? #estl 第41条:理解ptr_fun、mem_fun和mem_fun_ref的来由。咳,想起当年理解 .* 和 ->* 的时候多么地头痛…… #estl 第40条:若一个类是函数子,则应使它可配接。因为 STL 的函数配接器要求一些特殊的类型定义,argument_type,result_type…之类。编写函数子从unary_function或 binary_function继承是一个不错的方案。 #estl 第39条:确保判别式是“纯函数”。纯函数即返回值仅仅依赖于其参数的函数。估计在这条阴沟里翻过船的人不少,哈哈哈。 #estl 第38条:遵循按值传递的原则来设计函数子类。换句话说就是让它们小巧,而且单态。这个条款的意义在于为赘重而且多态的函数子带来的问题提出一个解决方案,pimpl 惯用法。 #estl 第37条:使用accumulate或者for_each进行区间统计,前者的代码更明了一些,重要的是它们接受的函数子要求不同。 #estl 第36条:理解copy_if算法的正确实现。文中给出了一个正确实现,注意点是不能要求使用的函数子是可配接的,STL 算法都这样。 #estl 第35条:通过mismatch或lexicographical_compare实现简单的忽略大小写的字符串比较。 #estl 第34条:了解哪此算法要求使用排序的区间作为参数。嗯,STL 算法有不少是要排序的区间的,如果实参并非如此,轻则性能下降,重则逻辑错误,不可不察。 #estl 第33条:对包含指针的容器使用remove这一类算法时要特别小心。作为cpp程序员,一定要时刻警惕资源泄漏。boost::shared_ptr是一个好选择。 #estl 第32条:如果确实需要删除元素,则需要在remove这一类算法之后调用erase。嗯,讲的就是erase-remove惯用法的由来,另外在讲了一次不同容器删除元素的方法是不同的。 #estl 第31条:了解各种与排序有关的选择。简言之,介绍了partition/stable_partition/nth_element /partial_sort/sort/stable_sort的用法和适用场合。 吼吼,到这里,书就看了一半了。接下来是重头戏:算法。 #estl 第30条:确保目标区间足够大。特别是做覆盖的时候,一定要注意,可以先用resize撑大。插入时用back_inserter、front_…、 inserter和ostream_iterator。 #estl 第29条:对于逐个字符的输入请考虑使用istreambuf_iterator。先说了一下istream_it

    01

    扫码

    添加站长 进交流群

    领取专属 10元无门槛券

    手把手带您无忧上云

    扫码加入开发者社群

    相关资讯

    热门标签

    活动推荐

      运营活动

      活动名称
      广告关闭
      领券