如何要求一个小的添加？（纯虚函数的语法）答案

【问题标题】：How to ask for a small addition? (syntax of pure virtual functions)如何要求一个小的添加？（纯虚函数的语法）
【发布时间】：2010-10-25 12:58:51
【问题描述】：

在current C++0x draft 中，我注意到他们引入了一些新的显式关键字来突出预期的行为（很棒的举动！）。

示例：defaulted/deleted 函数（= 默认 和 = delete），新的nullptr 常量，explicit 关键字也可用于转换运算符，. ..

所以我希望看到纯虚函数的 = pure 语法。

相反，丑陋的（当然是恕我直言）= 0 的东西仍然存在。

好的，我可以使用 #define pure 0（有时我会这样做），但我认为一致性/一致性绝对应该是标准的目标。此外，我知道这只是一种极端迂腐的要求，但 = 0 确实是我最不喜欢的 C++ 部分之一（委婉说法）...

我的问题：

我知道，新标准功能齐全，但是否仍然可以要求这个小小的迂腐添加，即使只是作为“必需的宏”东西？
如果答案是肯定的，怎么办？（周围有委员会成员吗？）
我是不是有点过于迂腐（或错误）来要求这个补充？您如何看待当前纯虚函数的语法？

【问题讨论】：

+1 来自我顺便说一句。这是一个非常好的问题，我认为如果更多人对他们的工作感兴趣，标准委员会会喜欢它。 :)
谢谢！正如其他 cmets 所说，我不是专家，我刚刚开始阅读最后一稿（1347 页）......

标签： c++ standards c++11

【解决方案1】：

这不是一个小小的迂腐变化。引入新关键字是您可以要求的最大更改之一。这是他们几乎不惜一切代价试图避免的事情。想想所有使用“纯”这个词的代码，它会中断。

一般来说，他们的指导方针是只在语言中添加以前无法完成的内容。 pure 关键字不会启用任何新功能（例如，与 nullptr 关键字不同，它可以实现更好的类型检查），因此希望它具有非常低的优先级。请记住，他们所做的任何事情基本上都是维护工作。 #1 目标是避免破坏语言（或使用它的现有代码）。添加的任何功能只有在不破坏向后兼容性的情况下才能添加。

但是，委员会或多或少是一个开放的论坛。浏览他们的website，您应该能够找到一些电子邮件地址。或使用comp.std.c++ 新闻组。

我相信他们的会议也是开放的，所以你可以直接闯入下一个会议。 ;)

【讨论】：

我自己不是专家，但我认为在这种情况下使用的 = pure 不应该破坏任何东西。无论如何，关于“pure as a new keyword”问题，我认为您是对的：我根本没有考虑过这个问题......谢谢。
感谢您的回答。有趣的是，default 和 delete 已经是 c++ 关键字，但是在不同的上下文中。
一个问题。他们引入了“null_ptr”作为新关键字。如果他们将其命名为“未定义”，那么使用它来定义纯虚函数是合乎逻辑的，正如 Gian 所建议的那样......还是我在做梦？ :)
没错，我想。但是它在空指针上下文中就失去了意义。空指针不是未定义的。它是空的。您可以将其与其他指针进行比较，并获得一致的结果。你不能用未定义的值来做到这一点。它会使现有的 C++ 程序员感到困惑。他们知道空指针是什么，所以他们可以猜出 null_ptr 的含义。但是“未定义”？不过你说得有道理，他们可能会找到一个涵盖这两种情况的词。但同样，这样做会获得多少？
void 一般有表示某物不存在的意思。就像强制转换为 void 表示不使用计算的值。参数列表中的 void 表示没有参数，当然作为返回类型表示没有返回值。和 =void 表示没有实现，或者更准确地说，需要在派生类中实现。

【解决方案2】：

你最讨厌 C++ 的地方是“= 0;”？？？

您曾经使用过这种语言吗？还有很多其他的事情你可以更好地消磨你的仇恨。

<Flame retardant>我用C++已经10多年了。对我来说，当我需要做一些繁重的计算时，它仍然是首选语言。</Flame retardant>

【讨论】：

这不是这种语言最糟糕的事情，恕我直言（6 年以上的这种语言，顺便说一句）。但自从我使用 C++ 的第一天起，我就非常讨厌这个东西，当我看到草稿（这个和上一个）时，我希望在这方面看到“一些东西”。换句话说：我认为这个补充是如此小，它可以进入下一个草案。我没想到会出现“as-a-new-keyword”问题，因为我的“提案”仅限于“必需的宏”。 :)
但是宏会导致更多问题。如果它是关键字，编译器可以限制范围，使其不会影响名为“纯”的变量或函数。但是宏只会将它们 all 替换为 0。:)
是的，这是个问题。我问了这个问题，提供了一个简单的建议，而不是完美的解决方案。对不起...^^'

【解决方案3】：

首先，开始阅读comp.std.c++ 新闻组。这是公开讨论的地方。

其次，我会说只有勘误表将应用于当前的 C++0x 草案，委员会确实处于最后阶段。

如果您非常热衷，请在新闻组中提出您的建议，并提供非常好的理由。并期待它被击落。更多有用的提案（例如模块）尚未提出。

附录：如果您希望这样的事情取得进展，您将需要加入（ANSI 拥有）委员会，或者在委员会中找人来推动您的提案。

【讨论】：

感谢您的提问。我知道我的“建议”很小，迂腐，次要，......但我不是要月亮。也许我错了，但连贯性和一致性比我要求的“添加”更重要。
你在求月亮。正如 Jalf 指出的那样，您要求的新关键字不会增加任何新的表现力。顺便说一句，理查德的回答是死的。我以前在标准讨论中被击落过。这不是致命的。
我完全同意你（所有人）的观点：“表达能力没有改变”=>“为什么要改变，可能会破坏现有的东西？”。您可以将我的“建议”视为 pure (LOL) 美学。我只是想避免这种情况： ... = delete; ... = 默认值； ... = 0;如果我的“提案”读作“你要月亮”，我会谦虚地退休（真的很抱歉 - 不是在开玩笑）。谢谢！ :)

【解决方案4】：

为时已晚。请求征集于几年前结束。

（有一个页面保存了提交，但我再也找不到那个列表了。）

【讨论】：

好的，我会再试一次，稍后...谢谢。
不要感觉太糟糕 - 其他人最初是这样建议的。我的建议是：弃用 int、short 等，并用 int8、int16 等替换。还弃用 char 和新类型的字形，这将是代表 unicode 字符的模板类。
我相信 C99 类型（如 int16_t）已被标准接受，但作为 typedef，您可以通过包含头文件来获得。委员会非常不愿意引入新的关键字，但可选的 typedef 不太可能给任何人带来不便。
是的，但我对 64 位类型的极其乏味的“long long”感到恼火。当我们达到 128 位时会发生什么？ '长长长'？通过在类型本身中定义数据类型的大小，您不会得到我们现在拥有的这种愚蠢的类型 a '>= type b'，并且很明显您正在使用什么，并且使移植代码更容易。

【解决方案5】：

除了jalf关于添加关键字的缺点的评论（我 100% 同意），您还应该注意，在计算机科学中，短语 pure function 已经有一个意义。这意味着给定相同的参数，函数总是返回相同的值并且没有副作用。因此，选择= pure 来指示必须重写的虚函数将是一个糟糕的语法选择。

【讨论】：