《C++ API设计【软件API设计经典著作，Pixar动画系统首席工程师悉心讲解，软件工程效率之源】》 - [美]Martin - 人民邮电出版社 - 香港大書城

	登入帳戶　 \|　訂單查詢　 \|　購物車/收銀台(0)　\|　在線留言板　 \|　付款方式　 \|　運費計算　 \|　聯絡我們　 \|　幫助中心　\|　加入書簽
		會員登入新用戶登記

HOME

新書上架

暢銷書架

好書推介

2023年度TOP

臺灣用戶

品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心

服務：香港／台灣／澳門／海外

送貨：速遞／郵局／服務站

新書上架：簡體書繁體書
暢銷書架：簡體書繁體書
好書推介：簡體書繁體書

『簡體書』C++ API设计【软件API设计经典著作，Pixar动画系统首席工程师悉心讲解，软件工程效率之源】

書城自編碼： 2103261
分類：簡體書→大陸圖書→計算機/網絡→程序設計
作者： [美]Martin
國際書號(ISBN)： 9787115322999
出版社：人民邮电出版社
出版日期： 2013-09-01
版次： 1 印次： 1
頁數/字數： 362/560000
書度/開本： 16开釘裝：平装

售價：HK$ 235.9

我要買件

** 我創建的書架 **
未登入.

新書推薦：

《 8秒按压告别疼痛》
售價：HK$ 87.4

《津巴多时间心理学：挣脱束缚、改写命运的6种时间观》
售價：HK$ 77.3

《大英博物馆东南亚简史》
售價：HK$ 177.0

《纯粹·我只要少许》
售價：HK$ 80.6

《投机苦旅：一位投机客的凤凰涅槃》
售價：HK$ 88.5

《重返马赛渔场：社会规范与私人治理的局限》
售價：HK$ 69.4

《日子慢慢向前，事事慢慢如愿》
售價：HK$ 55.8

《场景供应链金融：将风口变成蓝海》
售價：HK$ 111.8

建議一齊購買：

HK$ 127.7
《高级C/C++编译技术》

HK$ 164.7
《C++并发编程实战》

HK$ 335.4
《大规模C++程序设计（由世界级软件开发大师John Lako》

HK$ 227.7
《深入理解C++11：C++ 11新特性解析与应用（C++标准》

HK$ 235.9
《C++ Templates中文版（模板奥秘，一览无余）》

編輯推薦：

有怪兽，有超人，有尼莫，有瓦力……
驱动Pixar神奇产能的技术要诀之一就是性能优异的API。
要高效，要稳定，要健壮，要扩展……
对API顺畅表现的期盼已然成为下游开发人员的由衷呼声
Pixar背后神秘技术推手Martin Reddy打造本书，面向中高级程序员，坦陈API不同风格及模式，融合大型项目内在需求，深入剖析各种最佳设计策略应用范围及利弊，为API设计过程的规范性和可持续性提供了中肯的建议和策略，堪称学习API设计的秘制宝典。
历时一年
中科院计算所专家潜心译制力作，图灵品质出版
所有付梓辛劳，都只为抚慰渴求且苛刻的你！

內容簡介：

如何构建高效、健壮、稳定且可扩展的优质API？对于这一软件工程上的难题，Martin Reddy凭借长期的从业经验，对优质API所应具备的各要素进行了全面分析，针对API的不同风格及模式，以及大型长期项目的内在需求，给出了种种最佳设计策略，从而对API设计过程的规范性及可持续性作出了理论上不可磨灭的贡献。
《C++ API设计》适合具有一定C++编程经验的程序员阅读，也适合对API设计主题感兴趣的读者参考。

關於作者：

Martin Reddy博士是软件行业的一名老兵，有着15年以上的从业经验，共撰写过40多篇论文，拥有3项软件专利，并与他人合著了Level of Detail for 3D Graphics。另外，他还是ACM以及IEEE的会员。
早年，他曾在SRI International供职5年，主要从事分布式三维地形可视化技术方面的工作，他成功创建了在Web上描述3D地球空间信息模型的ISO标准，并且还连续两年被选为Web3D协会的会长。
他曾在Pixar动画工作室工作过6年，担任内部动画系统的首席工程师，设计并实现了很多高性能API，这些API在一些奥斯卡获奖及提名影片的制作中都发挥了关键作用，这些影片有《海底总动员》、《超人总动员》、《赛车总动员》、《料理鼠王》，以及《机器人总动员》等。
他还开办了一家咨询公司Code Reddy，为各家软件公司提供技术咨询，主要客户有Linden Lab和Planet 9 Studios，为大型在线3D虚拟世界《第二人生》设计了API并改善了其基本架构。
现在他担任ToyTalk公司的首席技术官。

目　录

第1章　API简介　1
1.1　什么是API　1
1.1.1　契约和承包人　2
1.1.2　C++中的API　3
1.2　API设计上有什么不同　4
1.3　为什么使用API　5
1.3.1　更健壮的代码　6
1.3.2　代码复用　6
1.3.3　并行开发　8
1.4　何时应当避免使用API　9
1.5　API示例　10
1.5.1　API层次　10
1.5.2　真实示例　12
1.6　文件格式和网络协议　13
1.7　关于本书　15
第2章　特征　17
2.1　问题域建模　17
2.1.1　提供良好的抽象　17
2.1.2　关键对象的建模　19
2.2　隐藏实现细节　20
2.2.1　物理隐藏：声明与定义　20
2.2.2　逻辑隐藏：封装　22
2.2.3　隐藏成员变量　23
2.2.4　隐藏实现方法　26
2.2.5　隐藏实现类　28
2.3　最小完备性　29
2.3.1　不要过度承诺　29
2.3.2　谨慎添加虚函数　30
2.3.3　便捷API　31
2.4　易用性　33
2.4.1　可发现性　34
2.4.2　不易误用　34
2.4.3　一致性　36
2.4.4　正交　38
2.4.5　健壮的资源分配　40
2.4.6　平台独立　43
2.5　松耦合　44
2.5.1　仅通过名字耦合　45
2.5.2　降低类耦合　45
2.5.3　刻意的冗余　47
2.5.4　管理器类　48
2.5.5　回调、观察者和通知　50
2.6　稳定的、文档详细且经过测试的API　53
第3章　模式　54
3.1　Pimpl惯用法　55
3.1.1　使用Pimpl　56
3.1.2　复制语义　59
3.1.3　Pimpl与智能指针　60
3.1.4　Pimpl的优点　61
3.1.5　Pimpl的缺点　62
3.1.6　C语言的不透明指针　62
3.2　单例　64
3.2.1　在C++中实现单例　64
3.2.2　使单例线程安全　66
3.2.3　单例与依赖注入　68
3.2.4　单例与单一状态　69
3.2.5　单例与会话状态　71
3.3　工厂模式　71
3.3.1　抽象基类　72
3.3.2　工厂示例　73
3.3.3　扩展工厂示例　74
3.4　API包装器模式　76
3.4.1　代理模式　76
3.4.2　适配器模式　79
3.4.3　外观模式　81
3.5　观察者模式　83
3.5.1　MVC架构　83
3.5.2　实现观察者模式　84
3.5.3　推与拉观察者　87
第4章　设计　88
4.1　良好设计的例子　89
4.1.1　积累技术债　89
4.1.2　偿还技术债　90
4.1.3　为长期而设计　91
4.2　收集功能性需求　92
4.2.1　什么是功能性需求　93
4.2.2　功能性需求举例　94
4.2.3　维护需求　94
4.3　创建用例　95
4.3.1　开发用例　95
4.3.2　用例模板　95
4.3.3　编写高质量用例　96
4.3.4　需求与敏捷开发　98
4.4　API设计的元素　100
4.5　架构设计　102
4.5.1　架构的开发　103
4.5.2　架构的约束　104
4.5.3　识别主要抽象　105
4.5.4　创造关键对象　106
4.5.5　架构模式　109
4.5.6　架构的交流　110
4.6　类的设计　111
4.6.1　面向对象概念　112
4.6.2　类设计选项　113
4.6.3　使用继承　113
4.6.4　Liskov替换原则　115
4.6.5　开放?封闭原则　118
4.6.6　迪米特法则　119
4.6.7　类的命名　120
4.7　函数设计　121
4.7.1　函数设计选项　121
4.7.2　函数命名　122
4.7.3　函数参数　123
4.7.4　错误处理　125
第5章　风格　129
5.1　纯C API　129
5.1.1　ANSI C特性　130
5.1.2　ANSI C API的优点　132
5.1.3　使用ANSI C编写API　132
5.1.4　从C++中调用C函数　134
5.1.5　案例研究：FMOD C API　135
5.2　面向对象的C++ API　136
5.2.1　面向对象API的优点　136
5.2.2　面向对象API的缺点　136
5.2.3　案例研究：FMOD C++ API　137
5.3　基于模板的API　138
5.3.1　基于模板的API示例　138
5.3.2　模板与宏　139
5.3.3　基于模板的API的优点　140
5.3.4　基于模板的API的缺点　141
5.4　数据驱动型API　141
5.4.1　数据驱动型Web服务　142
5.4.2　数据驱动型API的优点　143
5.4.3　数据驱动API的缺点　144
5.4.4　支持可变参数列表　144
5.4.5　案例研究：FMOD数据驱动型API　147
第6章　C++用法　149
6.1　命名空间　149
6.2　构造函数和赋值　150
6.2.1　控制编译器生成的函数　152
6.2.2　定义构造函数和赋值操作符　153
6.2.3　explicit关键字　154
6.3　const正确性　155
6.3.1　方法的const正确性　155
6.3.2　参数的const正确性　157
6.3.3　返回值的const正确性　157
6.4　模板　158
6.4.1　模板术语　158
6.4.2　隐式实例化API设计　160
6.4.3　显式实例化API设计　162
6.5　操作符重载　164
6.5.1　可重载的操作符　164
6.5.2　自由操作符与成员操作符　165
6.5.3　为类添加操作符　166
6.5.4　操作符语法　168
6.5.5　转换操作符　170
6.6　函数参数　171
6.6.1　指针与引用参数　171
6.6.2　默认参数　172
6.7　避免使用#define定义常量　173
6.8　避免使用友元　175
6.9　导出符号　176
6.10　编码规范　179
第7章　性能　181
7.1　通过const引用传递输入参数　182
7.2　最小化#include依赖　184
7.2.1　避免“无所不包型”头文件　184
7.2.2　前置声明　184
7.2.3　冗余的#include警戒语句　186
7.3　声明常量　188
7.4　初始化列表　190
7.5　内存优化　192
7.6　除非需要，勿用内联　196
7.7　写时复制　198
7.8　迭代元素　202
7.8.1　迭代器　202
7.8.2　随机访问　203
7.8.3　数组引用　204
7.9　性能分析　205
7.9.1　时效性分析　205
7.9.2　基于内存的分析　207
7.9.3　多线程分析　208
第8章　版本控制　209
8.1　版本号　209
8.1.1　版本号的意义　209
8.1.2　小众的编号方案　210
8.1.3　提供API的版本信息　211
8.2　软件分支策略　213
8.2.1　分支策略　213
8.2.2　分支方针　213
8.2.3　API和并行分支　214
8.2.4　文件格式和并行发布产品　215
8.3　API的生命周期　216
8.4　兼容性级别　217
8.4.1　向后兼容性　217
8.4.2　功能兼容性　218
8.4.3　源代码兼容性　218
8.4.4　二进制兼容性　219
8.4.5　向前兼容性　221
8.5　怎样维护向后兼容性　222
8.5.1　添加功能　222
8.5.2　修改功能　223
8.5.3　弃用功能　224
8.5.4　移除功能　226
8.6　API审查　226
8.6.1　API审查的目的　226
8.6.2　API预发布审查　227
8.6.3　API预提交审查　228
第9章　文档　230
9.1　编写文档的理由　230
9.1.1　定义行为　230
9.1.2　为接口契约编写文档　232
9.1.3　告知行为的改变　233
9.1.4　文档涉及的内容　234
9.2　文档的类型　236
9.2.1　自动生成的API文档　237
9.2.2　概述文档　237
9.2.3　示例和教程　238
9.2.4　发布说明　238
9.2.5　授权信息　239
9.3　文档可用性　241
9.4　使用Doxygen　242
9.4.1　配置文件　242
9.4.2　注释风格和命令　242
9.4.3　API注释　243
9.4.4　文件注释　245
9.4.5　类注释　245
9.4.6　方法注释　246
9.4.7　枚举注释　247
9.4.8　带有文档的示例头文件　247
第10章　测试　250
10.1　编写测试的理由　250
10.2　API测试的类型　252
10.2.1　单元测试　253
10.2.2　集成测试　255
10.2.3　性能测试　257
10.3　编写良好的测试　259
10.3.1　良好测试的特征　259
10.3.2　测试对象　260
10.3.3　关注测试工作量　261
10.3.4　与QA一起工作　261
10.4　编写可测试的代码　262
10.4.1　测试驱动开发　262
10.4.2　桩对象和模拟对象　264
10.4.3　测试私有代码　267
10.4.4　使用断言　269
10.4.5　契约编程　270
10.4.6　记录并重放功能　272
10.4.7　支持国际化　273
10.5　自动化测试工具　273
10.5.1　自动化测试框架　274
10.5.2　代码覆盖率　277
10.5.3　缺陷跟踪系统　279
10.5.4　持续构建系统　280
第11章　脚本化　282
11.1　添加脚本绑定　282
11.1.1　扩充或嵌入　282
11.1.2　脚本化的优点　283
11.1.3　语言兼容性问题　284
11.1.4　跨越语言障碍　285
11.2　脚本绑定技术　286
11.2.1　Boost Python　286
11.2.2　SWIG　286
11.2.3　Python-SIP　287
11.2.4　COM自动化　287
11.2.5　CORBA　288
11.3　使用Boost Python添加Python绑定　289
11.3.1　构建Boost Python　290
11.3.2　使用Boost Python包装C++ API　290
11.3.3　构造函数　292
11.3.4　扩充Python API　293
11.3.5　C++中的继承　295
11.3.6　跨语言多态　296
11.3.7　支持迭代器　298
11.3.8　综合应用　298
11.4　使用SWIG添加Ruby绑定　300
11.4.1　使用SWIG包装C++ API　301
11.4.2　调整Ruby API　303
11.4.3　构造函数　304
11.4.4　扩充Ruby API　304
11.4.5　C++中的继承　305
11.4.6　跨语言多态　307
11.4.7　综合应用　307
第12章　可扩展性　310
12.1　通过插件扩展　310
12.1.1　插件模型概览　311
12.1.2　插件系统设计问题　313
12.1.3　以C++实现插件　314
12.1.4　插件API　315
12.1.5　插件示例　317
12.1.6　插件管理器　318
12.1.7　插件版本控制　321
12.2　通过继承扩展　322
12.2.1　添加功能　322
12.2.2　修改功能　323
12.2.3　继承与STL　324
12.2.4　继承与枚举　325
12.2.5　访问者模式　326
12.2.6　禁止子类化　331
12.3　通过模板扩展　332
12.3.1　基于策略的模板　332
12.3.2　奇特的递归模板模式　334
附录A　库　336
参考文献　351
索引　355

內容試閱：

编写大型C++应用既复杂又棘手，设计健壮、稳定、易用且耐用的可重用C++接口更是难上加难。在这些努力中获得成功的最佳途径就是遵循优秀的应用编程接口（Application
Programming Interface，API）设计原则。
API为软件组件提供逻辑接口，同时又隐藏实现该组件所需要的内部细节。它提供模块的高层次抽象，并通过多个应用共享相同的功能，以促成代码复用。
现代软件开发高度依赖于API，从底层应用程序框架到数据格式API，以及图形用户界面（GUI）框架。事实上，常见的软件工程术语，诸如模块化开发、代码复用、组件化、动态链接库（DLL）、软件框架、分布式计算以及面向服务的架构（SOA），都隐含了对高超的API设计技能的需求。
你也许了解一些流行的C和C++ API，比如标准模板库（STL）、Boost、微软Windows
API（Win32）、微软基础类库（MFC）、libtiff、libpng、zlib、libxml++、OpenGL、MySQL++、奇趣公司的Qt、wxWidget、GTK+、KDE、SkypeKit、POSIX
pthreads、英特尔的线程构建模块（Threading Building
Blocks）、Netscape插件API以及Apache模块API。除此之外，Google的许多开源项目也使用C++，在sourceforge.net、bitbucket.org和freshmeat.net网站上也有很多开源的C++代码。
在软件开发中，从桌面程序到移动计算和嵌入式系统，再到Web开发，都能见到上述API的踪影。例如，Mozilla
Firefox网页浏览器就是在80多个动态库的基础上构建的，其中每一个动态库都提供了若干个API的实现。
因此，优雅而健壮的API设计对现代软件开发至关重要。它区别于标准应用程序开发的一个重要特征，就是对变更管理的巨大需求。众所周知，在软件开发中，变化是一个不可避免的因素。新的需求、功能要求以及错误修复，这些要求导致软件从最初的设计以来要经历一系列从未预料的演变。然而，若API由数百个最终用户应用程序共享，那么变化就将引发巨大的动荡，并最终可能致使客户抛弃该API。因此，良好的API设计的首要目标是：在为客户提供所需功能的前提下，使新发布的API对客户代码造成的影响最小，理想状况下应该是零影响。
本书的价值
如果有其他软件工程人员需要依赖你所编写的C++代码，那么你就是API的设计者，本书就是为你而编写的。
接口是你编写的最重要的代码，因为如果接口出现问题，那么修复它的代价比修复实现部分的代价要高很多。举例来说，接口的变化要求对所有依赖此接口代码的应用进行更新，相比之下，当客户端应用采用新版本的API时，仅略微更改的实现则可以被透明地、毫不费力地集成。从经济的角度看，设计拙劣的接口会极大缩短代码的生存期。因此，写出高质量的接口是一项必备的工程技能，也是本书的焦点所在。
Michi
Henning曾指出，如今API设计比起20年前显得更为重要。因为近年来有更多的API被设计出来，这些API提供更为丰富和复杂的功能，并且被更多的最终用户应用所共享（Henning,
2009）。尽管如此，当前市面上着重介绍C++ API设计的书籍却不多。
需要指出的是，本书并不是一般的C++编程指南——市面上这类优秀书籍已经有很多本了。本书当然会涵盖许多面向对象的设计材料并提供很多有用的C++技巧和窍门，但更侧重清晰地描述C++中模块接口的技巧。因此，我不会深入讨论如何实现接口背后代码的问题，诸如具体的算法选择，或是应用于函数体花括号内代码的最佳实践。
然而，本书将涵盖API开发的整个领域，从最初设计到实现、测试、文档编写、发布、版本控制、维护以及最终弃用。我还会讨论一些特殊的API主题，如创建脚本化API和插件式API。虽然总体上许多主题也和软件开发相关，但这里着重强调API设计。举例来说，当讨论到测试策略时，我将重点介绍自动化的API测试技术，而不会试图囊括最终用户应用的测试技术，如GUI测试、系统测试或人工测试。
我曾领导过若干由多个合作机构共享的研究性代码的API开发，还有奥斯卡获奖影片所使用的内部动画系统API，以及全球上百万用户所使用的开源客户端、服务器API等。本书的内容正是基于以上这些实际经验的，正是这些实践让我明白，高质量API设计是成功的关键所在。因此，本书旨在提供工业强度的API设计技术与策略的实践精华，它们均源自一系列实践经验。
本书读者对象
虽然本书不是C++初学者的指南，我还是竭尽全力使文字更通俗易懂，并且清楚地解释所有的术语和行话。因此，无论你是想提高设计技能掌握C++基础的新手程序员，还是想获得新的专业技能以完善已有才能的高级工程师和软件架构师，本书都具备一定的参考价值。
在写作本书时，我拟定了3类特定的读者群体。
? 在职软件工程师和架构师。正在从事特定API项目的初级和高级开发人员，需要一些如何构建优雅且持久设计的实用建议。
? 技术经理。负责开发API产品的开发经理，以及想深入理解API设计的开发过程和技术问题的产品经理。
?
学生和教学人员。计算机科学和软件工程专业的学生，正在学习如何编程，或者正在寻找总结了全面、大型项目实践经验的软件设计资料的学生。
为什么选用C++来描述API设计
虽然有很多通用API设计方法学（可适用于任何编程语言或编程环境）可以讲，但最终都需要使用一门特定的编程语言来表述。因此了解特定语言的特征以促进规范的API设计是非常必要的。所以，本书专门使用一种语言（C++）描述API设计的问题，而非分散内容使其适用于所有语言。然而，想要使用其他语言（如Java或C#）开发API的读者仍然可以从本书中获得许多通用的深刻见解。本书的直接目标读者是编写并维护API的C++工程师，他们的API要供给其他工程师使用。
目前，C++仍是大型软件项目中使用最广泛的编程语言之一，并且日渐成为注重代码性能项目的首选语言，因此，你可以在自己应用中选用的C和C++的API种类非常多（前面我已经列出一些）。本书重点关注如何使用C++编写优秀的API，并引入了丰富的源代码示例以更好地阐述这些概念。也就是说，本书会涉及一些C++特有的主题，例如模板、封装、继承、命名空间、操作符、const正确性（const
correctness）、内存管理、STL的使用、Pimpl惯用法，等等。
另外，在本书出版期间，C++也正经历着巨大的变革。新版的C++规范处于ISOIEC的标准化进程中。目前，多数C++编译器遵循1998年首次发布的标准，即C++98。随后的标准于2003年发布，修正了前版的几处缺陷。自那时以来，标准委员会一直致力于制定一个重大的新版本规范。在标准被正式批准生效并确定发布日期之前，该版本一直被非正式地称为C++0x。当你读到本书时，新的标准可能已经发布了。但是，在我编写本书的期间，它仍然被称为C++0x。
尽管如此，C++0x已经达到标准化进程的高级阶段，我们可以满怀信心地预言一些新的特性。事实上，一些主流的C++编译器已经开始实现许多建议的新特性。在API设计方面，某些新特性可以用来构建更加优雅和健壮的接口。因此，我一直努力在整本书中强调和解释C++0x中的API设计。所以，本书在未来几年中应该依然具有参考价值。
术语及排版规约
传统上，我们使用术语“用户”（user）表示使用软件应用的人，比如Microsoft Word或者Mozilla
Firefox的用户。而在本书所指的API
设计背景下，此术语表示借助API创建应用的软件开发人员。换言之，本书通常提到的是API用户并不代表应用程序用户。与此同时，术语“客户”（client）在这一点上也具有相同的语义。注意术语“客户”除了指代使用API的人之外，还表示调用API函数的其他软件。
虽然有许多文件格式后缀可以用来标识C++源文件和头文件，如.cpp、.cc、.cxx、.h、.hh和.hpp，但本书将统一使用.cpp和.h。本书会交替使用术语“模块”（module）和“组件”（component）表示一对.cpp和.h文件。很明显它们不等价于一个类，因为一个组件或模块可能包含多个类。本书使用术语“库”（library）表示一个物理集合，即组件形成的包。也就是说，库＞模块组件＞类。
面向对象编程社区经常使用的术语“方法”（method）并不是严格的C++术语，它源自Smalltalk语言。在C++中与之等价的术语是成员函数（member
function），但是也有一些软件工程师喜欢使用更为具体的虚成员函数（virtual member
function）。本书并不特别关注这些术语的微小差别，故将交替使用方法和成员函数。同样，虽然在C++中，数据成员（data
member）是更准确的表述，但是本书将术语“成员变量”（member variable）视为它的同义词。
考虑到印刷习惯，本书使用等宽字体编排所有源代码示例以及正文中出现的所有关键字。在本书给出的示例中，我习惯使用大写驼峰式命名法（upper
camel
case）书写所有类和函数的名字，即使用CamelCase而非camelCase或snake_case。不过，我会保留引用的外部代码的大小写形式，如std::for_each。本书遵循在数据成员名前添加m前缀以及在静态变量前添加s前缀的习惯约定，如mMemberVar、sStaticVar。
应当指出，书中的源代码往往只是代码片段而并非功能完整的样例。我还会省略示例代码中的注释。这样做是为了简洁和清晰。特别地，我经常会省略头文件前后防止重复引用的预处理警戒语句。本书认定读者都已清楚CC++头文件需要将所有内容包含在预处理警戒语句（preprocessor
guard）中，并且最好将所有的API声明都包含在统一的命名空间下（见第3章和第6章）。换言之，本书假定给出的每个头文件都默认包含如下代码：
#ifndef MY_MODULE_H
#define MY_MODULE_H
需要#include的文件……
namespace apibook{
API声明……
}
#endif
提示
本书中，我也会强调各种有关API设计的小提示和关键概念。提供这些标注是为了让你能够快速搜索到想要重读的概念。如果你的时间非常有限，可以只浏览书中的这些小提示，然后阅读提示附近的内容以深入理解你最感兴趣的主题。
本书的网站
本书也有一个支持网站：http:APIBook.com。该网站提供了本书的全部信息以及一些辅助资料，如书中示例的完整源代码。读者可以随意下载并使用这些样例。样例设计得尽可能简单，但仍然极具价值。本书使用跨平台的CMake构建系统来编译和链接这些示例，因此它们可以在Windows、Mac
OS X 及 Unix操作系统上运行。
我也会在此网站上发布所有对该书的新的修订以及勘误表，还有互联网上其他相关的API资源的链接，如有趣的工具包、文章和实用程序等。
本书的网站上也提供了一个由我编写的名为Diff的API组件。此程序可以通过可视化的对照方式，比较两个版本的API，并检查编码和注释上的不同之处。你也可以用它生成某个特定发行版本的变更报告，这样你的客户就能准确知道需要注意什么了。该工具适用于Windows、Mac
OS X 及 Linux。

書城介紹　 \|　合作申請　\|　索要書目　 \|　新手入門　\|　聯絡方式　 \|　幫助中心　\|　找書說明　 \|　送貨方式　\|　付款方式	香港用户　 \|　台灣用户　\|　海外用户

	megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.