尽管如此，C++0x已经提上标准化议事日程，很多新特性是可以预期的。事实上，一些主流C++编译器已经开始开发着手实现这些新特性。就API设计而言，其中的一些新特性可以利用来设计更优雅和稳固的接口。同样地，在全书中我将尽力关注和解释C++0x这些方面的内容。C++0x还要几年才能正式出来，所以本书讲述的关于C++0x的相关资源还是不会有什么变化。
约定
“用户”（user）这个术语在传统概念中是表示软件程序的使用人，如微软 Word字处理软件用户或者Mozilla火狐浏览器用户。在API设计语境中，表示一个软件开发人员，他利用某个API来开发一个程序。换句话说，我通常都是在讨论API用户，而不是什么程序软件的用户。还有就是术语“客户”（client）的意思也是一样的。不过要注意的是，这个术语“客户”也可以是使用你所设计的API的那个人，还可以表示调用API功能的软件。
虽然标识C++源文件和头文件的扩展名有很多种，如.cpp 、.cc、.cxx、.h、.hh和.hpp，但是全书中我都统一以.cpp和.h为标准。我也会交替使用模块和组件这两个术语来表示一组.cpp和.h文件对。这些显然和一个类是不一样的，因为一个模块或者组件可以包含多个类。我还会用术语“库”表示一个物理上的集合或包。这几者的关系是库>模块/组件>类。
“方法（method）”这个术语，就是和面向对象编程领域中大家理解的一样，并不是严格的C++术语。它起初是从Smalltalk语言发展过来的。同等的C++术语应该叫成员函数（member function），不过有些工程师喜欢更精确的定义：虚成员函数（virtual member function）。本书中，我并不是特别关注这些术语的微妙差异，我会交替使用方法和成员函数。同样地，虽然术语“数据成员”（data member）更符合C++的表述风格，但是我还是会使用“成员变量”（member variable）来表示同样的意思。
就排版约定而言，所有的包含源代码的例子都使用固定宽度的字体，还有所有文件名、文中出现的编程语言的关键字也一样。我给出的所有类名和函数名都采用首字母大写的“骆驼拼写法”（译者注：camel case 在英语中，依靠单词的大小写拼写复合词的做法）。例如，CamelCase来取代camelCase或snake_case，不过我在引用外部代码时会保留如下写法：std::for_each()。我还会遵循如下约定，在使用数据成员时会加一个前缀“m”，例如：mMemberVar，而“s”用在静态变量（static variable）之前，例如：sStaticVar。
应该指出的是本书中的带有源码的例子常常是一个代码片段（code snippet），并不是带有完整功能的例子。本书中，我还经常省略掉例子的注释，这样做的原因是为了简洁和清晰。特别地，我常常省略头文件（header file）中的所有“预处理保卫”（译者注：preprocessor guard 避免出现重复 #include 头文件的情况）语句。我认为读者已经知道每个C/C++头文件都要放在保卫语句之内，还有就是把所有的API声明都放在某个一致的名空间之内（这将在第三章和第六章中讲述）。换句话说，我给出的每个头文件都隐含了如下代码：
[P4 代码 P20 第一段1]
#ifndef MY_MODULE_H
#define MY_MODULE_H
// required #include files...
namespace apibook {
// API declarations ...
}
#endif
提示
我在全书中也会着重讲述API设计的各种建议和关键概念。这个“提示”标记方便你想重读某个概念时可以快速地找到它。如果你的时间非常紧迫，你可以简单地浏览书中的这些提示，然后再阅读周围的文字，这样你就可以找到那些你最感兴趣的主题。
本书网址
本书还有一个配套的网站，http://APIBook.com/。在这个网站，你可以找到关于本书的综合信息，以及配套资料，如完整的源码例子。你可以随意下载并自由使用。它们被设计成尽可能的简单，不过做为作为例子也还是很有用的。我已经使用了跨平台的CMake构建系统，这样方便编译和链接例子，他们应该都可以运行在Windows，Mac OS X和UNIX操作系统上。
我也会在网站上发布所有新的勘误信息，还包括网上的其它有用的API资源的链接，例如有趣的工具、文章和程序。
本书网站还提供了一个我写的API Diff的程序。该程序可以让你比较某个API的两个版本，浏览它们代码间的差异或并排格式可视化显示并排格式的可视化注释。你还可以给指定的发布版本给客户API生成所有变动的报告，这样客户就可以清楚地找到什么是他们需要的。这个程序可以在Windows，Mac OS X和Linux操作系统上运行。