pretty unusual these days to use single-width character sets, using TCHAR makes it easier
for you to port back to a single-width system if you need to. In a few years time, we can
drop all this and just use a wide character set for everything.
You‘ll notice that CHAR and unsigned CHAR is still used in code that needs 8-bit values,
specifically when dealing with graphics, sound data, or SDKs that prefer single width
character sets, such as ZLib.
I tend to use std::string and std::wstring throughout the book. It is an incredibly
useful string class, and while not everyone agrees, it‘s the one I‘m most comfortable with.
In the code samples, I generally use literal strings for clarity. In a real project, every string
that could possibly be seen by anyone playing the game is declared in a string table. The
string table can be managed by a global class, such as your application class, and you have
an easy way to swap out one language for another:
std::string msg = g_pApp-&GetString(IDS_QUESTION_QUIT_GAME);
Regarding the resource constant, I don‘t attempt to encode the exact text of the string in
the macro. It takes too long to type and muddles the code. I usually find a good
abbreviation.
One final note about strings in real game code: Debug strings or names for objects are fine
as literals. You can declare them at will:
if (impossibleError == true)
{
OutputDebugString(_T("Someone enabled the impossible error
flag!"));
}
Commenting
Really good code comments itself, and I‘m hoping the code in this book does exactly that.
Good variable names and logic should obviate the need for wordy explanations. In this
book, I‘ll sprinkle comments in the code where I think they do some good, but you‘ll usually
find some meaty explanation immediately after the code sample.
In a real game, the meaty explanation should be inserted into the code, perhaps at the
beginning of the file, so that other programmers can figure out what‘s going on. What
seems obvious the moment you type the code degrades linearly with time to a confusing
mess. For me, total confusion sets in approximately three months after I write the code.
How could I possibly expect anyone else to understand it if I‘m completely lost in something
I wrote myself?
I always start projects with the intention of putting good comments in my code. I always
end projects disappointed in other programmers and myself—we just didn‘t have enough
time. That happens. Projects under pressure will see comments disappear because the
programmers are spending 100 percent of their time coding like mad. The best policy is to
start off with a lean, light commenting policy and keep it up as long as you can. If there
comes a point in the project where comments are dwindling, try to make a good effort to go
back in the code base after the project releases to document the code. A good friend of
mine at Microsoft told me that shipping the product was a good feature. I agree.
剩余754页未读，继续阅读
cloudffx
- 粉丝: 1
- 资源: 5
我的内容管理
展开
最新资源
- 岩石滑动与断层冲击地压：声发射特征分析
- 新时代煤炭工业八大战略新取向剖析
- 开采强度对华亭矿区冲击地压危险性的影响分析
- 新安煤矿探采对比：影响安全生产的关键因素与技术支撑
- 210MW循环流化床锅炉引风机变频改造优化与节能效果
- 浅埋煤层开采沉陷预测：方法应用与影响分析
- 优化巷道过陷落柱支护方案：数值模拟与现场试验
- 坚硬顶板定向断裂爆破技术：安全高效采煤新方案
- 北航2019算法课作业解析：投资策略与凸子多边形优化
- 断层破碎带垮冒下堆积体边界抗力分布关键影响因素
- 哈拉沟选煤厂优化末煤系统提高效率与处理能力
- 瓦斯涌出影响下采动煤体蠕变失稳研究
- 提升煤矿装载效率的可控箕斗定量装载设备设计
- 水分调控下烟煤瓦斯吸附特性对比研究
- 重介质悬浮液密度控制硬件设计与选型探讨
- 坚硬顶板巷道支护参数设计：现场测试与数值分析
资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！
点击此处反馈
