http://media.xbox360.ign.com/media/866/866314/imgs_1.html

http://media.xbox360.ign.com/media/866/866314/vids_1.html

1. 每个material的id 最好用一个 64位 unsigned int 表示。当然如果你用 128位 unsigned int， 使用__mm128关键字， 也可以。这样可以相对减少排序复杂度。

2.  对于游戏里所有的texture和effect,最好分别有个 texture manager和effect manager, 对于相同的 texture和effect，给一个相同的 id： 分别是 texture id 和 effect id。 每个id是个8位的 byte就足够 了。同时支持256个effect和texture在内存中差不多是极限。

3. 关于material 的 id， 还需要包含物体的一些信息和到camera的距离，一般来说， 大概的定义如下：
union{
  struct {
    unsigned int    objectType       : 8;
    unsigned int    effectID         : 8;
    unsigned int    textureStage1    : 8;
    unsigned int    textureStage2    : 8;
    unsigned int    textureStage3    : 8;
    unsigned int    textureStage4    : 8;
    unsigned int    distanceToCamera : 8;
    unsigned int    renderstate      : 8;
  }
  unsigned __int64  matId;
}
上面的结构只支持4个texturestage，如果要支持更多，可以适当的修改。

里 边的objectType可以用来区分opaque, transparent 和 hud. 比如opaque 的id 是 1000,  transparent是 0100, hud是 0010, 这样排序时候可以保证是先渲染 opaque, 然后transparent，然后是 hud. 

对于effect 和 texture 哪个放在前面，主要是看哪种资源更换的更频繁。这个需要具体测试才知道。关于距离的问 题，对于opaque，需要做位反操作，因为是从近到远排序。 同时对于transparent的物体，distance可能要和effect或者 texture stage 1的位置换以下，因为从远到近排序更重要一些。

还有对于material的内部const value或者render state排列，很多时候是在build time进行的。

4.  只考虑了material的系统。也可以算是effect system. 但是effect system的话还是缺少  post effect 的支持。 其次是光靠这里排序是不够的，因为很多effect内部可以改变render states. 因此还需要增加一 个effect states manager，DX里边就有这个. 具体结构可 以参考 shader X4里边 "tips and tricks for d3dx effects-based renderers".

Terrain Rendering:

http://www.gamedev.net/reference/articles/article1936.asp

http://www2.imm.dtu.dk/pubdb/personal/showbasket.php?cmd=full_view&id=53&title=Publications&header=&footer=&css=&f=1&b=1&e=1&year=&fmt=html&order=year

http://research.microsoft.com/~hoppe/

Texture:

http://ati.amd.com/developer/NormalMapCompression.pdf

http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf

http://www.gamedev.net/community/forums/topic.asp?topic_id=183462

http://www.delphi3d.net/articles/viewarticle.php?article=stateman.htm

http://www.gamedev.net/community/forums/topic.asp?topic_id=183462

1. All resource needs to be carefully managed, the best way to do that is using IUnkown like interface. Every time a resource is acquired, the code increases the reference count internally, and the client releases the resource externally, which decrease the reference count.
2. Basic stuffs need to be thread safe, things like basic data structures: queue, link list, etc. and memory allocation functions. All lock-free algorithms are very good candidates but it’s very hard to get it correct; Anyway, it’s worth it. For the lock-free ABA problem, an iterator can be used to indicate an element is referenced by a client. When the iterator moves away ( ++ or -- ), or get deleted, the reference count of the element can be decreased. This provides good way to manage the delete items for non-managed code.
3. for the memory management, several points need to be taken into account:
   1. It’s useful to remember the caller thread ids,  source filename, and line numbers for each memory allocation in debug mode. So it’s very easy to find out where the memory leakage happens.
   2. An allocated memory needs two memory guard bytes, one at the beginning, and one at the end. It helps to find out memory overflow problem
   3. Memory reference count and allocation count is very important. It’s the first place to detect memory leakage.
4. For a good game editor here are several points:
   1. It should be a MVC architecture, and use the events to update the view from the controller, not the model!!!!!!!
   2. The model data should be like an object database, for all objects in the database, they should share a common interface for object management. And each object should have sibling and children data structure support for maintaining a well-defined, flexible object database structure.
   3. All tools logic should be happened in the controller. But the controller can be separated into two parts: a command line based controller, and GUI based controller. These two parts can be independent from each other, or the GUI based controller is based on the command line controller.
   4. The rendering is really not a big deal, but the key problem is the events that require to update the UI element from the controller may overwhelm the graphics capability. So the good way to design the view is maintaining an update requests cache and only do one update for the UI element if there are several same update requests from the controller.
   5. C# is the best choice for game editor (This is the really my point! )
5. For the graphics pipeline, there are the things are necessary at the build time:
   1. Collapse model, which made a single vertex buffer and index buffer for all the models in a scene. So this may introduce some limitations, but it can reduce draw calls a lot.
   2. Vertex sharing is very very important. But I really want to know the different between using one stream and the using multiple streams for the vertex data sharing. Just don’t have enough time to try.
   3. Materials need to be merged and sorted first, same material with different parameters needs to be grouped together to minimize the states changes.
   4. All the data binding, for example: the material, and the textures this material use, should be indicated by a string CRC token, rather than the direct pointer or index whatever. This gives flexibility that resource can be managed by different software module. For example, models can be managed by model manager, and texture can be managed by texture manager. The pointer can be obtained at the initialization time to allow fast resource access.
   5. Animations needs to be optimized, unnecessary animation keys should be removed.
   6. After that, the triangle strip needs to be created at the build time.
   7. All light maps should be generated at the build time or scene creation time, different light map can use different channels in one texture to save the memory space.
   8. Within the pipeline, the fx file should be exist in ASCII format rather than the compiled binary format. This gives the flexibility to post process the fx code and make it portable on different platform.
   9. Vertex data should be compressed to save the video memory and bandwidth.
6. For the run-time graphics:
   1. Instancing with LOD really sucks. I think the instancing can be obtained by pre-generate an index buffer and vertex buffer with multiple objects of the same model and use draw index call to control how many instance should be rendered. Each instance individual data (like position) can be obtained from a matrix in a matrix list sent from the CPU to GPU. The index of the matrix in the matrix list should be stored in the vertex data ( one byte should be enough. )
   2. Rendering order should be take care. Opaque first, then transparent stuffs, then HUD. A good way to do this is using 3 display lists, and each display list is for one type of rendering only.
   3. The render should be sorted by effect | material | texture | distance …….. For each sub-object in an object’s materials, and id should be generated for sorting. The id can be a 64 bits number with: effect id ( 63 – 58 ) | material id ( 57 – 50 ) | texture id for all stages (49 – 20 ) | distance 18 – 6 | other ids ( 5 – 0 ). A quick sort would be enough to sort all sub-objects. The order of each element in the id can be changed to reflect different priorities.
   4. Multi-thread should be used: one thread to calling rendering api, one for updating game objects, one for updating partcles, clouds, waters, trees and non-important environments etc…… So all the game world should be separated into two parts, one part is the object that can affect the game-play, another part is not.

That’s all that I can remember right now, I will add more stuffs if I get something.

Illustration & Sculpture

Image-guided maze construction (project page)

Jie Xu, Craig S. Kaplan (University of Waterloo)

Dynamic Planar Map Illustration

Paul Asente Mike Schuster Teri Pettit (Adobe Systems Incorporated)

Interactive cutaway illustrations of complex 3D models (project page)

Wilmot Li, Lincoln Ritter (University of Washington), Maneesh Agrawala (University of California, Berkeley), Brian Curless, David Salesin (University of Washington)

Digital Bas-Relief From 3D Scenes

Tim Weyrich, Jia Deng, Connely Barnes, Szymon Rusinkiewicz, Adam Finkelstein (Princeton University)

Performance Capture

Multi-Scale Capture of Facial Geometry and Motion

Bernd Bickel, Mario Botsch Roland Angst, (ETH Zürich), Wojciech Matusik (Mitsubishi Electric Research Laboratories (MERL)), Miguel A. Otaduy (ETH Zürich), Hanspeter Pfister (Mitsubishi Electric Research Laboratories (MERL)), Markus Gross (ETH Zürich)

Capturing and Animating Occluded Cloth

Ryan White (University of California, Berkeley and University of Illinois at Urbana-Champaign), Keenan Crane, David Forsyth (University of Illinois at Urbana-Champaign)

Practical Motion Capture in Everyday Surroundings

Daniel Vlasic (Massachusetts Institute of Technology), Rolf Adelsberger (Mitsubishi Electric Research Laboratories (MERL) and ETH Zürich), Giovanni Vannucci, John Barnwell (Mitsubishi Electric Research Laboratories (MERL)), Markus Gross (ETH Zürich), Wojciech Matusik (Mitsubishi Electric Research Laboratories (MERL)), Jovan Popovi]]> aear http://blog.sina.com.cn/s/blog_4b3173c501000a9b.html#comment Wed, 08 Aug 2007 20:57:51 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c501000a9b.html http://blog.sina.com.cn/s/blog_4b3173c501000a9a.html

Squish, Bounce, and Collide

Volume-Conserving Finite Element Simulation of Deformable Models

Geoffrey Irving, (Stanford University and Pixar Animation Studios), Craig Schroeder (Stanford University) Ron Fedkiw (Stanford University and Industrial Light & Magic)

Many-Worlds Browsing for Control of Multibody Dynamics

Christopher D. Twigg (Carnegie Mellon University) Doug L. James (Cornell University)

Continuous Collision Detection for Articulated Models using Taylor Models and Temporal Culling

Xinyu Zhang (Ewha Womans University), Stephane Redon (INRIA), Minkyoung Lee, Young J. Kim (Ewha Womans University)

A Finite-Element Method for Animating Large Viscoplastic Flow

Adam W. Bargteil (Carnegie Mellon University) Chris Wojtan (Georgia Institute of Technology) Jessica K. Hodgins (Carnegie Mellon University) Greg Turk (Georgia Institute of Technology)

Shape Depiction and Stylization

Locally Controllable Stylized Shading

Hideki Todo (The University of Tokyo), Ken Anjyo, William Baxter (OLM Digital, Inc), Takeo Igarashi (The University of Tokyo)

Line Drawings Via Abstracted Shading

Yunjin Lee, Lee Markosian (University of Michigan), Seungyong Lee (POSTECH) John F. Hughes (Brown University)

Apparent Ridges for Line Drawing

Tilke Judd, Frédo Durand (Massachusetts Institute of Technology, Computer Science and Artificial Intelligence Laboratory) Edward H. Adelson (Massachusetts Institute of Technology, Department of Brain and Cognitive Science and Computer Science and Artificial Intelligence Laboratory)

Dynamic 2D Patterns for Shading 3D Scenes

Simon Breslav Karol Szerszen, Lee Markosian (University of Michigan), Pascal Barla, Jo雔le Thollot (INRIA Grenoble University)

Point Sets

Global Non-Rigid Alignment of 3-D Scans

Benedict J. Brown, Szymon Rusinkiewicz (Princeton University)

Parameterization-free Projection for Geometry Reconstruction

Yaron Lipman, Daniel Cohen-Or, David Levin (Tel Aviv University), Hillel Tal-Ezer (Academic College of Tel-Aviv Yaffo)

Algebraic Point Set Surfaces

Ga雔 Guennebaud, Markus Gross (ETH Zürich)

Direct Visibility of Point Sets

Sagi Katz, Ayellet Tal (Technion), Ronen Basri (The Weizmann Institute of Science)

Lighting

The Lightspeed Automatic Interactive Lighting Preview System

Jonathan Ragan-Kelley (Massachusetts Institute of Technology) Charlie Kilpatrick, Brian Smith (Industrial Light & Magic), Doug Epps (Tippett Studio), Paul Green (Massachusetts Institute of Technology, Computer Science and Artificial Intelligence Laboratory), Christophe Hery (Industrial Light & Magic), Frédo Durand (Massachusetts Institute of Technology, Computer Science and Artificial Intelligence Laboratory)

Matrix Row-Column Sampling for the Many-Light Problem

Milos Hasan (Cornell University), Fabio Pellacini (Dartmouth College), Kavita Bala (Cornell University)

Interactive Relighting with Dynamic BRDFs

Xin Sun (Zhejiang University), Kun Zhou, Yanyun Chen, Stephen Lin (Microsoft Research Asia), Jiaoying Shi (Zhejiang University), Baining Guo (Microsoft Research Asia)

Frequency Domain Normal Map Filtering

Charles Han, Bo Sun, Ravi Ramamoorthi, Eitan Grinspun (Columbia University)

]]> aear http://blog.sina.com.cn/s/blog_4b3173c501000a9a.html#comment Wed, 08 Aug 2007 20:57:09 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c501000a9a.html http://blog.sina.com.cn/s/blog_4b3173c501000a99.html Here is the original link of the source: http://trowley.org/sig2007.html . I copy it here just in case there page is not available in some case.



Image Analysis & Enhancement

Image Deblurring with Blurred/Noisy Image Pairs

Lu Yuan (The Hong Kong University of Science and Technology), Jian Sun (Microsoft Research Asia), Long Quan (The Hong Kong University of Science and Technology), Heung-Yeung Shum (Microsoft Research Asia)

Solid Texture Synthesis from 2D Exemplars

Johannes Kopf (Universit鋞 Konstanz), Chi-Wing Fu (The Hong Kong University of Science and Technology), Daniel Cohen-Or (Tel Aviv University), Oliver Deussen (Universit鋞 Konstanz), Dani Lischinski (The Hebrew University), Tien-Tsin Wong (The Chinese University of Hong Kong)

Photo Clip Art

Jean-Fran鏾is Lalonde, Derek Hoiem, Alexei A. Efros (Carnegie Mellon University) Carsten Rother, John Winn, Antonio Criminisi (Microsoft Research Cambridge)

Scene Completion Using Millions of Photographs

James Hays, Alexei A. Efros (Carnegie Mellon University)

Character Animation I

Active Learning for Real-Time Motion Controllers

Seth Cooper (University of Washington), Aaron Hertzmann (University of Toronto), Zoran Popovi

]]> aear http://blog.sina.com.cn/s/blog_4b3173c501000a99.html#comment Wed, 08 Aug 2007 20:52:55 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c501000a99.html http://blog.sina.com.cn/s/blog_4b3173c5010009f4.html 连续加了将近半年的班，最近总算全部搞定了。下面是Aear参与制作的新游戏

名称： Fantastic Four 2: rise of the silver surfer （也就是传说中的神气4傻2）
类型： ACT
网站： http://www.2kgames.com/riseofthesilversurfer/
视频： http://www.youtube.com/watch?v=UDTEcguwaYI
平台： XBOX XBOX360 PS2 PS3 GameCube Wii ..... ( 就是无PC )

其 实就是个movie game,　个人感觉也就一般，就跟金庸小说改编的电视剧一样好不哪里去。整个游戏做了３年，２年引擎，一年的GamePlay。主 要是电影拍的太快了，为了能和电影同时发行没有太多的时候做内容。公司估计投了可能有2000W$吧，　个人感觉不卖个200W 份copy是赚不回来 的。基本上亏本是很有可能了。不管怎么说，总算搞定了。大家有钱的捧个钱场，没钱的捧个BT，Emule场。。。。。对了，我只参与制作了 xbox360 和 ps3的版本，　所以其他的平台版本都不是很好，就不要玩了。

下面是一些游戏画面：





]]> aear http://blog.sina.com.cn/s/blog_4b3173c5010009f4.html#comment Thu, 14 Jun 2007 16:25:26 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010009f4.html http://blog.sina.com.cn/s/blog_4b3173c5010007w2.html
原图看这里：
http://www.1up.com/do/media?cId=3154980&sec=IMAGES








 

Fantastic Four: Rise of the Silver Surfer (Xbox 360)

	Rate It: 1 2 3 4 5 6 7 8 9 10
Average Rating: 8.1	Page: 1 2 3  4 5 < >

]]> aear http://blog.sina.com.cn/s/blog_4b3173c5010007w2.html#comment Mon, 12 Mar 2007 17:35:54 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010007w2.html http://blog.sina.com.cn/s/blog_4b3173c5010007qy.html 下面的文章转自：
http://xbox360.ign.com/articles/767/767699p1.html

NYCC 07: Fantastic Four: Rise of the Silver Surfer First Look

You get to battle Super Skrull? Say no more.

by Chris Carle

February 26, 2007 - Today at New York Comic-Con, we were treated to a special sneak peek of the newest Marvel game, Fantastic Four: Rise of the Silver Surfer. Developed by a brand new team at Visual Concepts and based on the upcoming movie sequel, the game features realistic models patterned after the actual actors and actresses from the film. If you have ever dreamed of playing with Jessica Alba or Chris Evans, here is your chance.

Although versions of the game are being developed for the Wii, PS2 and DS, the Xbox 360 game is a much different experience. The game is the same in that it is a team-based superhero brawler with an emphasis on action and cooperative play.

The game is set in the world of the upcoming film, but also draws from the pages of the comics for some extra story elements. For instance, the early stages of the game take the team to an alien Skrull mine, which we were assured is definitely not a scene in the film.

Unfolding over six massive levels, the game features plenty of large-scale combat and emphasizes interaction between characters. Most intriguing are the fusion attacks, which take the normal character abilities and mesh them into more powerful team moves with the ability to deal massive damage.

We saw a couple of these in action, and can't wait to check out even more. In one, Sue Storm makes a ball of force energy which Johnny pumps full of fireballs. The resulting ball of flame is a powerful attack, indeed. In another, Mr. Fantastic stretches into slingshot formation and pile-drives The Thing into the turf for an extra-heavy slam attack.

In addition to puzzle-solving elements and straight-up combat, a couple of other wrinkles have been added to mix it up. In one of the levels, Johnny Storm flames on and blazes forward, and the action switches to an on-rails shooter as he careens forward through the level.

Who are the baddies? The Skrulls, longtime alien foes of the Fantastic Four, are common fodder, and a jumbo-sized Super Skrull is even a boss in the game. Super Skrull, for those unaware of the comic, is an oversized alien badass who has developed the ability to use some of the 4's powers…and his rocky, Thing-like arm is perfect proof. As a boss, he looks large and menacing, and the model is amazing. Other villains include old schooler Red Ghost, and of course, Dr. Doom.

Overall the game looks astounding, with great character models, excellent lighting, and cool animations. This ain't your mama's Fantastic Four game! We'll have more on all versions of Rise in the coming months, so keep your browsers pointed to IGN for all of the breaking developments.

]]> aear 游戏业界咨询 http://blog.sina.com.cn/s/blog_4b3173c5010007qy.html#comment Wed, 28 Feb 2007 16:32:36 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010007qy.html http://blog.sina.com.cn/s/blog_4b3173c5010007od.html
更高分辨率的视频到这里看：

http://www.gametrailers.com/gamepage.php?id=4444



（上面的视频转自www.gametrailers.com）
]]> aear http://blog.sina.com.cn/s/blog_4b3173c5010007od.html#comment Fri, 23 Feb 2007 22:24:53 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010007od.html http://blog.sina.com.cn/s/blog_4b3173c5010007dl.html 在库里有class A和class B，Class A有个Static Member functions用来对Class A进行初始化。在 Class B中掉用Class A，所以要保证在使用Class B的时候 Class A已经正确初始化了。那么可以在写程序的时候显式的对A进行初始化，但是这种方式太累赘，容易犯错误，另一种方式如下：

    // class A header file

    class A
    {
        .... // Class A member and interface

        // Helper class
        class AInitHelper
        {
            static int _initRefCount;
            AInitHelper() {
                if( _initRefCount++ == 0 ) ... // Class A init here
            };

            ~AInitHelper() { ... // Deinit here };

        };

    };

namespace {

A::AInitHelper __init;

};

在class B 的cpp 文件中 #include "a header" 这个时候由于是unnamed namespace，所以会单独建立一个AInitHelper __init的拷贝。

然后 int AInitHelper::_initRefCount = 0;

这个时候由于__init是全局，那么必然先于class B进行初始化。由于在unnamed namespace里，所以即使其他 file include A的header,也会有不同的__init，所以可以保证每个include A的module，都会进行_init的初始化，从而检查class A是不是已经初始化了。保证正确的初始化顺序。这是STL中解决模块之间初试化依赖关系的标准方案.

]]> aear 程序设计随笔 http://blog.sina.com.cn/s/blog_4b3173c5010007dl.html#comment Mon, 29 Jan 2007 20:37:24 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010007dl.html http://blog.sina.com.cn/s/blog_4b3173c5010007dj.html 一般来说，client和server之间的数据交换，分为几个优先级，大部分情况下是下面3种：
1. 不可以丢失，但是不要求速度。
2. 不可以丢失，但是要求速度,确并不是非常严格。
3. 可以丢失，但是要求速度

对 于1来说，最直接的例子就是聊天信息，动态的地图信息。这些数据不是time-critical的，所以应该使用TCP连接。 在大多数情况下，有专门的  voice/chat server和map server,client到每个server有个TCP连接。一个client有多少个连接根据需要决 定。同时有2-3个连接并没有多大开销。当然，如果开销很大，就是程序设计的问题了。其实你想想开BT的时候同时有4,50个连接，你用其他程序的速度并 没有慢多少。

对于2来说，比较显著的例子是战斗信息，动作序列。 比如一个人玩游戏，用鼠标点了下地图上的一个坐标，那么人物向这个坐标 前进。这个信息从server转发到其他的client,当然越快越好，如果client没收到，就要重发，否则client就看不到这个动作。如果你玩 过wow的盗贼，就会发现在网络卡的时候，经常先偷袭，按下键盘以后要等一会才看到攻击动作，就是这个原理。当然这里数据需要经过server的处理，每 次打包多个client的动作，和顺序，然后发送。需要复杂的server端逻辑处理。这种应该使用UDP，同时对所有的UDP包编号（用来防止2次处 理），使用slide window类似的协议进行重传。

对于3来说，就是位置信息。 位置信息可以丢失，但是由于这种信息更新的最频繁， 所以即使丢失其中一个，也可以根据 dead reckoning 算法进行位置预测和修正。 dead reckoning算法有很多变种，适合多类情 况。 比如你见过wow里，如果一个人掉线，但是一直往前不停的跑，那多半就是算法进行的预测。偶尔你会发现网络卡的时候，刚刚走到一个地方就退回到原来 的位置，就是因为你的动作数据包(2里的)没发送出去，导致update world position的时候，算法进行位置修正的结果。这类数据应该使 用UDP.

需要说明的是 UDP和TCP无明显分界。 TCP相比UDP，有3个主要缺点，1是slow start, 2是 throughput jitter, 3是insistence on reliability(相对的，不时绝对缺点). 在数据传送量比较小,网络 状况比较稳定的情况下，使用TCP和UDP无大分别。

对于防火墙穿透，如果你是做client的，不需要关心这个问题，因为你往Server发数据，建立连接，都不会受到防火墙的影响。不过server端对于放火墙可以有几种实现方式：

1. 最差的方式是client发送SYN包给服务器，在防火墙或网关上建立NAT地址，然后 Server之需要取得这个NAT地址，把所有的数据包都封装成SYN-ACK包，发给client就行拉。这样做比较省事。但是无法穿透 stateful firewall

2. 是比较好的方式。 不过需要先建立TCP连接，然后对server发送正常的UDP包。大部分的NAT网关会为UDP专门建立个NAT地址，那么通过这个地址，server就可以发UDP包了。但是并不是所有的firewall都会为UDP建立单独的NAT地址。

3.  是最好的方式，由于防火墙不会阻止内部网发起的TCP连接，所以TCP进行数据传输没有任何问题。对于Server/Client来说，只要使用 Raw Socket模拟TCP协议，但是这个模拟的TCP协议使用UDP的本质，没有slide window, 没有 congestion control, 没有flow control等等，这种实现最麻烦，但是几乎能处理所有的防火墙。

4. 其实没 有4，不过实在想提下这种最强技术. 就是所有的Server到Client的数据包都可以是ICMP echo reply message. 由于种 种原因，firewall不太可能禁止ICMP echo,所以这类消息也是很容易传送到client,但是。。。。。。。。Client如果有 IDS system,很容易把你的sever归类到入侵扫描的范围。所以不用最好。

如果你们不是采用第3种方式，并且你只写client,那么防火墙跟你就没有什么关系。都是server的事。 ]]> aear 程序设计随笔 http://blog.sina.com.cn/s/blog_4b3173c5010007dj.html#comment Mon, 29 Jan 2007 20:29:02 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010007dj.html http://blog.sina.com.cn/s/blog_4b3173c501000717.html
Aear估计最近没时间写什么东西了，不过还是欢迎大家来这里玩。

祝大家过的开心！
]]> aear 胡砍乱砍 http://blog.sina.com.cn/s/blog_4b3173c501000717.html#comment Mon, 08 Jan 2007 18:28:40 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c501000717.html http://blog.sina.com.cn/s/blog_4b3173c5010006nt.html ======================================================
大家请把我的文章当参考，详细内容 还请参照 权威书
籍如果文中有错误和遗漏， 请指出，Aear会尽力更正,
谢谢！
Aear Blog: http://blog.sina.com.cn/u/1261532101
======================================================

说到Exception就要说下相关的Error Handling. 比较常用的Error Handling一般有如下几种类方式：
    1. Return Value
    2. Assert
    3. Debug Output
    4. Exception

相对于其他三种错误处理方式， Exception更加容易使用，而且使得错误代码相对集中，同时使得独立函数库的开发更加方便。 同样，对于C++来说， Exception提供了Class的Constructor 和 Operator = 错误处理机制，因为这两者都不是能够通过return value进行报错的。

但是就游戏开发来说， Exception最大的缺点是内存和CPU的开销。当然，不是说游戏的代码中不应该使用Exception。 Aear见过用Exception的游戏代码，也有完全不用Exception的代码。因为对游戏来说，应该在运行过程中保持自身状态的正确性，不应该产生任何的无法处理的Exception。 而所有能够自己处理的错误情况，都是能够通过Return Value 来解决的。 唯一可能产生Exception的地方，就是系统资源，比如磁盘文件，网络等。不过大部分系统掉用都提供非Exception的错误处理。不过程序开发各不相同，用不用Exception可能还是需要大家自行决定。

Aear个人观点是能不用Exception，就不用Exception,但是应该用Exception的时候，一定不要省。比如constructor里。

============ Exception的用法 ============

要使用Exception, 要么用系统的Exception的类，要么定义自己的类。 在定义自己类的时候，可以继承STD里边的Exception类，也可以创建自己新的类。比如：

class ExceptionBase{
    ...
};

class ExceptionDerived : public ExceptionBase{
    ...
};

需要注意的是，通常定义自己的Exception类的时候，都要有一个公共的Base Exception Class, 这样能够保证写代码的时候catch所有的你自定义的Exception,比如：

try {
    ...
}catch( ExceptionDerived & e ) {
    ...
}catch( ExceptionBase & e ) {

    // Catch 其他的Exception， 这样的设计即使今后添加新的Exception,只要
    // 是从ExceptionBase继承来的，都会被catch到。

}catch( ... ) {

    // 这里最好再加上 catch(...)来catch所有的exception，防止有未catch的    // exception. 因为如果有unexpected exception, C++的缺省动作是直接
    // 终止程序的运行。

};

============ Exception in Constructor ============

如果一个Constructor产生exception而且没有被程序catch到的话，那么这个object的创建就会失败, 比如：

class MemoryBlock {
private:
    void * _pMem;
public:
    MemoryBlock ( UINT32 size )
    {
       _pMem = new char[size];
    };
    ....
};

MemoryBlock myMemory(100000000000000000000000000);

如果new在分配内存的过程中throw一个Exception ,通常是 bad_alloc， 那么myMemory的创建就会失败，以后任何对 myMemory的成员访问，都是非法的，会导致程序的崩溃。

让我们看看另一中写法：

class MemoryBlock {
private:
    void * _pMem;
public:
    MemoryBlock ( UINT32 size ) :
       _pMem(new char[size])
    { };
    ....
};
上面也是合法的，不过会产生同样的问题。但是区别在于如果在代码中catch到exception，那么第一种写法，能够保证object被创建，而第二种写法不能。比如：

    // MemoryBlock 能够被创建
    MemoryBlock ( UINT32 size )
    {
       try {
           _pMem = new char[size];
       } catch(...) {}
    };

    // MemoryBlock 创建失败
    MemoryBlock ( UINT32 size )
    try
       : _pMem(new char[size])
    { } catch(...) {};


============ Exception in Destructor ============

其实对于Destructor来说就一句话，不能在Destructor中Throw Exception。 原因很简单，因为通常Destructor要么在Delete Object中掉用，要么在已经Throw了Exception的时候，由系统掉用。如果在Throw Exception的情况下再Throw Exception的话，那么程序就会强制终止。

============ Exception in Operator ============

这个是比较麻烦的，通常的Exception的处理有好几个级别， Basic, Strong, Nofail.我们这里只说下Strong Exception Safety。 下面是个例子:

class X {
    ...
private:
    void * _pMem1;
    UINT32 _pMemSize1;
    void * _pMem2;
    UINT32 _pMemSize2;

public:
    X& operator = ( const X & xo )
    {
        if( _pMem1 ) delete _pMem1;
        if( _pMem2 ) delete _pMem2;
        
        _pMem1 = new char[xo._pMemSize1];
        _pMem2 = new char[xo._pMemSize1];
        ...
    };
};

这里如果 _pMem2 = new char[xo._pMemSize1]; Throw一个Exception，那么X只是被Copy了一半。 状态是不完整的。但是原来在pMem1&2中的数据已经消失了。如果是Strong Exception Safety,那么要求如果throw excpetion，那么class的数据应该恢复在之前的状态，比如经典的exception safe operator = 如下：

    X& operator = ( const X & xo )
    {
        X temp(xo);
        swap( *this, temp );
        return *this;
    };

swap是交换*this 和 Temp的所有数据。通常我们能够保证这个过程没有任何exception的产生。因此即使 temp(xo) throw一个exception， 也不会影响当前类的任何状态变化。


============ RAII ============

最后说一种不使用Exception而能保证没有Resource Leakage的技术。那就是 Resource Aquisition Is Initialization ( RAII ). 其原理很简单，就是C++标准保证一个被成功创建的 Object， 无论任何情况下（即使是在Throw exception ）， 它的 Destructor都会被掉用。 因此，我们可以用一个object 的constructor 来获取资源，用Destructor来释放资源。下面举个最简单的应用，thread 的 asynchronization:

class CriticalSection {
public:
    CriticalSection( CRTICIAL_SECTION *pCs ) :
       _pCs(pCS)
    { EnterCriticalSection( _pCS ) };

    ~CriticalSection( )
    { LeaveCriticalSection( _pCS ) };
private:
    CRTICIAL_SECTION * _pCs;
};

通常我们使用Critical Section的时候，用下列方式：

void threadXX( CRTICIAL_SECTION * pCs)
{
    EnterCriticalSection( pCS );

    void * pTemp = new char[100000000];

    LeaveCriticalSection( pCS );
}

问题是如果     void * pTemp = new char[100000000]; Throw一个 bad_alloc,那么 LeaveCriticalSection( pCS );就不会被掉用而直接返回，很容易导致死锁。类似的代码在游戏服务器端的设计是很常见的，正确的做法是使用上面定义的类：

void threadXX( CRTICIAL_SECTION * pCs)
{
    CriticalSection temp( pCS );

    void * pTemp = new char[100000000];
}

由于即使throw exception， C++保证temp的destructor一定会被调用。因此不会产生死锁的情况。

============ 其他 ============

比如下面的代码是很容易产生问题的：
    function( new char[100], new char[300] );
如果new char[300]throw exception，那么 new char[100]很有可能就不会被释放。

推荐使用auto_ptr或者boost中的Shared_ptr，特别是在class 的initialization list 中， 比如下列做法不使用catch exception也不会产生内存泄露：

class X{
    X() :
    _ptr1(new XXX()),
    _ptr2(new XXX())
    {};

private:
    auto_ptr<void *> _ptr1;
    auto_ptr<void *> _ptr2;
}

Destructor中不需要catch exception，因为destructor主要是调用其他的destructor，没有任何的destructor会throw exception的，所以没必要catch.

这次就说这么多，大家过的开心，下次见！

















]]> aear 程序设计随笔 http://blog.sina.com.cn/s/blog_4b3173c5010006nt.html#comment Sun, 24 Dec 2006 17:28:20 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010006nt.html http://blog.sina.com.cn/s/blog_4b3173c5010006jz.html ======================================================
大家请把我的文章当参考，详细内容 还请参照 权威书
籍如果文中有错误和遗漏， 请指出，Aear会尽力更正,
谢谢！
Aear Blog: http://blog.sina.com.cn/u/1261532101
======================================================

在OO中Base Class最多的应用有2种方式，第一种是interface,也就是基类是个abstract class, 最典型的例子是Factory Design Pattern. 第二种方式是Base Class 提供一种机制，然后提供几个Virtual Function,允许使用者对这个类进行重载，从而达到“配置” (customization)的目的。 其典型的代表是 MFC，通过继承提供消息传递机制的CWin类的OnPaint等函数，实现更多更强大的功能。

这次就主要讲讲这两种类的设计。

============== Abstract Interface ==============

对于Interface Class来说，基类一定是个Abstract Class. 其含义是一类物体的抽象概念。比如下面一个例子：

class Gun {
public:
    void Shoot    (void) = 0;
    ...
};

Gun是所有人的抽象概念，具体的实现起来可以为Eagle, AK47, MD5 等等。所有的枪都有射击的功能，但是他们具体射击的方式不同， 因此只要提供一个Shoot的Interface,内容由派生类来实现。

在具体设计 Interface Class的时候，有几个需要注意的内容：

1. 最好只提供 pure virtual function。 这样做能够使Interface Class更加单一，更加纯净，更加漂亮，更容易维护。Interface就只能是Interface，不应该提供其他任何东西。因为Interface仅仅是一个描述。

2. 最好没有data member。Data Member往往会限制 Interface Class的灵活性。而且有Data Member，一般就要有Accessor Function,使得Interface Class不再纯洁。。。。。。

3. 如果不得不用Data Member,那么一定要提供带参数的Constructor,并且把确省的Constructor设成private.例如：

class InterfaceClass {
private:
    UINT32   _dataMember;
public:
    Base()      {};
    ...// other interface      
};

class Derived : public InterfaceClass {
public:
    Derived()    {};  
};

上面代码中的Derived Constructor是合法的，但是由于写代码的人粗心大意，忘记给_dataMember附初值，很容易造成程序的崩溃。所以，对于有data member的Base Class 正确的写法是：

class InterfaceClass {
private:
    UINT32   _dataMember;
public:
    Base( UINT32 data ) : _dataMember(data) {};
    ...//other interface
};

4. 在大部分情况下，Base Class的Destructor 一般要放到public 里边，并且要有实现，也就是说至少是空的实现，"{ }"，即使是pure virtual destructor，这个 {}也是不能少的。因为还很多情况下，都需要通过Interface 调用Destructor来释放object. 如：

class InterfaceClass {
public:
    ~InterfaceClass() {};  
};

======= Derived Class的管理 =======
对于Interface Class来说，如果Derived Class太多，是很难管理的，不过我们可以通过统一的ClassManager来实现。下面是个小例子：

// Interface
class InterfaceClass {
public:
    virtual void SomeInterface( void ) = 0;

private:
friend class ClassManager;  
    ~InterfaceClass()     = 0     {};  
};

// First Concrete Derived Class
class Derived1 : public InterfaceClass {
public:
    virtual void SomeInterface( void )    { ... };

private:
friend class ClassManager;  
    Derived1()   {...};
    ~Derived1()   {...};
};

// Second Concrete Derived Class
class Derived2 : public InterfaceClass {
public:
    virtual void SomeInterface( void )    { ... };

private:
friend class ClassManager;  
    Derived2()   {...};
    ~Derived2()   {...};
};

// Class Manager
// Singleton
class ClassManager
{
public:
    static ClassManager* GetInstance( void )
    {
       static ClassManager instance;
       return &instance;
    }
   
    InterfaceClass * GetDerived1(void) { return new Derived1() };
    InterfaceClass * GetDerived2(void) { return new Derived2() };  

private:
    ClassManager();  
    ~ClassManager();
};

============== Concrete Base Class ==============

Concrete Base Class是使用的比较多的。游戏中经常有的object之间，差别非常的小，这些都可以通过Concrete Base Class来抽象，提高代码重用的效率。比如 Design Pattern中比较著名的 Strategy Pattern. 下面是 Strategy Pattern的小例子：

class StringArray {
public:
    void AddString() {...};
    void SearchString() {....};
    void SortString( void ) { StrategySortString(); };
    ...
private:
    virtual StrategySortString ( void )
    { ... };   // bubble sort
};  

class StringArray2 : public StringArray {
    ...
private:
    virtual StrategySortString ( void )
    { ... };   // quick sort
};  

假设我们有StringArray, 已经提供了所有基本的String Array操作，不过对于不同的Array输入方式，删除方式等，对应的排序方式的效率也不大相同。因此我们可以把sort设置成为 virtual,然后对于不同的StringArray的使用方式，再相对选择正确的Derived Class就可以了。

对于Concrete Base Class 有几点需要注意的：

1. Destructor。 相信这个不用多说了，一定要 virtual, 而且要保证资源释放的干净。

2. 使用non-virtual interface. 这个是C++大师们的结论。 其原因是因为Derived class在重载Virtual的时候，在很多情况下会影响到基类里提供的机制的正常运作。如果使用non-public virtual，可以使得程序更加灵活，并且进程pre/post condition的检查。比如：

class StringArray {
public:
    void SortArray ( )
    {
       // Pre-condition Check
       StrategySoryArray();
       // Post-condition Check
    };  
private:
    virtual void StrategySoryArray( void ) { ... };
};

这样通过 pre/post condition check, 可以最大程度的保证基类的使用者不会犯错误。从而避免程序bug.

3. 尽量使用 private virtual. Protected virtual 只有在继承类需要调用基类实现的时候，才应该放在protected里。比较著名的是clone函数：

    class Base {
    protected:
       Base * clone ( void ) {};
    };

    class Derived : Base{
    protected:
       Base * clone ( void ) { Base::Clone(); ... };
    };

还有其他的一些方面，那就和基本的class设计大同小异了。 不过还有一个重要的方面，就是Operator 和 Copy Constructor.

============== Operator ==============

在Base Class里边，所有的 operator中最重要的就是operator =了。对于 Abstract Class 来说，最好是禁止使用 Operator =。 为什么呢？ 让我们来看看代码：

class Base {
public:
    virtual void Interface( void ) = 0;
    ...  
};

class Derived1 : public Base{
private:
    _x;
};

class Derived2 : public Base{
private:
    _x;
    _y;
};

Base *pD1 = new Derived1();
Base *pD2 = new Derived2();

*pD1 = *pD2;

也许 *pD1 = *pD2并不常见，但是确实是合法的代码，可以通过编译器的检查。但是*pD1 = *pD2 调用的是 Base 的 operator = , 在Base 并没有提供operator =的情况下，使用的是缺省的位拷贝操作。这个缺省的拷贝操作只拷贝Base Class的内存，而忽略了Derived Class的内存。也就是说 _x _y都没有被拷贝。

如果我们在 Base Class 里提供一个 virtual operator =, 在一定程度上能够解决问题，但是 overload 的operator 必须进行类型转换，例如:

Base & Derived1::Operator = (Base & x) {
    ....
    static_cast<Derived1 *>(x)
    ....
};

但是下面的代码仍然可以编译通过，产生错误的结果：

*pD1 = *pD2;

因此，对与 abstract class 来说，最方便的就是禁止 operator = , 把它设成 private.

对于Concrete Base Class来说，要么提供 operator = ,要么放在private 里，但是要在Derived Class里调用 Base Class 的 operator = 在例如：

class Base {
    ...
public:
    Base & operator = ( Base & );
};

class Derived : public Base{
    ...
public:
    Derived & operator = ( Derived & X )
    {
       Base::operator = ( X );
       ...
       // own assignment operations
    }
};

这种方法不支持cast up,也就是:
    Base * pBase1 = new Derived();
    Base * pBase2 = new Derived();
    *pBase1 = *pBase2;
   
稍微好点的方式是把 Base 的 operator = 放在 protected里边，但是也不是解决根本的问题。最好的解决方案是使用前面讲到的virtual clone 和 construct实现。如：

class Base {
    virtual Base * construct (void) { return new Base(); };
    virtual Base * clone(void) { return new Base(*this); };
};

class Derived : public Base {
    virtual Base * construct (void)
    { return new Derived(); };
   
    virtual Base * clone(void)
    { return new Derived(*this); };
};

同时禁止Base的 opeartor =。 但是这样的效率会有所降低。总之，最好的方法是使用 abstract interface,同时禁止base使用 private operator =.


好了。这次就说这么多，希望对大家有帮助，下次见！还有，虽然不是我们的节日，但是大家圣诞快乐！

]]> aear 程序设计随笔 http://blog.sina.com.cn/s/blog_4b3173c5010006jz.html#comment Sat, 16 Dec 2006 19:28:29 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010006jz.html http://blog.sina.com.cn/s/blog_4b3173c5010006iz.html 大家请把我的文章当参考，详细内容 还请参照 权威书
籍如果文中有错误和遗漏， 请指出，Aear会尽力更正,
谢谢！
Aear Blog: http://blog.sina.com.cn/u/1261532101
======================================================

关于virtual 一般有3种用法: virtual function, pure virtual function, 和 virtual inheritance. 今天就分别来讲讲这几种virtual.

================ virtual function ================
virtual函数是在类里边的一种特殊的函数，至于具体的含义，相信大家都知道，我就不多说了。而virtual最基本的思想，就是OO语言中多态的体现。把函数从编译时的棒定，转移到运行时的动态绑定。

virtual的好处很多，比如能使程序结构更加清晰，代码的重复利用率更高, 但是也是有代价的。让我们来看下代码：

class Test {
    ...
    virtual void VirtualFunc(void) { cout<<"Test1"<<endl; };
};

class Test2 : public Test {
    ...
    virtual void VirtualFunc(void) { cout<<"Test2"<<endl; };
};

Test * pTest = new Test2();
pTest->VirtualFunc();

上面代码的输出结果是"Test2"。也就是说，虽然你是通过Test * 进行的调用，但真正执行的代码是你创建的Test2的VirtualFunc. 这样的效果是通过在编译的时候创建virtual pointer: _vptr 和 virtual table: _vtbl 来实现的（大部分编译器的实现是通过_vptr & _vtbl）。对于每个有virtual function的class，compiler创建一个_vtbl，用来记录所有的virtual function的地址。同时在所有这个class的instance(实例)里，都有一个_vptr，指向_vtbl。因此， pTest->VirtualFunc() 这段代码等同于：

    (*pTest->_vptr[X])()

其中X是VirtualFunc在_vtbl中对应的位置。（其实对于不同的compiler，都有不同的实现，不同的类层次结构，_vptr和_vtbl的数目也不一定相同。）

从上面的代码考虑，virtual 和 non-virtual的class对比，在性能上有3个方面受到影响：
    1. _vptr是在constructor中由compiler生成的代码隐性的初始化，占用了一定的时间。
    2. virtual function是通过指针间接调用的，比直接调用需要更多的时间，而且在有的情况下会导致CPU的指令缓存失效，从而浪费更多的时间。
    3. 由于virtual function是在运行时进行动态绑定的，所以无法进行inline.

对于第一条，如果是使用 virtual function，那是无可避免的，对于第2条，有通过显式的调用virtual function来提高速度,代码如下：

class Test2 : public Test {
    ...
    virtual void VirtualFunc(void) { cout<<"Test2"<<endl; };
    void VirtualFuncFast(void) { Test2::VirtualFunc(); };
};

由于Test2::VirtualFunc指定了调用函数的版本，所以是在编译时候就绑定了，免去了指针的间接调用过程，而且VirtualFuncFast本身也是可以inline的。当然了，这样做也是有坏处的，就是VirtualFuncFast本身是Test2的函数，而不是Test的，所以不能通过Test的指针掉用。因此只有在确定是Test2的情况下，通过static_cast才能掉用VirtualFuncFast.

同理，在一个virtual function里调用另外一个virtual function的时候，使用显试的调用也能提高一定的速度，比如：

class Test2 : public Test {
    ...
    virtual void VirtualFunc(void) { cout<<"Test2"<<endl; };
    virtual void VirtualFunc2(void) { Test2::VirtualFunc(); };
};


对于第3种情况，我们可以通过用Template代替Virtual Function来获得性能上的提高，举个简单的例子：

========== virtual 实现 ==========
class Base{
public:
    virtual void VirtualFunc(void);
};

class Derive1 : public Base{
public:
    virtual void VirtualFunc(void);
};

class Derive2 : public Base{
public:
    virtual void VirtualFunc(void);
};

class SomeClass {
public:
    void test(Base * pBase) { pBase->VirtualFunc(); };
};

// 用法
Test * pTest1 = new Derive1();
Test * pTest2 = new Derive2();
SomeClass Temp1.test(pTest1);
SomeClass Temp2.test(pTest2);

========== 对应的 Template 实现 ==========

class D1{
public:
    // inline here
    void VirtualFunc(void) {};
};

class D2{
public:
    // inline here
    void VirtualFunc(void) {};
};

template <class DCLASS>
class SomeClass {
public:
    // inline here
    void test( void ) { Temp.TestVirtualFunc(); };
private:
    DCLASS Temp;
};

// 用法
SomeClass <D1> Temp1;
SomeClass <D2> Temp2;
Temp1.test();
Temp2.test();


========== 如何选择 ==========

对于到底是使用 Virtual ，还是使用Template或者Virtual的优化形式, 在大多数情况下不难做出决定。具体选择的过程，只需要问问自己到底是程序的速度重要，还是其他重要，也就是，要在： 速度，程序结构，灵活性，易用易维护性，代码的复杂度，代码大小 这些中间做出选择。

如果速度排第一位，那么就使用template或者优化，如果其他排在速度的前面，应该尽量的使用virtual。


================ pure virtual function ================

pure virtual function主要是用在abstract class里。有pure virtual function的class,就是abstract class,是不能被实例化的。因此，pure virtual function的代码只有在指定的情况下才能被调用。 例如：

class Test {
    virtual void VirtualFunc(void) = 0 { cout<<"Test"<<endl; };
};


class Test2 : public Test {
    virtual void VirtualFunc(void) { Test::VirtualFunc(); };
};

================ virtual inheritance ================

其实Virtual Inheritance只有可能在Multiple Inheritance中使用。对于Muliple Inheritance, Aear是坚决反对反对再反对的。Aear个人认为，single inheritance是足够用的，Java就是最好的例子。 MI实在是太让人头疼了，所以Aear不会在这个系列中讲MI，这里只说说 Virtual Inheritance和普通的Inheritance的区别。

class Base {
    virtual ~Base();
};

class Derived1 : public Base {
};

class Derived2 : virtual public Base {
};

这里:

sizeof(Derived1) == 4
sizeof(Derived2) == 8

sizeof(Derived1) == 4 是因为 Derived1继承 Base以后，使用Derived1的 _vptr

sizeof(Derived1) == 8 是因为由于在所有的vritual inheritance里，Base作为基类在内存中只能出现一次。所以必须把Base和Derived2的附加部分单独对待。因此有2个_vptr,一个是Base的，一个是Derived2的。

virtual inheritance的直接结果就是大大增加了指令缓存失效的可能性，同时降低了类内部数据的访问速度。因为Base 和 Derived2的内部数据不再是放在连续的内存中了。如果virtual inheritance的层次越多，对运行速度的影响就越大。

所以Aear在这里极度不推荐MI和Virtual Inheritance.

================ virtual 的一些用法 ================
下面是virtual的一些用法。

========== virtual destructor ==========

这个比较简单，就是所有的Base Class，都应该是 public virtual destructor 或者是protected non-virtual destructor，例如：

class Base {
public:
    virtual ~Base();
};

或者

class Base {
protected:
    ~Base();
};

========== virtual constructor ==========

其实本没有virtual constructor，不过C++中有特殊的实现，实现类似virtual constructor 和 virtual copy constructor的。代码如下：

class Base {
    virtual Base * construct (void) { return new Base(); };
    virtual Base * clone(void) { return new Base(*this); };
};

class Derived : public Base {
    virtual Base * construct (void) { return new Derived(); };
    virtual Base * clone(void) { return new Derived(*this); };
};

========== pure virtual destructor ==========

如果我们想设置base class 为abstract class,而又只有一个destructor作为唯一的成员函数，可以把它设成为pure virtual

class Base {
public:
    virtual ~Base() = 0;
};

========== protected & private virtual ==========

对于virtual function是不是应该放在public里边，学术结论和现实中的代码往往不能统一。虽然很多人认为virtual function 不应该放在public里边，但是这样的设计经常会造成编码中的不方便，

实际上对与Java来说，protected 或 private 所有 virtual function，几乎是不太可能的。因此，Aear个人观点，是不是要protected & private virtual function,要根据情况而定。下面是个private virtual的例子：

class Base {
public:
    // this is interface
    void print(void) { output() };
private:
    virtual void output (void) { cout<<"Base"<<endl; };  
};

实际上这样的处理，要比public virtual速度上慢点。

========== 一些要点 ==========

1. 不建议使用MI (Mission Impossible?), 在大多数情况下，它引入的问题，要比它解决的问题多的多的多。
2. 类层次结构越多，类成员和函数的访问效率越低。
3. Virtual Inheritance的类成员访问效率要低于 Non-virtual Inheritance.

今天说了好多东西，下次见！祝大家过的愉快。

]]> aear 程序设计随笔 http://blog.sina.com.cn/s/blog_4b3173c5010006iz.html#comment Fri, 15 Dec 2006 05:03:31 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010006iz.html http://blog.sina.com.cn/s/blog_4b3173c5010006ec.html 大家请把我的文章当参考，详细内容 还请参照 权威书
籍如果文中有错误和遗漏， 请指出，Aear会尽力更正,
谢谢！
Aear Blog: http://blog.sina.com.cn/u/1261532101
======================================================

今天讲的是inline. 其实大家都知道，inline并不是c++独有的特性。其实Aear的个人观点，inline根本就不应该是语言标准的一部分。因为inline的具体实现，跟compiler有很大的关系，把inline说成compiler的一个开关更合适一些。今天我们就说下在什么情况下可以使用inline, 使用inline的好处和坏处。

================= Inline能做什么 =================

关于inline能做什么，什么原理，相信很多人都知道。Aear再在这里重复一下：

1. inline能够去掉function call的overhead
2. inline能够帮助函数调用时候常量参数进行优化

举个例子来说明一：

void function(void)
{

}

function();

在调用function()前，一般会进行下面的操作（根据操作系统和compiler来决定，并不一定按照这个顺序）：
    保存IP FP SP等寄存器的值(压栈)
    把参数压栈
    建立新的 IP FP SP等以便进行函数调用
    函数有可能还需要保存一些寄存器数据到内存。

在完成function()调用后，也会进行一系列的操作：
    如果有返回值，一般在一个寄存器中，需要进行一系列的处理工作
    恢复IP FP SP等保存的寄存器值。

整个过程大约需要花费20-150个CPU clock cycle.具体要根据参数的多少，还有函数的具体实现来决定。使用inline function,可以去掉这些函数调用前和调用后的工作，从而节省CPU clock cycle,提高程序的运行效率。

关于2的情况，例子如下：
    float test = cos(0);

如果cos不是inline,compiler有可能会生成cos()的调用代码，计算cos(0)，然后返回给test.如果cos被inline了，由于cos(0) == 1，所以经过优化的代码可是直接生成test = 1.

================= Inline 坏处 =================

Aear个人认为，inline只在特定的情况下起到正面的作用，在大部分情况下，起到负面的作用，也就是说，坏处多过好处。使用inline的缺点包括：

1. 不容易debug，并不是所有的debugger都支持在inline function中设置断点，不过幸运的是，VS .net支持。

2. 很容易增加代码的长度，在很多情况下，代码长度的增加直接导致了代码执行速度的减慢，特别是在循环中，因为整个循环的长度超过了cache的容量，从而使得cache miss的几率增大

3. 使得编译的时间过长。如果一个inline function被更改，所有调用这个程序的代码都要重新编译。对于一般的游戏代码,整个编译时间可能会有1，2个小时。

4. 暴露了代码实现细节。由于inline function在大多数情况下必须在header file中定义（不过目前由于compiler越来越好，也可以在.cpp中定义inline了），所以导致使用者能够看到你的代码实现细节。

Inline并不是一个好东西，也不是一个万能药，在很多时候，它会给你带来无穷无尽的麻烦。所以在inline的时候，最好慎重慎重。

================= 如何使用 Inline =================

下面给出几种inline的用法。由于个人的代码结构，平台，实现细节的不同，请参考相关资料自行决定.

========= Platform Inline =========
首先要指出的是，inline并不是一条命令，而是对compiler的建议。compiler会具体分析你的代码，如果合适inline,才会进行inline的工作。在VS .net下，一共有3个关于inline的定义：

inline
__inline (__inline__ for GCC)
__forceinline

inline和__inline相同， 只有compiler认为inline合适，才会进行。__forceinline是强制compiler进行inline. 比如：

__forceinline void f(void);

如果你使用了inline或者__inline, 并且打开了编译器的 /Ob开关，那么compiler就会告诉你一个function是不是被真正的inline了。

========= Macro Inline =========

使用一个macro来控制inline，我们可以做如下定义：

#ifdef _DEBUG
#define COND_INLINE
#else
#define COND_INLINE inline
#endif

// inline function declaration
COND_INLINE function();

这样我们在debug模式下，就不会有inline带来的烦恼了。只有在release version，编译器才会进行真正的inline.


========= Inline Condition =========

一般来讲，根据程序员主观感觉inline得到的很有可能就是负面的效果。下面的一些情况，能够帮大家决定是否inline一个函数：

1. 使用profiler分析的结果告诉你需要inline一个function。 这个是最有把握的。windows下比较流行的profiler是vTune

2. class的属性访问函数（Accessor Methods）。一般来讲，这些是可以inline的，而且很多compiler都会帮你自动inline这些函数。

3. 小函数。这个需要举个例子说明，代码如下：

int Cal(int x, int y, int z)
{
    return x+y-z;
}

我们可以看到 Cal的代码很少，就是计算 x+y-Z，最多也就3，4条汇编代码。但是如果不inline, Cal函数的调用和返回过程所产生的代码，都比cal实际运行的代码多。因此Cal最好inline,通过消除Cal的调用和返回的代码，可以减少可执行程序的大小，同时加快运行的速度。

因此，一般来讲，5行内逻辑结构简单，没有if else的代码，可以比较放心的inline,大过5行的代码，就需要仔细的斟酌了。

================= 不能Inline的情况 =================

1. 包含Static Member的function. 很多compiler不能inline有static member的function.或者即使inline了，也会生成错误的代码（把static当成local处理）。所以最好先测试下compiler支持不支持static inline.测试代码可以这么写：

inline void f(void)
{
    static int k = 1;
    k++;
    std::cout<<k<<endl;
}

f();
f();

2. virtual member function.  Virtual Member Function在很多情况下是不能被inline的（根据compiler而定），因为具体virtual的哪个版本被调用，要在运行时候才能决定。不过我们可以通过创建一个新的可以inline的non-virtual member function，来提高运行速度。


================= 结论 =================

总的来说，inline的坏处多过好处，请大家inline的时候，慎重慎重再慎重，并不是所有的函数都适合inline的。







]]> aear 程序设计随笔 http://blog.sina.com.cn/s/blog_4b3173c5010006ec.html#comment Tue, 05 Dec 2006 02:35:37 GMT+8 http://blog.sina.com.cn/s/blog_4b3173c5010006ec.html