C++参考/指针语法的替代方案

Question

除了C和C++之外，还有哪些语言具有显式的引用和指针类型限定符？人们很容易被类型的从右到左的阅读顺序所困惑，例如char*&是“指向字符的指针的引用”，或者是“字符指针引用”；是否有任何使用从左到右阅读顺序的显式引用的语言，例如&*char/ref ptr char？我正在开发一种小型编程语言，易读性是我的主要关注点之一。

在我看来，这似乎是那种对于人来说很容易但对于搜索引擎来说很难提供答案的问题。提前感谢！

- Jon Purdy

---

我同意声明可能会变得难看，但你觉得“指向字符的指针的引用”和“字符指针引用”之间有什么区别呢？ - UncleBens

没有区别，只是阅读顺序不同。一个使用自然的英语排序，另一个使用同位语来近似自然的英语排序，从人工语言排序中得出。 - Jon Purdy

Answer 1

斯特劳斯特鲁普曾经说过，声明语法是“失败的实验”。不幸的是，为了与C兼容，C++必须遵循它。最初的想法是，声明看起来像一个用法，例如：

char * p;  // declare
* p;       // use (dereference)

但是对于更复杂的声明，这种方式很快就会崩溃。许多人（至少是许多Pascal程序员）更喜欢以下语法：

variable : type;

其中 type 类似于：

array of char

这是关于IT技术的，相对易读，从左到右阅读。

- anon

---

我认为Ritchie后来回复说他仍然支持那种语法（不过我没有引用）。就个人而言，我同意Stroustrup的观点。 - Konrad Rudolph

当C++拥有模板typedefs时，您将能够执行类似于 template<class T> typedef T* ptr_t; template<class T> typedef T& ref_t; ref_t<ptr_t<char>> p; 的操作。我想知道Stroustrup对此感觉如何。 - Jon Purdy

在我看来，破坏一切的是引用。到目前为止，即使是成员函数指针，声明与使用也非常相似（类型=>该类型的表达式，::=>.）。现在随着C++0x的出现，右值引用使情况变得更加“糟糕” :) - Johannes Schaub - litb

没有引用，就不会有运算符重载和复制构造函数。 - Seva Alekseyev

@UncleBens 请明确你在评论谁的评论。 - anon

Answer 2

我认为这已经过时了，但它可能对你有用： http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C%2B%2B_Syntax。该网页介绍了更易读、更易懂的C++语法。请注意保留 HTML 标记。

- jmucchiello

---

哇，我好久没见过这个了。有点可惜它从来没有流行起来。差一点。 - Jon Purdy

它通过一种与旧含义完全无关的新含义来重载 ->，这样就应该更加清晰明了吗？ - caf

@caf- 这个新的含义仅适用于函数定义中的返回值，如果我没记错的话，C++0x标准还覆盖了->以在函数原型中使用。请参阅新C++功能列表中的“替代函数语法”。 - jmucchiello

我能理解，但是相同的语法元素意味着完全不同和无关的东西，这仍然让我觉得是个错误。 我建议 C++0x 应该仔细考虑使用不同的东西（也许是 =>？） - caf

（例如，人们仍然会混淆逗号运算符和用于分隔函数参数的逗号！） - caf

Answer 3

相比之下，Perl 5 的方法在解除引用时是从左到右阅读的：

$i = 10;  # Scalar
say $i;

$j = \$i;  # Scalar reference
say $$j;

@a = (1, 2, 3);  # Array
$b = \@a;  # Array reference
say $a[0];
say $$b[0];  # prints same thing

但是，与C/C++不同的是，针对变量名使用的sigil决定了将要读取的类型（标量vs数组vs哈希）

say "Array size: " . scalar(@a);
say "Array size: " . scalar($@b);  # dereference with $, access as @ (array)

- spoulson

Answer 4

Pascal强制类型别名。您不能声明:

myvar: ref to array of struct{..pointer to char.}

您必须在TYPE块中单独声明每个链接步骤。

这可以提高可读性（如果您不介意上下滚动），也可能更容易解析。

- Seva Alekseyev