Cppreference 讨论：常见问题解答

语法：要么/或者

这句话“注意，但是，您不需要了解复杂的模板，也不需要了解上述指南，就可以做出贡献”应该改为“注意，但是，您不需要了解复杂的模板，或者上述指南，就可以做出贡献”。

-P

已修复，感谢！ --P12 2015年8月7日 19:32 (PDT)

这还没有修复；它仍然是“neither”，而不是“nor”。 Nwn (talk) 2018年4月13日 11:49 (PDT)

TR1？

我们是否应该包含有关 TR1 的信息？ -- Jaredgrubb 2011年7月2日 07:41 (PDT)

已修复。P12 2011年7月2日 12:34 (PDT)

TR1（当然现在已经过时了）和 TR2（距离完成还很远，但微软已经部分支持了 (#include <filesystem>)）都没有在当前页面中提到。 --Cubbi 2012年4月30日 08:50 (PDT)

2011 C++ 标准

ISO/IEC 14882:2011 现已发布。此页面不应该谈论草案。 Jonathan de Boyne Pollard 2012年3月24日 02:27 (PDT)

• 链接的草案是最新的公开可下载草案 --Bazzy 2012年3月24日 02:51 (PDT)
  • 这完全是胡说八道。除了它根本不是最新的草案，而是比实际的最新草案晚了一年多，获取非草案标准副本的地址之一就在上面。 Jonathan de Boyne Pollard 2012年3月25日 07:11 (PDT)

我们不能指望所有编辑都有一份实际的标准，因为它不是免费提供的。除此之外，常见问题解答肯定过时了，感谢你指出这一点。 -- P12 2012年3月25日 08:04 (PDT)

我们应该添加 C++11 的 ANSI Store 购买链接，它比当前链接的 ISO Store 便宜 10 倍：http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS%2FISO%2FIEC+14882-2012 --Cubbi 2012年7月25日 07:49 (PDT)

好主意 -- 已完成。 --Nate 2012年7月25日 13:07 (PDT)

C 参考

此页面应该更新以提及该站点的新的 C 参考部分。 --- Undeterminant 2012年4月22日 10:34 (PDT)

已更新。谢谢。 -- P12 2012年4月22日 10:52 (PDT)

也可以给出 C11 ANSI Store（我似乎无法编辑此页面）。 --Cubbi 2012年9月24日 12:08 (PDT)

我已经稍微放宽了此页面的权限；你现在应该能够编辑它，@cubbi。（@p12：如果这是有意为之，我们可以恢复到管理员专有的写入权限，用于常见问题解答 -- 我假设此页面具有与例如首页相同的保护措施。） Nate 2012年9月24日 15:57 (PDT)

确实没有理由让此页面只能由管理员编辑。 -- P12 2012年9月25日 05:03 (PDT)

失效链接

到 C++20 工作草案的链接应该替换为指向 n4868 的链接 https://isocpp.org/files/papers/N4868.pdf

有关此网站上失效链接的信息可以在下面报告

到 C17 草案 PDF 的链接已经失效一段时间了。该 PDF 仍然可以通过 archive.org 获取，所以也许可以将链接更改为此？ https://web.archive.org/web/20180118051003/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

页面 https://cppreference.cn/w/cpp/error/terminate 上有两个链接“std::terminate_handler”，它们指向的是 https://cppreference.cn/w/cpp/error/terminated_handler，而不是 https://cppreference.cn/w/cpp/error/terminate_handler

谢谢；看起来是我们语法高亮程序中的一个打字错误，现在已经修复了：https://github.com/p12tic/cppreference-doc/commit/bcb0271a87519c44b522563ddee7dccfd7c6830b。下次刷新时，该页面应该会修复。 -Nate 2012年10月31日 11:25 (PDT)

书籍版本在某些页面上缺少指向 CSS 的工作链接，例如 std::search_n。 --91.96.47.34 2014年6月4日 12:06 (PDT)

这并不完全是一个失效链接，但 URL “https://cppreference.cn/w/cpp/language/implicit_cast”具有误导性。没有所谓的“隐式转换”；转换是一个*显式*转换。该页面本身正确地提到了“隐式转换”。我建议将该页面重命名为“implicit_conversion”，并将“implicit_cast”链接到它。（删除现有 URL 会导致问题。） Keith Thompson (talk) 2016年4月1日 09:03 (PDT)

是的，实际上该页面的内容与 URL 不匹配。.. 重命名后保留重定向，谢谢。 --Cubbi (talk) 2016年4月1日 12:45 (PDT)

这并不是一个失效链接，而是一个不存在的链接。自动链接器似乎没有“std::scoped_lock”的条目，因此大多数对它的引用都没有链接。例如：https://cppreference.cn/w/cpp/thread/mutex#Notes Nwn (talk) 2018年4月13日 12:00 (PDT)

此处两种语言的 NULL 链接相同 https://cppreference.cn/mwiki/index.php?title=Special%3ASearch&search=null&button=。C 语言的 NULL 应该引用 https://cppreference.cn/w/c/types/NULL，而不是 https://cppreference.cn/w/cpp/types/NULL。

这似乎在一段时间前就已修复。至少目前，搜索页面的链接看起来很正常。 --178.162.222.163 2020年6月28日 01:04 (PDT)

同样也不是真正的失效链接，更像是缺少链接。 free() 试图链接到 aligned_alloc()，但失败了。我调试了一下，发现{{rlp|aligned_alloc|aligned_alloc}} 似乎可以工作。那里采用的链接机制是{{lc|...}} 模板，根据其 文档，它使用的是自动链接技术，但 C 自动链接器定义 页面似乎缺少 aligned_alloc() 之类的内容。我确信在其中添加它会使链接正常工作，但有许多障碍

• 该页面受保护，因此我无法更改它
• 我不知道它是手动维护的还是以编程方式维护的
  • 以编程方式维护意味着任何更改都将毫无用处，直到生成器或输入数据被修复。

此外，这可能只是缺少链接的一个具体实例，可能还有更多 C11 函数没有被正确地... 嗯... 索引。

有人愿意帮忙解决吗？ -- 217.92.117.31 2020年6月27日 07:06 (PDT)

cpplang slack 频道返回了 404 错误。在 https://cppreference.cn/w/Cppreference:EditingHelp 上找到。

有些东西会偶尔生成无效的链接。例如，https://cppreference.cn/w/cpp/ranges#Helper_concepts。对于 ranges::iterator_t 的链接指向 <a href="https://cppreference.cn/w/cpp/ranges-ranges-placeholder/iterator_t">。请注意，这是在原始 HTML 中。如果用鼠标悬停在链接上，JS 会修复它。如果您查看源代码，您可以看到错误的链接，包括路径和使用普通 http。当然，这会破坏像 wget 和 lynx 这样的非 JS 浏览器。 Nexushoratio (讨论) 2023 年 7 月 11 日 16:22 (PDT)

据我所知，这是从早期概念提案中使用的 PascalNames 过渡到 standard_case 名称所需的变通方法的结果。--太空任务 (讨论) 2023 年 7 月 12 日 11:13 (PDT)

cppreference.com/store 链接似乎已损坏。

CSS

应该删除整个页面的限制宽度和最大宽度。我在最新的 HTML-Book-Version 中的 common/loadfe52.css 和 common/load7fe1.css 文件中找到了 3 个。删除它们后，页面看起来好多了。我几个月前下载的离线版本也有同样的“错误”。80.147.4.22 2014 年 6 月 4 日 02:49 (PDT)

您是否担心 HTML-book-version 或实时网站（或两者）的宽度设置？--Nate (讨论) 2014 年 6 月 4 日 06:53 (PDT)

所有 3 个版本，book、Raw 和 live，都有固定宽度的文本主体（并且居中）。至少非 book 版本应该具有 W3 推荐的可变宽度，我认为。为什么毫无理由地破坏 HTML 最合理的特性之一？--91.97.19.47 2014 年 6 月 4 日 11:45 (PDT)

除英语之外的其他语言的 css Mediawiki:Common.css 未更新。请您将它们同步到英语版本吗？Hiroo (讨论) 2015 年 5 月 26 日 00:09 (PDT)

https://cppreference.cn/w/cpp/atomic/ATOMIC_FLAG_INIT 存在问题，它无法正确渲染。

Boost 文档？

根据常见问题解答

一些 Boost 库也可能是包含的候选者，尽管它们的教程很好，但参考文档通常非常不灵活且不方便。

我也有同感，我和每个谈论过 Boost 的 C++ 程序员似乎都有同样的想法。我真的认为在 cppreference.com 上包含流行的 Boost 库将对社区非常有用。

我们是否可以就这个问题达成共识？我知道这意味着该 wiki 的范围会发生变化，这会引发有关此处是否记录其他外部库的问题。从 OOD 的角度来看，我看到了将该网站的范围限制在纯语言标准的优雅之处，因此也许这是一个为新的开源库参考 wiki 寻求解决方案的案例？

EFNet 上的 CStubing 2012 年 12 月 31 日 10:55 (PST)

就我个人而言，我发现它们的教程与文档相比有所欠缺，但我已经使用 Boost 多年了，所以我想我已经习惯了。我同意像我们为标准 C++ 组件提供的简单示例那样有用（使用 Boost.GIL 创建一个小的填充洪水的 .PNG 文件只需两行代码，但没有教程展示如何做到。人们看到关于通用算法的大量文本，然后转向其他库）。不过，标准 C++ 库中仍然有很多红链接。--Cubbi 2012 年 12 月 31 日 11:29 (PST)

我喜欢这个想法。我怀疑让 Boost 进入 cppreference.com 所缺少的部分是找到一个人来领导最初的推动，以确定 Boost 文档的整体结构。我认为三个主要问题是

• Boost 很大：我对此没有确切的数字，但根据 boost_1_52 和 libstdc++-v3 的来源，我认为 Boost 可能比 libstdc++ 大 2-3 倍。这需要涵盖大量内容。
• Boost 的发布频率更高：我对我们处理现有 wiki 版本的方式并不完全满意，我们目前遇到的任何涉及多个版本的问题都将在 Boost 上被放大。
• Boost 是有版权的（？）：我们必须检查任何可能的许可问题，尤其是在我们有兴趣导入任何现有 Boost 教程或参考材料的情况下。

如果我们能找到这些问题的满意答案，我认为我们可以开始构建类似于 /w/c 和 /w/cpp 的 Boost 部分。--Nate 2013 年 1 月 1 日 11:22 (PST)

一些想法

1) IMO，在可预见的未来，除非有大量新的贡献者，否则几乎不可能涵盖所有 Boost 库。一个可能的解决方案是允许所有贡献，但只在文档真正有用时（即充分记录大多数流行的功能等）才在主页上显示这些库。

2) 这个问题很难解决。另一个问题是，Boost 在很多情况下不向后兼容。一些库已经过重大改版，几乎不可能在不完全分离每个库版本的文档的情况下对其进行记录。

3) 大多数文档是在 Boost 软件许可下分发的，这是一个类似 BSD 的许可 - 如果我们在某个地方包含版权文本，我们可以做任何我们想做的事。每个库的主页上的一条注释就足够了。

P12 2013 年 1 月 2 日 09:50 (PST)

过于严格的介绍

我认为常见问题解答中的以下文本过于严格。

不幸的是，这意味着成为一个好的教育资源并不在我们目标之内。假设读者对 C 和/或 C++ 有很好的了解。因此，许多内容（例如教程、关于某个功能的使用案例的评论、对经验丰富的程序员隐含清楚的事物的详细解释等）未被包含，也不应被添加。基本上，我们试图让程序员在寻找他已知的某个功能的参考时，保持事物简单明了。

几年前我写这段话时，是想阻止在旧的基于 Dokuwiki 的 cppreference.com 网站的某些页面中出现的混乱。现在似乎不太可能发生这种情况，因此我已经 放宽 了上述指南。 P12 2013 年 1 月 2 日 10:17 (PST)

看起来很不错。--Nate 2013 年 1 月 2 日 17:45 (PST)

对 c++ 标准的引用

我认为，也许有时添加指向 c++ 标准 ISO/IEC 14882 的链接是个好主意？例如这样：8.3.6 默认参数 (1-2,4) 或这样 [dcl.fct.default](1-2,4)。 Ruslo 2013 年 8 月 19 日 00:09 (PDT)

这可能是有用的一点信息。我们可以列出特定页面信息来源的标准的所有部分。例如，它可以放在参考文献部分

参考文献

• C++11 标准 (ISO/IEC 14882:2011)：8.3.6 默认参数 [dcl.fct.default] (第 1-2、4 页)

或（假设的）

参考文献

• C++11 标准 (ISO/IEC 14882:2011)

• 8.3.5 函数 [dcl.fct]
• 8.3.6 默认参数 [dcl.fct.default] (第 1-2、4 页)

• C++98 标准 (ISO/IEC 14882:1998)

• 8.3.5 函数 [dcl.fct]
• 8.3.6 默认参数 [dcl.fct.default] (第 1-2、4 页)

为了格式一致，我们可以选择使用模板，例如

===References===
{{ref std c++11}}
{{ref std | section=8.3.5 | title=Functions | id=dcl.fct}}
{{ref std | section=8.3.6 | title=Default arguments | id=dcl.fct.default | p=1-2,4}}
{{ref std c++98}}
...

请注意，在所有页面上添加此信息需要大量工作，因此我不确定这项工作是否值得继续，除非有志愿者愿意花一些时间将此信息添加到 wiki 的主要部分（例如，总共 3000 页中的 1000 页，这需要大约 10-15 小时）。 P12 2013 年 8 月 19 日 05:56 (PDT)

是的，我同意。这需要大量工作，但我认为这不是主要目标。就像示例 - 如果您认为可以改进，就尝试一下并保存它（为他人和自己）。目标不是为了避免一些链接搜索工作。 Ruslo 2013 年 8 月 19 日 07:10 (PDT)

第二个版本看起来非常不错，并且解决了版本控制问题。 Ruslo 2013 年 8 月 19 日 07:10 (PDT)

还有其他意见吗？ P12 2013 年 8 月 19 日 05:56 (PDT)

我认为参考文献 (和 </references>) 部分是一件好事。作为一名以前活跃的维基百科编辑，我甚至喜欢看到使用适当的引用模板（例如 http://en.wikipedia.org/wiki/Category:Citation_Style_1_templates）。确实，遍历所有（甚至是最流行的 1000 个）现有页面会很无聊，但如果有一种标准的方法，我个人会在编辑页面时添加参考文献部分。--Cubbi 2013 年 8 月 19 日 06:24 (PDT)

我喜欢它，假设

• ...创建 ref 模板的工作量不会太大。
• ...它位于页面底部，因为 (a) 参考文献通常位于那里，(b) 网站的普通用户可能更感兴趣的是 API 和示例。
• ...我们可以想出一种不那么复杂的方式来指定参考文献。我喜欢上面提出的 ref 模板。Cubbi，您能举一个“适当的引用模板”的例子吗？--Nate 2013 年 8 月 19 日 07:41 (PDT)

我的意思是像 {{cite ISO|number=14882|year=2011|title=|sectionname= |section=|paragraph=}}，它可以与引用的其他标准文档一起使用：ISO 9599、10646、10967、60559、Ecma 262，然后可以使用 <ref> 标记将其包装起来，以标记特定的句子并在 </references> 中弹出（这里已经支持）。--Cubbi 2013 年 8 月 19 日 08:27 (PDT)

那么 {{ref}} 模板可以生成基于 <ref> 的输出，可以使用 </references> 在参考文献部分显示？您认为 Mediawiki 的内置参考文献功能是否允许我们选择显示 C++98、C++11 等的参考文献？（最终，能够使用基于 JavaScript 的下拉菜单来选择特定页面显示的标准版本会很不错。）--Nate 2013 年 8 月 19 日 13:22 (PDT)

即使使用 <ref> 这样的系统，也可以选择性地显示和重新编号参考文献。但是，我更倾向于简单的文本/模板方法——这样只有页面末尾的 来源 会包含参考文献定义，主文本不会被弄乱。这对模板页面尤其有用，因为例如 Template:cpp/container/insert 需要使用 {{#switch: 并针对不同的容器描述标准的不同部分。另外，我们不是维基百科，在每个句子或段落附近放置引用可能不太有用——这里的大多数页面都很短，描述的是一个非常具体的主题，因此通常很明显哪个引用对应哪个段落。当然，C 和 C++ 语言的描述（cpp/language/*）除外——<ref> 在这里很有用。

顺便说一下，{{cite ISO|number=14882|year=2011|title=|sectionname= |section=|paragraph=}} 可以简化为 {{cite std c++11|title=|sectionname=|section=|paragraph=}}，因为很难记住确切的 ISO 标准编号。可以将适当的模板用于其他引用。

P12 2013年8月20日 (PDT) 06:11

好的，经过更多思考，我同意维基百科的大多数页面都只有一个来源（版本将来可能会成为用户偏好/选项卡），因此通用维基百科方法不适合。--Cubbi 2013年8月20日 (PDT) 07:01

FYI 我已经为参考文献部分创建了模板。文档在 这里。--P12 2013年9月23日 (PDT) 12:28

Coliru 编辑器中的错误

似乎存在一个错误，如果我输入宏定义，例如

运行此代码

#define size mysize

几秒钟后，编译器会将其更改为

运行此代码

# Define  you in mysiz

我只发现当我在宏名称中输入 size 并使用上面这样的 6 个字母的字母定义时，才会出现这种情况。自己尝试一下，你就会看到。

我不确定如何重现这种情况。当我运行你的第一个示例时，我只得到一堆链接器错误，抱怨缺少主函数——但 #define 保持不变。当我添加一个 main 时，它编译并运行，没有修改 main。你是否在特定编译器下观察到这种行为？--Nate (讨论) 2014年4月14日 (PDT) 06:48

此参考文献遵循哪个版本的 C 标准？

由于你在 FAQ 中要求标明 C89、C99 和 C11 之间的差异，是否值得提及 n1256 描述的是 C99，而 n???? 描述的是 C89？Newatthis (讨论) 2014年7月15日 (PDT) 11:55

值得一提的是，n1256 是 可免费获取的 ISO/IEC 9899:1999/Cor.3:2007(E) 的最终草案，这是 C99 的最后一次修订（请参阅 C 的历史，了解 C 的主要和次要修订列表）。C89 的最终草案是 X3J11/90-013（ANSI 编号）或 n119（WG14 编号），尽管我不确定是否可以免费获得它。--Cubbi (讨论) 2014年7月15日 (PDT) 16:18

我在 n1256 中插入了一个链接，并包含了 C89 的文档编号。在 iso.org 上，我发现 ISO/IEC 9899 条目在已撤回文档中列出。Newatthis (讨论) 2014年7月16日 (PDT) 07:17

C11 标准的最新草案是 N1570。ansi.c.txt 是 1989 年 ANSI C 标准的纯文本草案；1990 年 ISO C 标准与 ANSI C 的唯一区别在于添加了一些模板材料和对部分章节的重新编号。Keith Thompson (讨论) 2016年4月1日 (PDT) 08:57

没错，此页面链接到 n1570 用于 C11 (自 2012 年起)。至于那个特定的 ansi.c.txt，它与已发布的标准在 tm 中的 tm_sec 的最大秒数上有所不同（草案说 61，标准说 62，错误）。还有其他区别吗？--Cubbi (讨论) 2016年4月1日 (PDT) 12:42

转换构造函数

请为转换构造函数创建一个页面

感谢你大胆地自己创建了它。--Cubbi (讨论) 2014年9月22日 (PDT) 16:35

搜索是否应在完全匹配时重定向？

我不确定应该将此内容发布在哪里，但如果例如 https://cppreference.cn/mwiki/index.php?title=Special:Search&search=std::basic_string 重定向到其完全匹配项 https://cppreference.cn/w/cpp/string/basic_string 会很酷。希望这个想法还没有被否决，如果真是这样，我很抱歉。最好的，Nick

拼写错误

页面上有一个拼写错误：“not publicly availbale”。

确实有，已经更正了。--Cubbi (讨论) 2016年9月14日 (PDT) 06:58

std::lower_bound 描述语义 - 错误？

在 lower_bound 的描述页面上，它写道

返回一个指向范围 [first, last) 中第一个不小于（即大于或等于）value 的元素的迭代器。

我一直假设 '[...)' 括号形式表示一个包含/排除的 区间，这意味着例如 end() 绝不可能作为返回值。但是，稍后页面上写道

指向第一个不小于 value 的元素的迭代器，如果找不到这样的元素，则返回 last。

虽然可以声称，简要概述如果没有页面的其余部分则毫无意义，但我想修改简要陈述，以包括如果找不到这样的元素，last 会被返回的事实。

但是，我不想在征求意见之前进行编辑。感谢你的时间！

Ringobelingo (讨论) 2017年6月2日 (PDT) 08:10

这个讨论更适合在 Talk:cpp/algorithm/lower_bound 上进行。last 的副本用作错误代码，但它不是 std::lower_bound（以及所有标准算法）所操作的范围的一部分：由迭代器对表示的范围始终是 [first,last)，不包含 last。语义上没有错误，但存在遗漏：它没有说明如果不存在这样的元素会发生什么。我想可以将其添加为第二句话（“如果找不到这样的元素，则返回 last。”）。---Cubbi (讨论) 2017年6月2日 (PDT) 09:19

同意。感谢 Cubbi。我将声称是初次发言紧张 :) --Ringobelingo (讨论) 2017年6月2日 (PDT) 11:44

编译器示例无法运行

我本来想在 distance 中测试一个示例，但它只是在输出中显示了“正在构建和运行…”。这并非普遍现象（一些示例有效，而另一些则无效），因此在维基百科和 Coliru 在线编译器之间的链接中一定存在部分损坏的地方。请有人帮忙看一下吗？谢谢。

Adrian 2018年6月5日 (EDT) 11:13

Coliru 不支持 HTTPS，因此如果你通过 HTTPS 访问 cppreference，它将无法运行。T. Canens (讨论) 2018年6月5日 (PDT) 09:02

我已经联系了 Coliru 的人员，他们将尽快尝试启用 HTTPS 支持。--Nate (讨论) 2018年6月28日 (PDT) 07:59

一点编辑建议

我建议更改以下段落

查看以下链接集合 [1] [2]，以获取其他链接和不属于本网站范围内的资料。

更改为以下文本

查看 C 链接 和 C++ 链接 集合，以获取其他链接和不属于本网站范围内的资料。

更简洁、更清晰。- 37.113.168.36 2018年9月10日 (PDT) 21:20

非静态成员函数上的 const

应该将https://cppreference.cn/w/cpp/keyword/const链接到https://cppreference.cn/w/cpp/language/member_functions#const-.2C_volatile-.2C_and_ref-qualified_member_functions ? 2A0B:F4C1:0:0:0:0:0:6 15:28, 15 September 2018 (PDT)

当然，已完成。--Cubbi (讨论) 18:49, 15 September 2018 (PDT)

站点搜索

不知道该在哪里报告这个问题：在这个网站上搜索“is_rvalue”不会提出“is_rvalue_reference”。它显示“没有找到与查询匹配的结果”。搜索“minma”会提出很多部分匹配，例如“minmax”。-- Valiko (讨论) 12:58, 7 January 2020 (PST)

同样适用于“bind_front”，它不会产生任何匹配项。

同样适用于“midpoint”和“std::midpoint”。两者都没有找到，而std::midpoint应该已经被返回。有人知道这个搜索索引是在什么时候/如何构建的吗？ elbarto (讨论) 12:37, 8 July 2020 (PDT)

根据Special:Version，站点上的搜索使用 P12 本人编写的自定义 MediaWiki 插件。它的源代码位于 github 仓库中，p12tic/CppSearch - 更改任何代码的最后一个提交是在 2014 年。

根据自述文件...

该引擎非常简单 - 它根本不分析维基的内容。相反，它从 MediaWiki: 命名空间中的一个或多个特殊文件中获取搜索关键字列表，并且仅将搜索查询与该列表中的条目进行匹配。

我的一部分认为这种方法可能在 2012 年有效，但质疑它在今天的可持续性。不过，这就是工作方式。

对于 C++，该特殊文件是MediaWiki:Cpp-search-list-cpp。当然，这里提出的项目在搜索中没有出现的原因是，它们都不在列表中。（添加operator<<也是。有人在 2017 年在 github 仓库中唯一打开的问题中提到了这一点。）-- FeRDNYC (讨论) 07:35, 6 January 2021 (PST)

特别是operator<<的情况实际上很有趣，因为大多数这些都在列表中。搜索问题似乎归结为

1. 搜索只显示第一页匹配项，无论有多少。因此，仅仅搜索“operator”会误导性地让人觉得operator<<条目很少 - 实际上有很多，只是它们在结果中的位置更靠后。但是，我找不到任何方法可以将搜索范围缩小到超出“operator”的范围，同时仍然匹配“operator<<”。
2. 你不能搜索字面字符串“operator<<'，因为“<'是一个特殊字符，在 URL 和查询等内容中是被禁止的。（这也是为什么操作符页面有像operator_ltlt2这样的名称，以及为什么我在此小心地输入“operator&lt;&lt;'。网站上的一些模板会对特殊字符进行转义，这就是为什么该页面的代码可以以一个字面意义上的{{title|operator<<}}开头，但是如果没有模板参与，那么其他东西就必须进行转义。对于搜索来说，要么是坏了，要么就从未实现过。
3. 因为Cpp-search-list-cpp中的字符串是未转义的，你不能搜索诸如“operator_ltlt”或“operator lt”之类的字符串 - 你只会得到很多像std::atomic<T>::operator T这样的匹配。

-- FeRDNYC (讨论) 08:08, 6 January 2021 (PST)

感谢 FeRDNYC 的回复和你的研究。

-- Valiko (讨论) 12:10, 6 January 2021 (PST)

我到这里来报告关于搜索“midpoint”的问题（如上所述，已经由elbarto报告）。没有特殊字符，那么是什么阻止了它被添加到搜索列表页面？我会自己做，但该页面上没有编辑按钮。 Tomerv (讨论) 10:28, 14 September 2022 (PDT)

mediawiki 搜索由于维护负担而被放弃，并且已经有一段时间了。替代的 duckduckgo 搜索可以很好地找到 midpoint --Ybab321 (讨论) 14:27, 14 September 2022 (PDT)

我同意 duckduckgo 搜索效果很好，但另一方面，DDG 的 bang 功能实际上使用了 mediawiki 搜索。因此，如果我进入 duckduckgo.com 并搜索“!cpp midpoint”，我就会被重定向到[1]。也许有人需要要求 DDG 更改“!cpp”bang 的工作方式？ Tomerv (讨论) 23:02, 6 October 2022 (PDT)

Benio 的问题

嗨，我每天都在家里和工作中使用 cppreference，并且加入是为了贡献自己的力量。我相信我有足够的经验，可以让我在贡献中带来更多益处而不是损失。但是，我在页面之间发现了一些不一致，我想在继续之前澄清一下。

{{mark}} 注释

当前做法

• 属性说明符序列 (自 C++11 起)
  • ✅ 标题用“(自 C++11 起)”标记
  • ✅ 语法条目“[[ attribute-list ]]”用“(自 C++11 起)”标记
• alignof 运算符 (自 C++11 起)
  • ✅ 标题用“(自 C++11 起)”标记
  • ❌ 语法条目没有用“(自 C++11 起)”标记
• 移动赋值运算符 (自 C++11 起)
  • ❌ 标题没有用“(自 C++11 起)”标记
  • ✅ 所有语法条目都用“(自 C++11 起)”标记

期望约定

那么约定是什么呢？例如，如果我们有一个关于(C++11)特性的页面，我们应该

• 标记标题和所有(C++11)特性
• 标记标题，不标记任何(C++11)特性
• 不标记标题，标记所有(C++11)特性

说明模式

当前做法

为了提高可读性，只考虑“example”、“keywords”和“notes”部分。

• alignas 说明符 (自 C++11 起)
  • "notes" → "keywords" → "example"

注意：此↑顺序更可取。--Space Mission (讨论) 11:30, 14 September 2022 (PDT)

• alignof 运算符 (自 C++11 起)
  • "keywords" → "notes" → "example"

注意：更新为上面项目中显示的顺序。） --Space Mission (讨论) 11:30, 14 September 2022 (PDT)

• 替代运算符表示
  • "notes" → "example" → "keywords"

注意：此↑页面太复杂，无法遵循简单的模式“notes”→“keywords”→“example”。 --Space Mission (讨论) 11:30, 14 September 2022 (PDT)

期望约定

该 样式手册提供了不完整的说明模式，并且只涵盖了 类和 函数 。

• 对于 样式手册中缺少的部分，期望的说明模式是什么？
• 对于其他页面，期望的说明模式是什么？

{{langlinks}}

• 我应该什么时候使用{{langlinks}}？
• 我应该在{{langlinks}}中包含哪些语言？

在{{mark}}和{{cmark}}注释之前使用空格

• 我应该什么时候在{{mark}}和{{cmark}}注释之前加上空格？

— Benio (讨论) 2022年1月11日 20:31:19‎ (UTC)

这些细节中的大部分都是活跃编辑之间非正式的隐性协议，而且在完善格式之前，总有成千上万的事情要做来改进内容。这优先级很低。非正式地说，我认为这种推理适用（主要是在评论中宣传小工具）

• 关于版本标记，当用于列表条目时，它们的（弱实现）目标是支持版本选择（您是否启用了 StandardRevisions？），这样列表项就可以根据标准修订下拉选项卡中的选择显示和消失。当/如果它有效，描述以 C++11 开始，每行都标记为 C++11 的内容页面会在选择 C++98/C++03 时尴尬地显示一个空列表，然后是其他内容；我认为标题标记足以设置页面的基线，正文/列表应该只标记后来发生的更改。
• "关键字"在章节顺序中的位置确实从未确定过。它链接到页面上描述的关键字的其他用途，因此它充当导航的一部分，就像一个专门的“另请参见”一样——因此我将其放在“另请参见”之前。
• 语言链接只有在链接到手工翻译时才有用，也就是翻译人员倾向于更新翻译的时候。
• 标记前的空格？我不知道它们会起作用。--Cubbi (讨论) 2022年1月11日 14:29 (PST)

谢谢！我不知道这个小工具。我一定会启用它。— Benio (讨论) 2022年1月11日 22:57:46 (UTC)

<assert.h> 和 <errno.h> 指向同一个链接

您好，

assert.h 和 errno.h 的链接在这个页面上指向同一个链接

https://cppreference.cn/w/c/header

是否应该为 assert.h 头文件创建一个单独的页面？

链接的页面涵盖了这两个头文件，没有问题。--Ybab321 (讨论) 2022年11月18日 02:11 (PST)

我的梦想是在 cppreference 的“C”部分为所有标准 C 头文件创建带有概要的单独页面，就像已经为所有 C++ 头文件页面 完成的那样。当然，如果这对 C 来说是相关的。并且是可取的。但只有在所有主要的 C++23/C23 部分都添加到这里之后。--Space Mission (讨论) 2022年11月19日 12:40 (PST)

提案参考

您如何看待在某些库实体的“参考”块中添加提案链接？从库用户的角度来看，它们主要是因为它们的“动机”部分而有用。例如，在 C++ Weekly - 第 374 集 中，Jason 抱怨 out_ptr 页面 难以理解。在那里直接引用 https://wg21.link/p1132 比手动创建激励示例更容易。

我一点也不反对，这可以通过编译器支持页面来完成。但是，说实话，论文中提出的动机通常很弱，我宁愿把添加这些引用的工作花在编写示例或改进页面上，甚至只是在讨论页面上添加一个要点。--Ybab321 (讨论) 2023年5月3日 10:17 (PDT)

最新 C++20 草案标准

N4860 被认为是 C++20 的最终工作草案，直到 2021 年 6 月进行了以下编辑

https://cppreference.cn/mwiki/index.php?title=Cppreference:FAQ&diff=130272&oldid=127712

FAQ 现在指出 N4861 是最新的工作草案。没有任何来源在任何时候被引用为最新的 C++20 草案 - 能够有人给出理由，为什么这些中的任何一个都应该被认为是最新的 C++20 草案（以及为什么 N4861 应该或不应该被认为是第一个 C++23 工作草案？）请提供可引用的来源！ Ajm 80386 (讨论) 2023年9月22日 08:05 (PDT)

我研究过这个问题。根据 N4859 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4859.html)，N4860 被认为是 C++20 的最终草案，N4861 被认为是 C++23 的第一个工作草案。但这几乎是一个无关紧要的问题，因为来源指出

> N4860 和 N4861 的内容除了封面、页眉和页脚外完全相同，此外，N4861 不包含来自 ISO C++ 2017 的交叉引用索引。 Ajm 80386 (讨论) 2023年9月22日 09:13 (PDT)

哦，这很有用，谢谢。这确实令人费解，因为官方的页数

• 在 N4860 中是 1829 页，
• 在 N4861 中是 1826 页。

页面 FAQ: C++ 标准 已经更新。--Space Mission (讨论) 2023年9月22日 10:19 (PDT)

创建页面

用户可以自行创建页面吗？ Studyingegret (讨论) 2024年7月16日 02:12 (PDT)

当然可以，请放心，我们这里有些人会编辑页面以符合网站风格（即“fmt”页面）。用户经常会在他们的用户命名空间中创建页面，然后将它们移动到主站内容中，如果您觉得这样做更好。--Ybab321 (讨论) 2024年7月16日 02:17 (PDT)

那么我该如何创建页面？如何在我的用户命名空间中创建页面？ Studyingegret (讨论) 2024年7月16日 02:51 (PDT)

您只需访问您想要页面所在的 URL，例如 https://cppreference.cn/w/User:Studyingegret/Format，您将被提供“编辑此页面”的选项，或者单击右上角的“创建”--Ybab321 (讨论) 2024年7月16日 05:38 (PDT)

我知道了，谢谢。 Studyingegret (讨论) 2024年7月16日 17:46 (PDT)

指南类内容

您如何看待编写“指南类内容”？我的意思是直接告诉您“就这样做/使用它”的文本，就像教程一样，而不是像普通参考那样中立地列出事物。例如，我的页面 上的“常用用法”部分。

我没有看到这个问题在 风格指南 上有解答，而且我觉得很多页面尽可能地避免了这种“指南类内容”，只在提到一些非常微妙的事情时才会写它。所以当我想到在这样的页面上添加这种内容时，我就会过度思考“指南类内容”是否不合适。但我认为“指南类内容”对于解释不直观的事情很有用，而且有些文档有很多这样的内容，例如 Python argparse（建议阅读教程） 和 Rust std::collections。

那么，在多大程度上接受“指南类内容”？ Studyingegret (讨论) 2024年7月29日 00:12 (PDT)

抱歉，我错过了 FAQ 中的第一个问题，但我仍然想知道什么时候这种文本更可取 Studyingegret (讨论) 2024年7月29日 00:40 (PDT)

我个人宁愿我们大部分时间都保持纯粹的参考网站。指南/教程往往比仅仅解释标准或关于编译器的说明更具主观性（甚至“核心”指南有时也相当可疑，而且这是我迄今为止见过的质量最高的指南集）。教程值得单独的专用处理，比如市面上众多的 C++ 书籍或 learncpp.com。--Ybab321 (讨论) 2024年7月29日 04:28 (PDT)

同意，我宁愿看到指向优秀指南/教程的链接，我们对协程等特定主题以及通用链接页面都有。我认为一种合适的指导是记录语言和库功能的意图/动机。提案中有这些内容，但是当它们被合并时，动机部分就会丢失。我认为这些内容既有用（有时是必要的）来理解该功能，而且它们已经过同行评审。--Cubbi (讨论) 2024年7月29日 06:51 (PDT)