Irrlicht On IPhone

2010年06月04日

Irrlicht On IPhone

http://www.irrlicht3d.org/

主要参考来自于：http://www.ccloveaa.com/blog/article.asp?id=476
http://www.irrlicht3d.org/wiki/index.php?n=Main.IrrlichtEngineWiki

http://irrlicht.sourceforge.net/

1: Download irrlicht engine from: http://irrlicht.svn.sourceforge.net/viewvc/irrlicht/branches/ogl-es/

2: Create a new window base iphone app, add include and source folder into the project. add include in the include search path in xcode.
3: Add Foundation CoreGraphic OpenGLES QuartzCore UIKit framework in to the project.
3.1: delete all the error file from project when you build the project
4: Pass the UIWindow or UIView pointer to windowID, then Create a irrlicht device.
5: Use irrlicht engine render scene.

全文很简练，但是完全有效且使用，没有任何废话，按照步骤做就得了。
只是没有想到会这么容易，毕竟，Irrlicht是没有官方支持IPhone的，当然，上面得地址是官方的IPhone branch，从某种角度来说，比起官方支持的OGRE来说，要编译一个可用的irrlicht还是复杂了很多，并且，很多基础组件都没有，这点，所有尝试的人都需要注意。
假如你对Irrlicht很感兴趣，并且也对IPhone很感兴趣，那么就放心的尝试吧，比起你尝试装黑苹果的经历肯定要愉快的多。

首先，下载代码，解压，这些都不多说了，注意的是，需要自己新建工程，原工程太老太老，还是PPC的玩意儿，根本没有用，新建一个OpenGL ES的工程你会轻松很多，然后编译，肯定一堆错误，如上面所言，将所有报错的文件全部删了，另外，推荐通过irrcompile的config文件，关闭所有的d3d，并且完全删除libjpeg，我们不会用到，（事实上，主要是编译不过），然后去掉一堆irrlicht包含的第三方库的垃圾文件，比如readme,configure啦。。。。。。。

然后，链接，这个也不是太难，最主要的是，你需要注意，很多冲突的产生，原因都是因为很多第三方库（以bzip2最多）包含自己的Test程序，这些Test程序都包含有自己的main函数，这会与你自己的main函数冲突，全部删之，然后，恭喜你，你已经成功了！哈哈，没有想到这么简单是吗？

Irrlicht论坛中也有很多有用的资源：
最有用的thread
:Compiling irrlicht ogl-es branch for iphone (progress)
（事实上，按照thread中的说明一步一步来肯定能编过，并且成功，亲身实验）
IPhone上的触摸响应:http://www.rockfishnw.com/media/files/TouchEvents.zip

有用的Irrlicht在IPhone下的模版：http://www.mediafire.com/file/i1juyzy3mzz/iPhoneTemplateApp.zip

有图有真相，下面贴个上面templateApp运行时的截图：

原创文章作者保留版权转载请注明原作者并给出链接

2010年04月27日

【转帖】暴强游戏资源帖

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

Graphics Engines

Ogre 3D

Nebula Device

Jad
(formerly Haddd)
Irrlicht

Haaf's Game Engine
(hardware
accelerated 2D games engine)
Axiom
3D
(OGRE for .NET)
TrueVision

Revolution3D

Genesis3D

Crystal
Space 3D

Panda3D

Quake 3 Source Code

Quake 2 Source Code

Quake
2
(complete sources)
Tenebrae
(Quake with per
pixel lights and shaders)
Wild Magic
(David
Eberly's engine)
Apocalyx

ClanLib Game SDK

DevLib

kjAPI

Portable Game Library (PLIB)

RealmForge GDK

Delta3D

G3D

NeoEngine

QuakeForge

XEngine

Yake

Kyra Sprite Engine

Libraries

Free Game
Development Libraries
(external list)
Graphics:

Crazy Eddie's GUI system

Cal3D
(character animation
library)
GLFW
(OpenGL Framework)
GLee
(OpenGL easy extension
library)
DevIL

Game
Texture Loader

SDL

Cpw
(another OGL
framework)
Allegro

Open Scene Graph

Corona

Titan

SFont

CxImage

CImg

FreeImage

BMF_Font

BFont

FreeType
(font rendering library)
PaintLib

GLEW
(OpenGL extension
wrangler library)
gluX

GLUT

FreeGLUT

Open Inventor

FTGL
(OpenGL Font Library
nVidia Scene
Graph SDK

OpenSG

ParaGUI

LibUFO
(OpenGL
GUI Toolkit)
GPUmesh

GNU Triangulated Surface Library

libASE

lib3DS

GLOD
(Geometric
Level of Detail for OpenGL)
Video:

FFmpeg

Dirac

Theora

XviD

Networking:

RakNet

OpenTNL
(Torque network library)
HawkNL

OpenPlay

ReplicaNet

Game Networking Engine

Sound:

FMOD

OpenAL

Audiere

BASS

libsndfile

Ogg Vorbis

Physics and Collision:

Open Dynamics Engine (ODE)

Tokamak

Newton Game Dynamics

NovodeX SDK

Physical

True Axis

Open Dynamics Framework

ColDet
(Free 3D Collision
Detection Library)
Opcode

RAPID

FreeSOLID

V-Collide

Scripting and XML:

Python

IronPython

Lua

AngelScript

CInt

EOS

GameMonkey Script

Guile

IO

javascript

Squirrel

Small

Ruby

Tcl

Perl

LibXML

TinyXML

Expat

Apache XML libraries

ezXML

Compression and File Systems:

zlib

bzip2

LZMA SDK

LZO

PhysicsFS

#ZipLib
(native C# archive library)
SharpFS
(native C# VFS)
unrarlib

ZipArchive

Note: Much of the above lists (but not all) were taken from this page
,
maintained by Kylotan here
.

Applications and Utilities:

Development Environments:

Visual Studio 2005
Express

Code::Blocks IDE

Dev-C++

SharpDevelop

ActivePython

Graphics Development:

gDEBugger

FX
Composer

RenderMonkey

NVIDIA SDK

ATI Radeon SDK

DirectX Developer Center

NVIDIA Cg

Sh
(shader language)
Modeling:

SoftImage|XSI
Mod Tool

Milkshape 3D
(not
free, $25)
Wings 3D

Blender

Anim8or

DeleD

World Building:

Quake Army Knife (QuArK)

GtkRadiant

Getic3D

Audio:

ModPlug

Audacity

SynthEdit

Buzz Machines

KVR Audio
(not actually software,
but has tons of links)
Images:

Paint.NET (excellent free
image editor)

The GIMP

BMFont
(font
texture generator)

Media

Textures:

Transmogrifying
Textures Vol. I (NVIDIA)

Mayang's Free Textures

3D Cafe's Free Textures

Absolute Background Textures
Archive

Image * After

Media Link's
Free Backgrounds and Textures

Free Game Textures

Seamless
Textures -- Absolute Cross

3D
Millenium Free Textures

Pixel Poke

The Texture Studio

Textures

Marlin
Studios

Free Foto

Free
Textures

Free Textures

MorgueFile

Psionic3D

Models:

3D Millenium
Free Models

Polycount

Marlin
Studios

Free 3D Model
Collections

Free 3D Models

Digital
Animators Models

Psionic3D

Free 3D Models for 3D
Studio Max

Sprites

This
thread has lots...and lots...and lots...

Sounds:

SFX
and Music Resources
(another long GDNet post)
Jamendo
(Creative Commons
licensed music)
A1 Free Sound
Effects

Sound Effects

Tintagel's Free
Sound File Archive

Free Sound
Effects

Sound Hunter

Wav
Sound Complete Archive

deusX Sound Design

FindSounds
(sound search
engine)
Absolute Sound Effects Archive

That's all I've got for now. Still need plenty of resources in the art
and music department...free sounds, free textures, free models, free
music, and of course, many more utilities.

2010年04月23日

Boost::Signals2 学习

信号和插槽系统是我想用来在游戏引擎中让各模块解耦的关键部分，虽然自己以前也写过简单的实现，但是今天竟然找不到原来的代码了，而且我现在越来越懒了。。。。。于是乎，还是学习Boost中的signal2库吧。。。。。。。。。。汗颜中。在我发现公司一个比较成功的项目中竟然用了loki库后，使用外部库是越来越大胆了。。。。。更何况，这仅仅是我自己业余作品，按需配置使用使用boost并不过分吧。。。。呵呵，一点都不过分。

为什么我们需要信号和插槽？想想Qt几乎建立在这个基础之上，并且如此好用就能够理解了。降低耦合性，这应该是其核心目的吧。
信号和插槽可以让各对象只管处理自己的事情,比如按钮只管通知自己已经被按下而不是直接处理按下后应该做什么.
需要响应按键消息的对象应该只是注册自己需要在按钮按下后干什么,而不是每次去查询按钮是否被按下.毕竟轮询式的查询远不及通知来的有效。
UI用信号-槽设计的好处是巨大的，这让给对象的职责更加明确，减少了代码耦合，某一天，你想换套响应代码，OK，没有问题，直接换吧，UI层完全还是原来一样，不用关心外部的更改，反过来亦然，这在你将操作直接放在按钮按下的地方处理，肯定是没有办法做到了。

不过，个人感觉在游戏中比较特殊,因为各对象有固定的Update活动周期,各对象的处理应该都在自己的Update周期中处理,不然可能会破坏各自的Update顺序，导致问题.而且，在普通应用程序中存在的循环查询问题在游戏中也几乎可以忽略，因为游戏本身就是一个循环，无论什么时候，游戏都是每帧在render，每帧在Update,除非，你愿意给玩家看到一个往往全全的静态游戏。另外，特别需要注意的是，无论如何，这样的灵活性不是没有代价的，就像动态语言比静态语言往往要好用的代价一样，牺牲的是性能，信号和插槽在最好的情况下也多了一个间接层。

下面的例子（来自boost文档）是我个人认为最有价值，最能说明问题的，解决的也就是我提到的问题。

//[ passing_slots_defs_code_snippet
// a pretend GUI button
class Button
{
    typedef boost::signals2::signal<void (int x, int y)> OnClick;
public:
    typedef OnClick::slot_type OnClickSlotType;
    // forward slots through Button interface to its private signal
    boost::signals2::connection doOnClick(const OnClickSlotType & slot);

    // simulate user clicking on GUI button at coordinates 52, 38
    void simulateClick();
private:
    OnClick onClick;
};

boost::signals2::connection Button::doOnClick(const OnClickSlotType & slot)
{
return onClick.connect(slot);
}

void Button::simulateClick()
{
onClick(52, 38);
}

void printCoordinates(long x, long y)
{
std::cout << "(" << x << ", " << y << ")n";
}
//]

int main()
{
    //[ passing_slots_usage_code_snippet
    Button button;
    button.doOnClick(&printCoordinates;);
    button.simulateClick();
    //]
    return 0;
}

参考：
《boost 手册,signal2》，特别感谢金庆将其翻译成中文了，并且翻译的非常好。

原创文章作者保留版权转载请注明原作者并给出链接

2010年04月21日

boost::bind 学习

最近学习了太多与MacOS与Iphone相关的东西，因为不会有太多人有兴趣，学习的平台又是MacOS，不太喜欢MacOS下的输入法，所以写下来的东西少了很多。

等我学习的东西慢慢的与平台无关的时候，可能可以写下来的东西又会慢慢多起来吧。。。。。不过我想早一批订阅我博客的人应该已经不会再看了，因为已经很少会有程序语言或者C++之类的信息，相关的东西应该都是关于计算机图形，游戏的。或者，早一批订阅我博客的人现在也已经毕业，工作了呢？

对了，这次的主题是boost:bind。在历经了
boost::asio(1)

boost::asio(2)

boost::asio(3)

boost::foreach

boost::function

boost::lambda

boost::serialization(1)

boost::serialization(2)

boost::string_algo

boost::thread

之后，boost常用的很多都学会了，现在自己写点小东西，那是大胆的用大。。。。。。。呵呵，反正自己的东西，就当用来锻炼技术了。在学习boost::signal2的过程中发现自己其实对boost::bind这个将来要进C++标准的库了解还不够多，（在boost::functon中有所提及，也同时学了一点），所以抽了点时间，好好的学习了一下。

Purpose（目的）

原来文档中的purpose完全就是教程了，事实上，bind主要用于改造函数，比如，一个地方需要一个无参的函数，你只有一个以int为参数的函数，并且你知道此时int一直为1就可以了，你怎么办？传统方法，直接实现一个函数，然后以1调用以前的那个int为参数的函数。如下：

void
Fun1(int
i) {

printf("
%d
/n
"
, i);

}

void
FunWeNeed() {

Fun1(1
);

}

int
main()

{

FunWeNeed();

return
0
;

};

当然，这个例子太扯了，我们只需要直接用Fun1(1)调用就可以了，但是bind的目的就是如此，只不过现实中因为各种各样的原因，你的确需要改造函数。再比如下面的情况，你有一个原来写好的函数，接受一个以无参函数为参数，那么，你的Fun1就没有办法派上用场了，那么，传统上，怎么办？如下：

typedef
void
FunWeNeed_t(void
);

void
CallFun( FunWeNeed_t f) {

f();

}

void
Fun1(int
i) {

printf("
%d
/n
"
, i);

}

void
FunWeNeed() {

Fun1(1
);

}

int
main()

{

// CallFun(Fun1); // this line can't compile

CallFun(FunWeNeed);

return
0
;

};

Ok，你不得不写新的函数以满足需求，因为你没有简单的办法改变一个函数的参数。事实上，假如你是STL流派的话，那么随着你使用标准库的算法的次数的增加，你会遇到越来越多上面描述的情况，到底很简单，C++是如此的类型安全的语言，它不会加上诸如参数过多就忽略后面参数的胡扯特性。那么，一个算法需要你传进来的是什么形式的函数（或者函数对象），那么你就的怎么做。

去看看，标准库中提供了一大堆多么扯的函数对象吧，less, more,,greater_equal,not1,not2,。。。。。。然后还给了你一堆compose1，compose2........最后附带最恶心的bind1st，bind2nd，事实上，这些东西如此之多，以至于我甚至懒的列举出来，但是事实上我们在项目中用到了多少？简而言之，None!一次也没有，甚至因为很多算法与此相关，我们连那些算法也不用！

为啥C++当年出现了那么多奇怪臃肿无用的设计？可能是，C++标准出现的那个年代，编程技术的发展也就到那个地步吧。。。。。。。。。在C/C++语言中，关于函数的抽象特别的少，原因很简单，因为函数指针太不好用了！（函数抽象也用，但是好像用的最多的是在C语言中无物可用时，不得已的而为之）

记得在哪看过一句话，技术再花哨也没有用，最重要的是足够简单，因为不够简单的技术就很难给人讲解，别人很难理解那么就很难应用。这些C++特性应该算是其中的一例了。

boost中的bind，function
,lambda
就是为此而生的。注意，在tr1中，你就已经可以使用bind和function特性了，这也很可能是将来的C++标准之一。现在boost中的lambda还不够成熟，语法很怪，限制很多，因为，毕竟，boost再强大，仅仅是库啊。。。。。。。。。匿名函数的功能完全值得用语言特性来实现！

上面那个很扯的例子，总的给个bind的解决方案吧。

#include
<boost/bind.hpp>

#include
<boost/function.hpp>

void
CallFun( boost::function<void
(void
)> f) {

f();

}

void
Fun1(int
i) {

printf("
%d
/n
"
, i);

}

void
FunWeNeed() {

Fun1(1
);

}

int
main()

{

CallFun(boost::bind(Fun1, 1
)); // this line can't compile

CallFun(FunWeNeed);

return
0
;

};

需要注意的是，此时不能再使用函数指针了，bind的天生合作伙伴是function,而function是支持函数指针的（如上例所示）

。目的将的很多了，下面看看用法吧（不是什么问题）。

普通函数

最有意思的是，你甚至能用bind来扩充原有函数的参数，见下例：

#include
<iostream>

#include
<boost/bind.hpp>

#include
<boost/function.hpp>

using
namespace
std;
using
namespace
boost;

void
f(int
a, int
b)

{

cout <<"Argument 1 is "
<<a <<endl;

}

void
g(int
a, int
b, int
c)

{

cout <<"sum is "
<<a+b+c <<endl;

cout <<"arg 1: "
<<a <<endl;

cout <<"arg 2: "
<<b <<endl;

cout <<"arg 3: "
<<c <<endl;

cout <<"---------------------------"
<<endl;

}

int
main()

{

function<void
(int
,int
)> f1= bind(f, _2, _1); // 调整参数1，2的位置

f1(1
, 2
);

function<void
(int
)> sum1 = bind(g, _1, _1, _1); // 3个参数变1个

sum1(10
);

function<void
(int
, int
)> sum2 = bind(g, _2, _2, _2); // 3个参数变2个，仅用一个

sum2(10
, 20
);

function<void
(int
, int
, int
)> sum3 = bind(g, _3, _3, _3); // 3个参数还是3个，但是仅用1个

sum3(10
, 20
, 30
);

function<void
(int
, int
, int
, int
)> sum4 = bind(g, _4, _4, _4); // 3个参数变4个，但是仅用1个

sum4(10
, 20
, 30
, 40
);

return
0
;

};

输出结果：

Argument 1 is 2

sum is 30

arg 1: 10

arg 2: 10

arg 3: 10

---------------------------

sum is 60

arg 1: 20

arg 2: 20

arg 3: 20

---------------------------

sum is 90

arg 1: 30

arg 2: 30

arg 3: 30

---------------------------

sum is 120

arg 1: 40

arg 2: 40

arg 3: 40

---------------------------

函数对象

注意用法中很重要的一条：通常情况下，生成的函数对象的
operator()
的返回类型必须显式指定（没有
typeof
操作符，返回类型无法推导）。（来自Boost文档）

#include
<boost/bind.hpp>

#include
<boost/function.hpp>

using
namespace
std;
using
namespace
boost;

struct
F

{

int
operator
()(int
a, int
b) { return
a - b; }

bool
operator
()(long
a, long
b) { return
a == b; }

};

int
main()

{

F f;

int
x = 104
;

function< int
(int
) > fun1 = bind<int
>(f, _1, _1); // f(x, x), i.e. zero

cout <<fun1(1
);

function< bool
(long
) > fun2 = bind<bool
>(f, _1, _1); // f(x, x), i.e. zero

cout <<fun2(1
);

return
0
;

};

其他的也就很简单了。

成员指针

例子来源于boost文档。
#include
<iostream>

#include
<boost/bind.hpp>

#include
<boost/function.hpp>

#include
<boost/smart_ptr.hpp>

using
namespace
std;
using
namespace
boost;

struct
X

{

void
f(int
a) {

cout <<a <<endl;

}

};

int
main()

{

X x;

shared_ptr<X> p(new
X);

int
i = 1
;

bind(&X::f, ref(x), _1)(i); // x.f(i)

bind(&X::f, &x, _1)(i); //(&x)->f(i)

bind(&X::f, x, _1)(i); // (internal copy of x).f(i)

bind(&X::f, p, _1)(i); // (internal copy of p)->f(i)

return
0
;

}

可见bind的强大，支持自己拷贝需要的对象，支持引用，甚至，支持智能指针。

最后一个例子，结合标准库容器及算法的例子，这才是展示bind的强大的地方。

还是来自于boost文档。
class
image;
class
animation

{
public
:

void
advance(int
ms);

bool
inactive() const
;

void
render(image & target) const
;

};

std::vector<animation> anims;

template
<class
C, class
P> void
erase_if(C & c, P pred)

{

c.erase(std::remove_if(c.begin(), c.end(), pred), c.end());

}

void
update(int
ms)

{

std::for_each(anims.begin(), anims.end(), boost::bind(&animation::advance, _1, ms));

erase_if(anims, boost::mem_fn(&animation::inactive));

}

void
render(image & target)

{

std::for_each(anims.begin(), anims.end(), boost::bind(&animation::render, _1, boost::ref(target)));

}

例子展示了erase_if,for_each算法中使用bind的方法，当然，实际中，假如是你的游戏引擎中的update，render函数，碰到上述需求或者类似代码实现是很正常的，但是，你会放心的仅仅为了简化一些代码，然后将如此性能相关的位置，直接交给bind吗？

原创文章作者保留版权转载请注明原作者并给出链接

2010年04月19日

寻找最佳的数据存储方式

游戏中总是有很多相关的数据需要存储,比如编辑器产生的关卡数据,人物,物品属性的配置等等,并且现在已经不是每人都设计一种自己数据格式的时代了.程序员们是越来越懒,大家都想着一套文件格式,一套解析,处理代码能够通吃所有的程序.以下讨论,包括优缺点,都仅仅是对于游戏数据(还仅指编辑的数据)存储而言,以下都省略此前提背景,其他领域的使用本文仅供参考,游戏领域的使用本文也仅是一家之言,当然也仅供参考.
首先,看看传统的数据存储解决方案.

传统数据存储解决方案

EXCEL方案

最大的优点是几乎人人都会更改并且可以更改而不用进一步的学习.干这行的,别说策划,即使是文秘应该起码也会EXCEL吧?
缺点,需要自己写一大堆的Excel解析代码,这点是无奈的.
并且,假如不想每个Excel文件都写一套解析代码的话,你就要想好一种通用,并且扩展性良好的Excel编写格式,这也不是太容易的.
即使设计的Excel格式扩展性足够好,当数据慢慢复杂的时候,你会发现,事情越来越复杂.....几乎就开始将Excel做关联数据库使用了.有的时候,通过改动一些关联性很强的Excel数据来完成某个功能,甚至比你通过代码改变来实现还要复杂.....到那个时候,你才会发现,Excel已经不敷使用.
最最重要的是,Excel(起码03版的是这样)是二进制数据,SVN,mercurial等版本控制工具(偏偏这就是大家项目中所用的吧)不支持merge,这样,每次多人更改,必然导致冲突,然后,手工再去痛苦的重写吧.
但是,假如你碰到像我们公司说的这种,翻译组只懂使用Excel,那么你再痛苦,也就无奈去吧.这也是Excel的优点吧........当然,从程序的角度来看,那是最大的缺点.

数据库方案

数据库方案最大的优点是扩展性异常强大,数据库方案的扩展性几乎是无限的,无论多么庞大的数据量,放在数据库中总是不会显得很多,关联表格也总是能将冗余数据降到最低,并且,如此的清晰.由于现代数据库前端做的越来越好,修改数据库中的数据也不总是需要SQL语句了.最最重要的是,当你需要的时候,你还是能用SQL语句来实现你需要的最最复杂的查询,或者批量修改某些相关的数据.
当然了,没有方案是完美的,用数据库方案,的确强大,但是也有强大的代价,首先,项目中得有数据库专家,能够设计足够好的表格,及写出复杂的多重嵌套SELECT语句,项目中得有人懂得使用各自语言自己的数据库接口API,并且比较郁闷的是,各种数据库的API设计还不太一样......通用的API设计往往是以低效率为代价的....当然,这些都扯远了,扯上了原来做服务器的经验了........假如仅仅将数据库作为普通游戏数据存储的方式,缺点还没有那么夸张,并且,我们总是可以使用mySQL,SQLLite这样的开源解决方案.在各类语言中也总是有可用的相应的API可用.
除了上面那些,还有个问题,即使仅仅将数据库作为普通游戏数据存储的方式,为每个需求设计一套表,写一堆的从数据库中获取数据的代码,并且,最要要是以二进制数据发布的话,你还得写一套从数据库中读数据,然后序列化成二进制数据的代码,然后,额外的,解析二进制的代码也不可少.强大的数据库解决是以庞大的人工代码量堆积起来的.

现代数据存储解决方案

因为传统解决方案有着其天生的缺点,Excel对于越来越大的游戏,越来越多的游戏数据有些吃力,而是用数据库方案对于光是保存游戏数据(仅指编辑数据,不包括网游的运行时数据)又显得太过臃肿.那我们有没有更好的方法呢?先看看我们想要什么样的方案:
1.有着文本存储的方式,便于开发期调试和修改,也能直观的查看到改变和开发期的版本控制merge.
2.有二进制存储方式,在发布后可以使用这样的方式,减少parse时间,并且,从文本方式切换到二进制方式是有很简单解决方案的.
3.parse,序列化的代码编写要足够的简单,起码不会随着数据量的扩大而扩大到难以掌握的地步.
4.多语言支持,你总能在你喜欢的语言中使用
5.在数据之间建立关联,嵌套关系要足够的简单,这样才能简单的表示丰富的内容,而不是通过另外再建一套数据来表示关联(就像在Excel中需要做的那样)

有方案能满足上面所有的需求吗?可以寻找一下.
因为我能力有限,这里仅举较为常用的XML,JSON,Google Protobuf为例,作为比较,也作为自己选择最佳方式的参考.(在查找资料的过程过还发现了一个名叫Thrift的解决方案,有文章
的比较指出其比Google Protobuf要强大较多,因为使用较少,我不准备尝试,在此提供此信息,仅供参考)

XML方案

现在游戏数据中XML方案应用的应该算是非常广泛了,几乎算是事实上的工业标准?起码我的感受是这样,甚至于,Office 2007以后的通用格式都是XML化的了.是因为网页开发的太过流行,导致大家都喜欢上了尖括号横生的标记语言了吗?我不知道.但是,XML的确有其优点.在WIKI百科上,有这么一段描述:
As of 2009^[update]
, hundreds of XML-based languages have been developed,^[5]
including RSS
, Atom
, SOAP
, and XHTML
. XML-based formats have become the default for most office-productivity tools, including Microsoft Office
(Office Open XML
), OpenOffice.org
(OpenDocument
), and Apple
's iWork
.^[6]

看看吧,应用的还真不少.
首先,上述5点需求的需求1,3,4,5是较为完美的满足的.XML是写给人看的数据存储格式,虽然喜欢尖括号的人(比如我)会反感,并且因为其流行,解析XML的库也是非常丰富,各类语言对XML的支持肯定少不了,XML对于嵌套,关联的支持也是非常好的,其自描述性,能让你看到XML就能知道,它在描述什么.XML的处理都是字符串,支持unicode, wikipedia上还提供了一个有意思的例子:
version
="1.0"
encoding
="UTF-8"
?>

<烏語>

Китайська мова>

中国人写的?-_-!当然,实际中,除了字符串可能会用上中文外,一般的tag我们还是习惯用英文.
另外,有一点也很重要,XML是可扩展的,添加新的XML属性完全不影响原有的解析及代码的运行,直到你真的需要这个属性,然后再添加处理代码即可.
但是,XML有个致命的缺点,一堆类似HTML的标记,根本就不是设计给人来写的,(当然,好用的工具另外),在阅读的时候,很显然,废数据也过多,那么,存储,传输的时候,(假如传输的真是文本的话)同样的,信噪比太低,这点我不是太喜欢.当然,最主要的是直接写XML比较麻烦.也许有强大的工具能解决此问题,但是鉴于我们公司的制度,那可能是可望而不可及的事情.

JSON
方案

上述5点需求的需求1,3,4,5可以得到比XML更完美的满足.得益于简单的格式,所以解析及创建都可以做的很简单的,特别是JSONCPP这个库,在使用的时候简直就像获取到JS中的Object一样,直接通过[]操作完成索引及建立操作,使用起来感觉非常爽,并且,也有XML有的可扩展性,相对来说,比起以前使用LUA做配置而言,JSON会更加简单,当然,功能也稍微弱一些,不用逻辑处理(到脚本层次)的时候,我个人认为JSON就是最合适的数据存储格式.当然,从数据处理的速度来说,可能还需要一个从JSON到二进制的转换工具,(XML也有类似问题),然后在发布期完全使用二进制.
目前有点问题的就是,JSON的格式没有XML那么规范,所以常常会容易写错,然后自己还没有感觉,JSONCPP使用了MAP的特性,也就是说,使用方便,但是当[]查找不到的时候,是默认建立了空的索引,这会带来一些混乱.....
在我们的项目中,使用JSON来配置界面,为UI的灵活性提供了很大的方便,并因此节省了无数代码及编译时间,此时我想起一句LUA之父说的话,只有当配置足够灵活,人们才会使用它,的确如此,当JSON的使用如此方便的时候,使用配置,而不是代码,那是享受,而不是痛苦.

另外,XML与JSON方案还有个好处,因为他们的通用性,各个项目之间的沟通也会更加简单,与人解释XML,JSON在干什么,比与人解释自己的二进制文件在干什么要简单的多.也因为沟通更加简单,使得在通用格式上面的那一层代码也能得到更多的复用机会.甚至,我们考虑过使用其他项目中创造的用JSON实现的关键帧动画.........

Google Protobuf
方案

用的不多,试用了一下,谈下感想,Google在说明文档中说Google内部使用时,所有的进程间他通行,一律要求使用Google Protobuf,也可见其自有其强大之处.使用方式上与上述两个方案有比较大的不同,XML与JSON仅仅是描述数据,单纯的数据,解析的代码还是需要自己去写(尽管JSON的解析已经非常简单了)但是Google Protobuf不同,其要我们编写的是结构描述文档,并且通过其附带的工具,直接生成C++,JAVA,Python的代码(也就是Google内部使用的3语言,与我们公司完全一致),至此,不仅解析简单了,甚至结构都有了,我们需要做的是直接调用结构的接口去完成输入输出,所有的数据的getter都通过Google规定的方式进行了命名.甚至,直接将结构打包成2进制数据然后发送了.(也就是Google在文档中所描述的进程间通信).比起XML,JSon而言,此方案最大的优势在于速度,它有很好的文本格式以及二进制格式,可以很方便的切换(原生就支持),这也是3个方案中唯一满足了需求2的方案.(事实上,完全满足上述所有需求)但是,很明显的,有个缺点,(实在是没有实际使用,仅仅是通过试用感觉的),假如结构变换的话,可能得重新使用Google提供的工具,重新生成结构,这就需要重新编译代码,这是个较大的问题.................其他的,个人感觉,Google Protobuf是非常不错的解决方案,特别是用在需要进程间通信时(比如需要进行网络通信,连打包的代码都省了).

最后的总结是,未来的趋势应该是JSON
方案吧,Google Protobuf
方案更适合需要网络通信的情况,毕竟还需要通过工具生成代码,使用的方便性来说不如JSON.

原创文章作者保留版权转载请注明原作者并给出链接

2010年03月27日

不远的将来程序语言是怎样的

其实很久就看到Bruce Eckel的文章了《Programming in the Mid-Future》，原文发表于2010-3-10日.作为一个经常被自己无聊的求知欲所控制的程序员,我利用工作或者业余时间学习了N多种语言,也常常在想,到底怎么样的语言才是我们需要的,真的想要的,是能让(绝)大部分程序员所能接受的,公认的好语言,而不是一提到某某语言,就必定引发一场无休止的口水战呢?
Bruce Eckel提出了一些他的看法,虽然他不仅讲述了关于程序语言的内容,而是涵盖了程序设计的各个方面,但是,很显然,程序设计再多方面,主要的内容还是在程序设计语言上面. 在这里,大牛面前,我发表太多言论就类似班门弄斧了,这里先摘录一下原文的小标题及核心内容.
在Bruce Eckel心中,不远的将来程序语言是这样的:

1.极端动态(Extremely dynamic)

有越来越多的问题是静态语言解决不了的,所以,程序语言将向越来越动态的方向发展.

2.极其简单的并行(Stupidly parallel objects)

对象将管理他们自己的进程,就算不知道啥叫并行编程,也能无误的使用.

3.无盘持久化环境(Persistent diskless environment)

你将创建对象并随时使用它们,而不用关心它们在哪里,对象将在必要的时候包含必要的数据.

4.本地开发和云部署开发一致(Transparency between local and cloud)

程序员将不用考虑这些问题,它们将自动化.

5.自动覆盖测试(Swarm testing)

将来的测试要更快,更周密,更自动化,为测试所写的代码也要少的多.

6.代码安全测试(Security via suspicious systems)

将来的测试不仅包含现在普通意义上的测试,逻辑测试,安全测试也将存在.

7.以查询为基础的数据模型(Query-based data)

将来查询数据库就像使用Google一样简单............

8.更大尺度上的复用(Reusability on a vast scale)

未来的对象交互会以'组件'为基础,组件间的接口将是通用的,向一个系统中添加一个新的组件将非常容易.

9.简单的系统集成(Effortless System Integration)

你可以自由选择单独使用一个程序/组件,或使用由这些程序构成的更大的系统.

10.可复用的用户界面元素(Reusable UIs)

用户界面的元素将分类存储,并且获取和显示数据,大部分时间,我们选择并粘贴它们到系统中就能添加某个功能.

11.简单的效率伸缩性(Effortlessly Scalable)

一个程序在无论在多大规模下使用都不需要进行更改.

12.内建的可进化性(Built-in Evolvability)

无论向多大规模的程序中添加新特性,都是一样的简单.

原创文章作者保留版权转载请注明原作者并给出链接

2010年03月10日

在Google Doc不可用的时候，见识了Google的18国语言道歉, 力压苹果5国

write by
九天雁翎(JTianLing) -- www.jtianling.com

在Google
Doc不可用的时候，见识了Google的18国语言道歉。。。联想到苹果的4国，5国。。。还是Gooogle 的用户群更广？

以下为具体内
容：

Google：

Google Docs is temporarily unavailable -- please try
back later. If you get this page again, please check our Help Center

for outage
notices. We apologize for any inconvenience.

Google
ドキュメントーは一時的にご利用いただけません。しばらくしてから、もう一度試してみてください。また、ヘルプセンター

。
ご不便をおかけしますが何卒ご了承ください。

Google Documents est momentanément indisponible.
Veuillez réessayer ultérieurement. En attendant, vous trouverez des
informations utiles dans notre Centre d'aide

. Nous
vous prions de nous excuser des désagréments occasionnés.

Google Text & Tabellen ist
vorübergehend nicht verfügbar. Versuchen Sie es später erneut. In der
Zwischenzeit erhalten Sie nützliche Informationen in der Google Hilfe-Seiten

.
Wir entschuldigen uns für eventuelle Unannehmlichkeiten.

Google Docs no estará disponible
temporalmente. Por favor, intenta acceder más tarde. Mientras tanto,
puedes consultar el Centro
de Asistencia

. Disculpa las molestias.

Google Documenten is tijdelijk niet
beschikbaar. Probeer het later nogmaals. In de tussentijd kun je nuttige
informatie vinden in ons Helpcentrum

. Onze
excuses voor het ongemak.

Google Documenti non è temporaneamente disponibile.
Riprova più tardi. Nel frattempo prova a consultare il nostro Centro assistenza

. Ci
scusiamo per gli eventuali disagi causati.

O Google Docs não está disponível no
momento. Tente novamente mais tarde. Enquanto isso, você pode encontrar
informações úteis na nossa Central de Ajuda

.
Pedimos desculpas por qualquer inconveniente.

Google 文件是暂时无法使用。請稍後再試。在此期間，您可以在我們的說明中心

中找到有用的資訊。
對於造成您的任何不便，我們謹此致歉。

Google 文档暂时不可用。请稍后再试。在此期间，您可以在我们的支持中心

查找有用的信息。对于由此带来的任何不便，我们深表歉意。

Dokumenty Google jest tymczasowo niedostępny. Spróbuj
ponownie później. Tymczasem możesz znaleźć przydatne informacje w naszym
Centrum pomocy

.
Przepraszamy za wszelkie niedogodności.

Google Dokument är inte tillgängligt
för tillfället. Försök igen senare. Under tiden kan du hitta användbar
information i vårt hjälpcenter

.
Vi ber om ursäkt för eventuellt besvär.

Google Dokumenter er midlertidigt ikke
tilgængelig. Prøv igen senere. I mellemtiden kan du muligvis finde
brugbare oplysninger i vores Hjælp

. Vi beklager
ulejligheden.

Google
문서도구 잠시 사용할 수 없습니다. 나중에 다시 열어보십시오. 궁금한 점이 있으면 우선 Google 도움말 센터

에서 찾아보십시오. 불편을
끼쳐드려 죄송합니다.

Документы
Google временно недоступен. Повторите попытку позже. А пока полезную
информацию можно найти в нашем справочном центре

.
Приносим извинения за причиненные неудобства.

Google Dokumenter er midlertidig
utilgjengelig. Prøv igjen senere. I mellomtiden kan du finne nyttig
informasjon i Brukerstøtten

.
Vi beklager eventuelle ulemper dette medfører.

Google-dokumentit on väliaikaisesti
poissa käytöstä. Yritä myöhemmin uudelleen. Voit löytää hyödyllisiä
tietoja ohjekeskuksestamme

.
Pahoittelemme tilanteesta mahdollisesti aiheutuvaa haittaa.

Google Dokümanlar geçici olarak
kullanım dışıdır. Lütfen daha sonra tekrar deneyin. Bu arada, Yardım Merkezimizde

. Bu
durum için özür dileriz.

苹果：

原创文章作者保留版权转载请注明原作者并给出链接

2010年03月10日

各种进程创建方式比较总结(MacOS, Win32, Qt)

由于进程创建是非常基础，很重要的工作，由此导致的恶果就是每个系统自己都喜欢封装一套，以显示自己对其有原生的，较好的支持，但是，说实话，有的时候，
那方式，实在是相当别扭，这里，我讲我了解的平台/系统下的进程创建方式统一的梳理总结一下，也顺便可以比较一下各个系统的API封装情况，窥一斑而见全
豹嘛。这里很容易加入主观因素，也没有太多客观事实可以作为唯一的评定标准，那么，完成同样的工作，代码量少点总不是太坏的事情，仅以代码量为参考之一
吧，参考之二就是大家自己的感觉了。毕竟其中一些地方无法做到公平,因为所有代码并不是以精简代码为首要目的,首要目的是适应对应接口的风格.

方
式说明

    1, 最简单的创建一个带参数的进程,以显示当前目录下的文件a,文件b的内容为例。

2，展示进程的输出重定向使用，以将当前目录下的文件a,文件b定向到文件c中为例。

3，展示进程间的管道通信技术，以将当前目录下的文件a,文件b通过管道传递给另外一个输出的进程，并且显示。

（以下简称Test1，2，3）。

1.Shell/DOS

1.从最简单的开始吧，Shell/DOS，这种简单的情
况，Windows的DOS与Unix/Linux的Bash
Shell下都差不多，以Bash为例了。（其实Windows下仅仅将cat换成type命令即可。。。。其实还是有些细微差别的，参看《从Unix的
echo与Dos的type之间的区别，看操作系统之间的软件设计哲学的不同》一文）以下因为type,dos命令的限制导致Windows下某些时候
Test3无法完成，忽略之）

jtianling$ echo "I'm File A." > a
jtianling$
echo "I'm File B." > b
jtianling$ ls
a b
jtianling$ cat a
I'm
File A.
jtianling$ cat b
I'm File B.
jtianling$ cat a b
I'm
File A.
I'm File B.
jtianling$
好了，cat a
b，这样简单的调用，进程创建完成，参数输入完成，显示正常。

2.输出重定向，对于Shell来说实在是小
case，那简直可以说是其原生的。

TianLings-MacBook:test jtianling$ cat a b > c
jtianling$
cat c
I'm File A.
I'm File B.
jtianling$
cat a b >
c一句而已。

3.管道，还是Shell饭碗里面的内容。

jtianling$ cat a b |
cat
I'm File A.
I'm File B.
cat a b | cat还是一句代码而已。

自
此，Shell完成了全部任务，可以看到Shell这玩意儿不愧是为管理，调用进程而生的家伙，完成类似任务，那是信手拈来，毫不费劲，即便是最复杂的
Test3，也没有超过一行，字符数（以下都不计空格）甚至没有达到两位数。当然，到了这里，离谱的简单，有人可能会说这种比较根本不应该加入
Shell,甚至会觉得Shell参与此分类比较简直就是作弊。。。。。bash/bat也算是一种编程语言，而且为了进程调用的方便，牺牲了那么多，为
啥不算呢？^^

2.C Runtime Library

这里运行环境是MacOS，Windows下还是得用
type....利用了C Runtime Library的system函数。

Test1:
#include
<stdlib.h>

int
main()
{
system("cat a b"
);

return

0

;
}

结果：
Running…
I'm File A.
I'm File
B.

Debugger stopped.
Program exited with status value:0.

OK，
依
次类推，接下来的也就就是按照Shell的调用方式换system的参数而已了，不重复描述了，简单计算，起码都是5行内解决问题。（自然分行，没有特别
去缩减，也没有特别去增加，空行不算）有人又会说，这样使用完全是依靠了SHELL的强大，system函数不过是个简单的Shell调用而已。。。。根
本不算数，C语言本身压根就不带进程创建功能-_-!但是。。。。任务完成了吧。。。Shell本身都算，依赖于Shell完成任务，只要任务能够很好的
完成，为啥不算呢？

3.Python中的System

Python的OS模块中也有System这个C
Runtime
Library的函数，于是，第2种方法的好处其可以占尽，并且，因为Python作为脚本语言，少了很多负担，所以其实从完成任务的角度来说，要比C语
言更加简单一些。当然，我不知道这不属于Python社区接受的方式，也即，不知道这算不算Pythonic。
>>>
import os
>>> os.system("cat a b")
I'm File A.
I'm
File B.
0
当然，能够如此简单，还是少不了Shell的功劳。

4.Win32 API
WinExec/ShellExcute

这两个接口都好像不怎么推荐使用了,但是使用的简单性上还算是一个量级的.放在一起了.
Test1:

#include
<windows.h>

int
_tmain(int
argc, _TCHAR* argv[])
{
WinExec("cmd /c type a b"
, SW_SHOW);

getchar();
return

0

;
}

Test2与Test1类似,不累述了,Test3因为type不支持管道输入,所以无法完成.

5.Win32
API CreateProcess

CreateProcess其实是平时我在Windows下创建新进程使用最多的函数,因为可以获得新进
程的句柄,可以进行很多额外的操作,比如让新进程先停止,甚至可以hack新进程,通过API直接对新进程的内存进行write操作.....呵呵,当时
研究反外挂时的一些操作,平时用的其实也少.当时Wait相关API,只有获得CreateProcess返回的进程Handle才能进行.其实对与此
API我以前特别有一文讲述了一些经验(其实是做一个笔记,防止忘记)<
Windows下
的进程创建API--CreateProcess使用经验漫谈

>

#include
<windows.h>

#include

<stdio.h>

#include
<tchar.h>

int
_tmain( VOID ) {
    STARTUPINFO si;
    PROCESS_INFORMATION pi;
    LPTSTR szCmdline=_tcsdup(TEXT("cmd /c type a b"
));

ZeroMemory(
&si, sizeof

(si) );
si.cb
= sizeof

(si);

ZeroMemory( &pi, sizeof

(pi)
);

    // Start the child process.

    if

( !CreateProcess( NULL
, szCmdline, NULL
,
NULL
, FALSE, 0

,
NULL
, NULL
,
&si, &pi )) {
       printf( "CreateProcess
failed (
%d

).
/n

"
, GetLastError() );
       return

0

;
    }
    // Wait until child process exits.

    WaitForSingleObject( pi.hProcess, INFINITE );

//
Close process and thread handles.

CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );

return

0

;
}

纯C语言的接口,第一次看到此接口的时候简直懵了,后来用ShellExecute替代了,用到再后
来,CreateProcess用多了,每次copy示例代码,竟然也慢慢觉得看的顺眼了,习惯的力量是强大的..........

6.MacOS
Cocoa

下面看重头戏…………
Test1:

#import
<Foundation/Foundation.h>

int
main (int
argc,
const
char
*
argv[]) {
        NSAutoreleasePool * pool = [[NSAutoreleasePool
alloc] init];

        NSTask *task = [[NSTask alloc]
init];
        [task setLaunchPath:@"/bin/cat"
];

        NSMutableArray *args = [NSMutableArray array];
        [args addObject:@"a"
];

        [args addObject:@"b"
];
        // can be replace by －－ NSArray *args = [NSArray
arrayWithObjects:@"a", @"b", nil];

        [task
setArguments:args];
        [task launch];
        [task
waitUntilExit];

        [task release];

[pool drain];
return
0
;
}

一共15行，Cocoa中对进程进行了封装，
用NSTask来表示，并且将参数分割成一个一个字符串对象，组合起来成为一个Array后才能设定为参数，再然后，通过launch启动进程，通过
waitUntilExit等待进程推出，再释放自己分配的NSTask对象，对了，Objective
C程序中，为了适应没有垃圾收集的情况，还得好好的设定自动释放内存池。

Test2:
想投机取巧一下吧，利用Shell，如下：

        NSMutableArray *args = [NSMutableArray
array];
       [args addObject:@"a"
];
        [args addObject:@"b"
];

[args addObject:@">"
];

[args addObject:@"c"
];

你
会得到如下错误信息：
I'm File A.
I'm File B.
cat: >: No such file or
directory
cat: c: No such file or directory

Debugger stopped.
Program
exited with status value:0.
这是行不通的。。。。Apple给了你封装，你就得用，抵抗只有死路一条。。。。。
正
确用法：(不知道还有没有更简单的，这个方法还是自己想到的。。。。试了试还真可以用。。。。）

#import
<Foundation/Foundation.h>

int
main (int
argc,
const
char
*
argv[]) {
       NSAutoreleasePool * pool = [[NSAutoreleasePool
alloc] init];

        NSTask *task = [[NSTask alloc]
init];
        [task setLaunchPath:@"/bin/cat"
];

        NSMutableArray *args = [NSMutableArray array];
       [args addObject:@"a"
];

[args addObject:@"b"
];

[task setArguments:args];

        NSFileManager *fm =
[NSFileManager defaultManager];
        if
([fm
createFileAtPath:@"c"
contents:nil
attributes:nil
]
== FALSE) {
                NSLog(@"Can't
Create the file named c."
);
                return
1
;

        }

        NSFileHandle* fh = [NSFileHandle
fileHandleForWritingAtPath:@"c"
];

        [task setStandardOutput:fh];

        [task
launch];
        [task waitUntilExit];
        [task release];

        [fh closeFile];

        [pool
drain];
        return
0
;
}

于是乎，你可以知道了，apple是崇尚学习
的。。。。。因此，你又学会了好几个类，明白了好几个概念，
NSFileManager不
能直接创建文件然后返回
NSFileHandle进行操作的设定难道是为了更好的实行类的
分工？

Test3:
经历过Test1,Test2的洗礼后，应该会明白了，为啥苹果的笔记本起码都要7千多，苹果的一个外接完整
键盘都要500多,一根破转接线都要200（见《看到苹果
的把视频转接线当金条卖，我彻底怒了。。。。。。。
》生产效率太低估计是原因之一(可是苹果很多东西不都是中国组装的吗?)。。。。-_-!为
啥与苹果粉丝的宣传的好像不大一样啊。。。。。原因我也不知道，用苹果最大的感受是Mac
Book的Fx键都被笔记本的特性完全占用，苹果自己默认设定的一些快捷键都会形成冲突，XCode的调试常用键你都得用3个以上的键组合才能按
出。。。。人性化的设计极大的培养了用户手指的灵活度。（别说可以改，VS,Eclipse,Qt
Creator的调试常用快捷键为啥都只用Fx键一键调用是有原因的，这个道理Ollydbg都懂，为啥苹果这么注重用户体验及GUI设计的人为啥不懂我
是不太明白。。。。。。。难道苹果的GUI设计光是指使用鼠标或者触摸屏？唉。。。。也许我还没有适应苹果的文化吧。。。。。。当大家都被苹果的文化熏陶
后，也许苹果的东西就是好吧。。。。。。（估计说这些话会被很多人骂，所以不开新文章特别说明了，省的骂声一片，仅插播在这个枯燥的技术文章当中吧。某年
某月某日我改变主意了，再回来改掉这些文字吧。）
对了，主题是，Cocoa中的管道：

#import
<Foundation/Foundation.h>

int
main (int
argc,
const
char
*
argv[]) {
       NSAutoreleasePool * pool = [[NSAutoreleasePool
alloc] init];

        NSTask *task = [[NSTask alloc]
init];
        [task setLaunchPath:@"/bin/cat"
];

        NSMutableArray *args = [NSMutableArray array];
       [args addObject:@"a"
];

[args addObject:@"b"
];

[task setArguments:args];

NSPipe *pipe = [NSPipe
pipe];
[task setStandardOutput: pipe];

NSTask *newTask = [[NSTask alloc] init];
[newTask
setLaunchPath:@"/bin/cat"
];

[newTask setStandardInput: pipe];

        [task launch];
        [newTask launch];
        [task waitUntilExit];

[newTask waitUntilExit];
[task release];

        [newTask release];

        [pool drain];

return
0
;
}
Pipe的封装还算简单，使用也还算方便吧，但是因为Task的使用，代码量实在也够多了。

7.Qt
QProcess

作为几乎对C++进行语言级别改变的框架Qt，进行了与Cocoa类似的封装，对了，其实感觉Qt对C++从语言特性的改变
上来说类似于Cocoa对于Objective C的改变，不同的是Qt没能统治C++世界。
Test1:

#include
<QtCore/QCoreApplication>

#include
<QtCore/QProcess>

#include
<QtCore/QStringList>

int
main(int
argc, char
*argv[])
{
QString program = "cat"
;
QStringList arguments;

arguments <<"a"
<<"b"
;

QProcess *myProcess = new

QProcess();
myProcess->start(program, arguments);

    myProcess->waitForFinished();
    QByteArray output =
myProcess->readAllStandardOutput();
    printf("
%s

"
, (const

char
*)output);

return

0

;
}

QProcess就是Qt封装的进程类，需要特别说明的此类使用上在Qt4与Qt3是不同的。并且，有个问题是因为
Qt现在几乎已经是纯面向GUI的界面库了，所以QProcess默认是进行命令行不输出的，这里转了个弯，先读出了输出，然后用printf输出了。

Test2:

#include
<QtCore/QCoreApplication>

#include
<QtCore/QProcess>

#include
<QtCore/QStringList>

int
main(int
argc, char
*argv[])
{
QString program = "cat"
;
QStringList arguments;

arguments <<"a"
<<"b"
;

    QProcess *myProcess = new

QProcess();
    myProcess->setStandardOutputFile("c"
);
    myProcess->start(program, arguments);

myProcess->waitForFinished();

return

0

;
}
但是看了示例，什么感觉？个人感觉Qt不愧是专门做API的，靠API吃饭的与靠卖硬件为生的公司就是不一样，API的设计实
在是恰到好处，简介简练，并且，最重要的是，够用！

Test3:

#include
<QtCore/QCoreApplication>

#include
<QtCore/QProcess>

#include
<QtCore/QStringList>

int
main(int
argc, char
*argv[])
{
QString program = "/bin/cat"
;
QStringList arguments;

arguments <<"a"
<<"b"
;

    QProcess *myProcess = new

QProcess();
    QProcess *outProcess = new

QProcess();
    myProcess->setStandardOutputProcess(outProcess);

myProcess->start(program, arguments);

outProcess->start(program);

myProcess->waitForFinished();

outProcess->waitForFinished();

    QByteArray output =
outProcess->readAllStandardOutput();
    printf("
%s

"
, (const

char
*)output);
    return

0

;
}

总体上而言，Qt没有设计pipe对应的类，但是，对于一个函数可以解决的任务来说，很明显使用起来是更加简单的，像
Cocoa那样，对这么简单的概念都进行相应的封装，其实有过度设计之嫌。。。。其实NSPipe也就2，3个函数，而且，如此例所示，其实，除了一个有
用外，NSPipe多出的那么几个都是因为多了NSPipe才出现的函数。。。。。悲哀中。。。。

总表

使用方式/代码量	Test1	Test2	Test3
SHELL	单行5字符	单行7字符	单行9字符
C Runtime Library's system	5行	5行	5行
Python's os.system	2行	2行	2行
Win32 API WinExec/ShellExecute	6行	6行	type 限制
Win32 API CreateProcess	16行	16 行	type限制
Objective C With Cocoa	15 行	23行	23行
Qt QProcess	16 行	15行	20行

别的不
说了，起码有一点可以肯定。。。。。有的时候面向/基于对象的设计，不仅实现起来不能省代码量，就连使用起来都需要更多的代码。。。。。
而且封装
这技术，使用一定要适度，太细太过并没有太大好处。有的时候一个简单的C语言函数，已经可以做的事情，为啥我们要用3，4各类来完成?

原创文章作者保留版
权转载请注明原作者并给出链接

2010年03月10日

从Unix的echo与Dos的type之间的区别，看操作系统之间的软件设计哲学的不同

本文其实仅仅是写
《各种进程创建方式比较总结(MacOS, Win32, Linux, Qt,
Python…………)》一文时的过度发挥，发现插入大段无关文字有点问题，就给剥离出来了，也算一次文章的重构。。。。。
从Unix的echo
命令与Dos的type命令，从基本使用上来说，都是用于显示文件内容的，但是大致的使用一致，却有一些细微的差别，这些细微的差别，让我挺有感触，于是
借题发挥了，也算无聊一把。但是，毫不夸张的说，两个小命令，展示了两个不同的世界。

比较手段

    1,
最简单的创建一个带参数的进程,以显示当前目录下的文件a,文件b的内容为例。

2，展示进程的输出重定向使用，以将当前目录下的文件a,文件b定向到文件c中为例。

3，展示进程间的管道通信技术，以将当前目录下的文件a,文件b通过管道传递给另外一个输出的进程，并且显示。

（以下简称Test1，2，3）。
以上述三个操作，显示echo及type的不同。

Test1:

1.
从最简单的开始吧，先以Unix下的Bash为例了。

jtianling$ echo "I'm File A."
> a
jtianling$ echo "I'm File B." > b
jtianling$ ls
a
b
jtianling$ cat a
I'm File A.
jtianling$ cat b
I'm File B.
jtianling$
cat a b
I'm File A.
I'm File B.
jtianling$
好了，cat a
b，这样简单的调用，进程创建完成，参数输入完成，显示正常。

Test2:

2.输出重定向，对于
Shell来说实在是小case，那简直可以说是其原生的。

TianLings-MacBook:test jtianling$ cat
a b > c
jtianling$ cat c
I'm File A.
I'm File B.
jtianling$

cat a b > c一句而已。

Test3:

3.管道，还是Shell饭碗里
面的内容。

jtianling$ cat a b | cat
I'm File A.
I'm File B.
cat
a b | cat还是一句代码而已。

DOS中type的对比：

Test1:

DOS
下，type命令也可以完全按照上述方式尝试一次:

Test1,基本可用，也就是输出嘛，但其实,仔细看看DOS下的
type命令,会发现其实输出有些许不同:

F:/MySrc/TestProcess>type a b

I'm
File A.

I'm File B.

直观来看,type a
b时自动的将a,b文件按文件名给你排下版,多人性化啊?呵呵,但是,很明显的可以看出DOS开发者的文化(MS特有?)与UNIX社群的文化差
异.UNIX中提倡命令行程序不要输出废话(比如上面的a,b及排版),这样才能够通过管道或者重定向更多的重复被其他程序使用,DOS似乎提倡给人直接
看.......

Test2:

实践发现，虽然直接的输出会有额外输出，但是type命令的对于重
定向时进行了处理:

F:/MySrc/TestProcess>type a b > c

F:/MySrc/TestProcess>type
c
I'm File A.
I'm File B.

会发现重定向后的结果与cat a b >
c完全一样.但是a,b的格式还是输出了，说明a,b格式的输出根本走的不是标准输出通道。那剩下什么？标准错误通道。。。我们测试一下。

>type
a b 2>d
I'm File A
I'm File B

>type d

果
然如此，当把错误通道重定位到文件d中时，可以看到输出了精简的输出，并且可以看到d中的内容就是附加的输出。用较为复杂的hack手段，（利用错误输出
来输出正常的信息，总之不是什么好手段）实现其实不算太必要的但是有点用的任务，是好是坏，就看个人意见了。

Test3:

会
发现,type其实是无法接受标准输入的,也就是,无法形成 | type的链式调用,就像cat a b | cat一样.

这样会导致
Test3无法使用type完成。这也算文化差异吧......因为Unix的Shell使用的习惯，管道及重定位几乎是命令行必备的协作工
具，DOS/Windows程序没有此传统，所以没有实现，也就可以理解了。更进一步的说，Win32
API甚至没有对管道及输入输出重定向有任何直接的支持，因为似乎根本就不在意，而POSIX的pipe,popen对于相关使用的支持却能做到非常方便
快捷。（当然，其实Windows中也有POSIX的函数的一些实现，就包括pipe,popen，但是命名前加下滑线）

小
结：

所以,对于type命名来说,描述为:TYPE Displays the contents of a text file.

对
于cat命令,man中描述为:Concatenate FILE(s), or standard input, to standard
output.

而且,查查cat的参数就会发现,cat其实还有很多定制功能,但是type呢?估计只有/?参数
吧............

因为Unix以前相当依赖于Shell，（以前只有Shell)，加上其文化的影响，加上工作需要，每个
Shell命令都是比较强大，并且协作性非常好（因为那古老的规则），其中最最典型的就是find,grep有意者去尝试一下就知道了。另外，其实说命令
的话。。。。那perl,python算不算一个命令呢？。。。。。。呵呵，扯远了。

原创文章作者保留版
权转载请注明原作者并给出链接