我了解指针和引用的语法和一般语义，但是我应该如何决定什么时候在API中使用引用或指针比较合适?
当然，有些情况需要其中一个(操作符++需要引用参数)，但一般来说，我发现我更喜欢使用指针(和const指针)，因为语法很清楚，变量是破坏性传递的。
例如，在以下代码中:
void add_one(int& n) { n += 1; }
void add_one(int* const n) { *n += 1; }
int main() {
int a = 0;
add_one(a); // Not clear that a may be modified
add_one(&a); // 'a' is clearly being passed destructively
}
使用指针，它总是(更)明显的发生了什么，所以对于api和类似的地方，清晰度是一个大问题，指针不是比引用更合适吗?这是否意味着引用应该只在必要时使用(例如操作符++)?其中一种是否存在性能问题?
编辑(过时的):
除了允许NULL值和处理原始数组之外，选择似乎还取决于个人喜好。我接受下面的答案，引用谷歌的c++风格指南，因为他们提出的观点是“引用可能会令人困惑，因为它们有值语法，但有指针语义。”
由于需要额外的工作来清除不应该为NULL的指针参数(例如，add_one(0)将调用指针版本并在运行时中断)，从可维护性的角度来看，在必须存在对象的地方使用引用是有意义的，尽管失去语法的清晰性是一种遗憾。
任何性能差异都是如此之小，以至于使用不太清楚的方法都是不合理的。
首先，有一种引用通常更好的情况没有提到，那就是const引用。对于非简单类型，传递const引用可以避免创建临时类型，也不会引起您所关心的混乱(因为该值没有被修改)。在这里，强制某人传递指针会导致您所担心的混乱，因为看到地址被获取并传递给函数可能会使您认为值已更改。
无论如何，我基本上同意你的看法。我不喜欢函数接受引用来修改它们的值，而这不是很明显的函数在做什么。在这种情况下，我也更喜欢使用指针。
当需要以复杂类型返回值时，我倾向于使用引用。例如:
bool GetFooArray(array &foo); // my preference
bool GetFooArray(array *foo); // alternative
在这里，函数名清楚地表明您正在从数组中获取信息。这样就不会混淆了。
引用的主要优点是它们总是包含一个有效值，比指针更简洁，并且支持多态，而不需要任何额外的语法。如果这些优点都不适用，就没有理由更喜欢引用而不是指针。
任何性能差异都是如此之小，以至于使用不太清楚的方法都是不合理的。
首先，有一种引用通常更好的情况没有提到，那就是const引用。对于非简单类型，传递const引用可以避免创建临时类型，也不会引起您所关心的混乱(因为该值没有被修改)。在这里，强制某人传递指针会导致您所担心的混乱，因为看到地址被获取并传递给函数可能会使您认为值已更改。
无论如何，我基本上同意你的看法。我不喜欢函数接受引用来修改它们的值，而这不是很明显的函数在做什么。在这种情况下，我也更喜欢使用指针。
当需要以复杂类型返回值时，我倾向于使用引用。例如:
bool GetFooArray(array &foo); // my preference
bool GetFooArray(array *foo); // alternative
在这里，函数名清楚地表明您正在从数组中获取信息。这样就不会混淆了。
引用的主要优点是它们总是包含一个有效值，比指针更简洁，并且支持多态，而不需要任何额外的语法。如果这些优点都不适用，就没有理由更喜欢引用而不是指针。
免责声明:除了引用不能为NULL或“反弹”(意味着它们不能改变它们是别名的对象)这一事实之外，它真的归结为一个品味问题，所以我不会说“这更好”。
也就是说，我不同意你在文章中最后的说法，因为我不认为代码在引用中失去了清晰度。在你的例子中，
add_one(&a);
可能会更清楚
add_one(a);
因为你知道a的值很可能会改变。另一方面，函数的签名
void add_one(int* const n);
也不太清楚n是单个整数还是数组?有时您只能访问(文档记录不佳的)头文件和签名
foo(int* const a, int b);
乍一看不容易理解。
在我看来，当不需要(重新)分配或重新绑定(在前面解释的意义上)时，引用和指针一样好。此外，如果开发人员只对数组使用指针，那么函数签名就不会那么模糊。更不用说使用引用的操作符语法可读性更强了。
从 C++ 常见问题精简版 -
Use references when you can, and pointers when you have to.
References are usually preferred over pointers whenever you don't need
"reseating". This usually means that references are most useful in a
class's public interface. References typically appear on the skin of
an object, and pointers on the inside.
The exception to the above is where a function's parameter or return
value needs a "sentinel" reference — a reference that does not refer
to an object. This is usually best done by returning/taking a pointer,
and giving the NULL pointer this special significance (references must
always alias objects, not a dereferenced NULL pointer).
Note: Old line C programmers sometimes don't like references since
they provide reference semantics that isn't explicit in the caller's
code. After some C++ experience, however, one quickly realizes this is
a form of information hiding, which is an asset rather than a
liability. E.g., programmers should write code in the language of the
problem rather than the language of the machine.
