你你你... 唉，说你什么好。这段程序的目的是省略一个if语句，以及省略一个变量reset的语句。在游戏里，速度是最重要的因素之一，所以为了效率就得牺牲其它的一些东西，如可读性等。

collapsar(笨笨和旦旦.IMMANUEL)

当然，如果这点效率的提高对整个应用不重要的话，我也不赞成这么写程序。

Anyway，这个程序的输出应该是12012x。

不如这样，请你用你的方法去完成这个程序的目的（遵从原程序的意图），然后比较一下谁的运行速度更快好了。比方说，我用以下的方法来重写这段程序，

void main()
{
int a = 1;

for (int i = a; i < 3; ++i)
{
printf("%d", i);
}

for (i = 0; i < 3; ++i)
{
printf("%d", i);
}

printf("x");
}

如果你把这两者都运行数次（比方说1,000,000次）你就会明白我的意思了。

(#3475817@0)
Last Updated: 2007-2-3
This post has been archived. It cannot be replied.

#include void main() { int a = 1; switch(a) { case 0: while (a < 3) { printf("0"); case 1: printf("1"); case 2: printf("2"); a++; } default: printf("x\n"); break; } }

! -iwantcar(恶疾,时日无多,戒网); 2007-2-3 (#3475114@0)

这么写程序, 拉出去毙了! -wangqingshui(忘情水); 2007-2-3 (#3475130@0)

这是写游戏中为了提高效率而牺牲可读性的一种做法。我还有更绝的一段程序呢。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3475422@0)

效率个屁，这就是写了十几二十年程序只会C的人在耍无聊。C这碗饭也太容易吃了，都把人惯成这样了 -heeltoe(不過三); 2007-2-3 (#3475585@0)

你你你... 唉，说你什么好。这段程序的目的是省略一个if语句，以及省略一个变量reset的语句。在游戏里，速度是最重要的因素之一，所以为了效率就得牺牲其它的一些东西，如可读性等。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 {530} (#3475817@0)
当然，如果这点效率的提高对整个应用不重要的话，我也不赞成这么写程序。

Anyway，这个程序的输出应该是12012x。

不如这样，请你用你的方法去完成这个程序的目的（遵从原程序的意图），然后比较一下谁的运行速度更快好了。比方说，我用以下的方法来重写这段程序，

void main()
{
int a = 1;

for (int i = a; i < 3; ++i)
{
printf("%d", i);
}

for (i = 0; i < 3; ++i)
{
printf("%d", i);
}

printf("x");
}

如果你把这两者都运行数次（比方说1,000,000次）你就会明白我的意思了。

I think this is nonsense, if you write code for efficient and don't care about readability, for any company this is "suicide". you made the first version of your game quick and fun, good, what about next version? what about bugs? -canadiantire(轮胎-pax et lux); 2007-2-3 (#3475859@0)

That depends on how you look at it. -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 {671} (#3475906@0)
In game industry, especially in Engine side, where efficiency is the top concern, and changes seldom occur, code like this makes sense. But in term of GUI, and /or Control, you are right, there is no need to write code in such a way.

Again, in industries such as gaming, in an MVC (Model-View-Control design pattern), codes in Model are always of speed concerned. But in term of View, and Control, where flexibilities, extensibility and maintainability are always the top priorities, it's discouraged to write code that way.

As a matter of fact, the code segment in question was a varied form from an interview question for many game companies a few years back.

忘记是那个东西（ACE or APACHE里面老这么整）。这样的东西诚如你所说的有效率的考虑。 -frankwoo(柳五随风); 2007-2-3 (#3475893@0)

嗯，我相信这段程序有它存在的理由。正如有时候不得不用汇编语言来写一个函数/程序一样。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3475923@0)

printf("12012x") -heeltoe(不過三); 2007-2-3 {298} (#3475952@0)
这个程序的目的是什么？原程序的意图是什么？我们不知道。你的程序是基于你猜测的原程序的意图，并不真的是原来的意图。在我看来原来的程序输出12012x，OK，那我也输出12012x就够了。

你能找出个真实的例子需要这样写的吗？

退一万步讲，即使真的有这样的需求，我也宁愿用goto。goto同样不好读，但至少goto不误导。

不给你一段真正的程序看来你是不服的。那么准备作题吧： -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 {523} (#3475990@0)
下面这段程序是做什么的？为什么是这样做？你会怎么做并比较一下效率。

void send(register short* to, register short* from, register count)
{
register n = (count + 7) / 8;

switch (count % 8)
{
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}

做完后请知会一声，然后我公布答案。

唉...十五年前我是玩这种东西的高手。不就是省了几个JZ么，至于么？要是效率真那么重要也别一个一个*to=＊from++了，直接汇编复制一段内存多好 -heeltoe(不過三); 2007-2-3 (#3476037@0)

你说得不错，不过请注意to指针并没有递增，所以这不是内存块拷贝的问题。在什么情况下会这样呢？ -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476042@0)

哦，没注意to。难怪要一个一个复制。那边是显存？ -heeltoe(不過三); 2007-2-3 (#3476050@0)

没错，是串行(serial)设备。你一眼就看出来了，不愧是真正的高手。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476052@0)

惭愧，我自吹高手是吹着好玩儿的。 -heeltoe(不過三); 2007-2-3 {85} (#3476069@0)
听说Cisco在San Jose招写设备驱动程序的senior，有空缺都找不到人。你有没有兴趣去试一下？

谢谢你的信息，我也不是这方面的高手，只是以前做游戏开发时碰巧看到过别人这么写code而已。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476080@0)

公布答案了，如果你还没来得及做题又不想先看答案可以先不看。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 {357} (#3476072@0)
其实很简单，以上程序段的道理和以下两段程序的比较是异曲同工的。

（1）
for (int x = 0; x < 100; x++)
{
delete(x);
}

（2）
for (int x = 0; x < 100; x += 5)
{
delete(x);
delete(x+1);
delete(x+2);
delete(x+3);
delete(x+4);
}

当然，原题还有更重要的因素需要考虑。详情请见URL: http://en.wikipedia.org/wiki/Duff's_device

这个雕虫小技记下来了，找个机会用用，看能不能镇住人. 呵呵... -eagle_no1(瞎起哄); 2007-2-3 (#3476159@0)

一定能镇得住我。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476177@0)

把你的 (count + 7) / 8 改成 (count +7 ) >> 3 再把 switch (count % 8) 改成switch(count & 7) 就更能把人忽悠得一愣一愣的了 -eagle_no1(瞎起哄); 2007-2-3 (#3476212@0)

>>不安全，依赖于编译器。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476226@0)

强类型，比如unsigned int的话就安全了。当然&7问题不大，不过碰上PCC这样变态的6-bit byte的话就得小心了。 -frankwoo(柳五随风); 2007-2-4 (#3476502@0)

count & 7 不能完成所需的工作，%是为了求模。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476228@0)

? ? 0%8=?; 1%8=?; 8%8=?; ..10%8=? -eagle_no1(瞎起哄); 2007-2-3 (#3476246@0)

我错了。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476260@0)

看来这种忽悠方法很有成效；：-）） -eagle_no1(瞎起哄); 2007-2-3 (#3476267@0)

我早就说一定能镇得住我的了。:)) -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476271@0)

你这种程序的写法是典型的耍小聪明,如果一个大项目要到最后变成依靠这些小地方挤出那么一点点PERFORMANCE.这个项目离失败就没有多远了.如果极其在乎PERFORMANCE.那么就直接写汇编.另外,提高PERFORMANCE的地方有很多很多,我就不相信要弄到这个地步. -iwantcar(恶疾,时日无多,戒网); 2007-2-4 (#3476573@0)

首先声明我没有写游戏程序的经验, 对游戏程序速度的重要性没有那么深的感受. 但是我觉得游戏程序大量的IO, 比计算慢多了, 省一个if语句真的那么重要吗? 另外, 编译器也有优化功能啊. -wangqingshui(忘情水); 2007-2-3 (#3475997@0)

编译器有优化功能是不错，但并不是完全可信的。我并不是专家，我只是想说这一切是有原因的，不然为什么有时候有些程函数必须用汇编写呢？说实在的，以上这段程序正是受汇编的启发而写的。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476008@0)
现在回答你为什么游戏中速度这么重要的原因：几年前显卡的功能还没有这么强大，很多图形运算/渲染还得靠CPU而不是GPU来实现。现在情况好了，但是一个游戏公司可不能假设所有人的计算机都有一块高品质的显卡，不然会失会很多市场的。 -collapsar(笨笨和旦旦.IMMANUEL); 2007-2-3 (#3476016@0)
wrong. -iwantcar(恶疾,时日无多,戒网); 2007-2-4 (#3476569@0)

您老能把话说明白点吗? 到底什么不对? 谢谢. -wangqingshui(忘情水); 2007-2-4 (#3476927@0)

游戏程序大量的IO, 比计算慢多了 -iwantcar(恶疾,时日无多,戒网); 2007-2-4 (#3476955@0)

谢谢. -wangqingshui(忘情水); 2007-2-4 (#3476998@0)

我考，牛人，俺不行了。 -pigkiller(早起的虫子); 2007-2-3 (#3475401@0)

contractor 写的, 写的好! 合同还得续签' -eagle_no1(瞎起哄); 2007-2-3 (#3475873@0)

@Calgary

你你你... 唉，说你什么好。这段程序的目的是省略一个if语句，以及省略一个变量reset的语句。在游戏里，速度是最重要的因素之一，所以为了效率就得牺牲其它的一些东西，如可读性等。

Replies, comments and Discussions:

More Topics