问题标签 [c++23]

P0847提出了this对成员函数使用显式参数的可能性。

在这个提议带来的其他好处中，没有 C、R 甚至 T 的 CRTP也有很大的新可能性。

在 C++中实现泛型的一种常见做法clone是基于 CRTP，例如，请参阅此 SO 帖子。

鉴于我们需要clone（virtual或至少，表现为虚拟），以允许：

并且鉴于提议是不应声明具有显式 this 参数的成员函数virtual。

是否还有一种方法可以使用 P0847 来实现具有动态行为且没有 CRTP的通用克隆？

P1787对同一实体有很好的描述。

两个实体声明声明同一个实体，如果考虑到未命名类型的声明以引入它们的名称以用于链接目的，如果有的话（[dcl.typedef]，[dcl.enum]），它们对应（[basic.scope.scope]） , 具有相同的目标范围，不是函数或模板参数范围，并且要么

1. 它们出现在同一个翻译单元中，或者
2. 它们都使用模块链接声明名称并附加到同一个模块，或者
3. 它们都声明具有外部链接的名称。

所以，考虑这个例子：

除了注释说：

[注：具有外部或模块链接的内联函数或变量可以在多个翻译单元（[basic.def.odr]）中定义，但是一个具有一个地址的实体。因此，在此类函数的主体中定义的类型或变量是单个实体。--结束注释]

但是，让我们考虑value声明的 at #1。在b's TU 和c's TU 中，这两个 for 的声明value是对应的，它们具有相同的由 的复合语句引入的目标范围function。但是，局部变量没有任何链接，因此不会满足该列表中的任何项目符号。那么，为什么value在不同的两个翻译单元中（在函数体中）的两个声明声明了同一个实体？如何通过 P1787 中的规则来解释？

有一个关于静态反射的 C++ 技术规范（当前PDF 草案和cppreference 页面）可能会进入 C++23 或更高版本。

在当前草案中（我理解语法可能还没有固定）是否有可能通过名称访问结构字段/调用类成员函数？

例如

这可能吗？如果是的话，怎么办？

编辑：当我查看 TS草案时，我发现大多数函数都被命名为 'get_XX' (like get_type, get_scope, ...) 或 'is_XXX' (like is_private, ...) 这似乎只提供信息（这显然是反思的目的）。但是，我找不到任何似乎允许成员访问给定对象的东西。欢迎任何提示。

basic.scope #scope-3.3.1说

两者都声明具有相同参数类型列表的函数，等效 ([temp.over.link]) 尾随要求子句（如果有，除非 [temp.friend] 中指定），并且如果两者都是非静态成员, 相同的 cv 限定符（如果有）和ref 限定符（如果两者都有）

上面的规则可以理解为，对于两个具有相同参数类型列表的非静态成员函数，如果任何人有一个 cv-qualifiers 那么两个声明应该有相同的 cv-qualifiers；如果两个声明都有 ref-qualifier，它们应该有相同的 ref-qualifier。否则，它们不对应。

在这个片段中，#1 是否对应于#2？由于#2 有一个 cv-qualifier 但#1 没有，即使具有相同的条件为 ref-qualifier真，根据规则（注意强调的和 在该规则中），它们不对应。那么，这是否意味着草案允许从这两个声明中形成一个重载集？毕竟，over.load#2.3部分已被 P1787 删除。

cppreference 说std::string::contains出来了， https ://en.cppreference.com/w/cpp/string/basic_string/contains

但没有运行时要求。是否保证在线性时间内运行？（例如，在实现中使用 KMP 算法）还是二次时间？

我试图在当前的 C++ 标准草案（http://open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4849.pdf）中找到它，但我找不到参考。

在2015 年的一次演讲中， Andrei Alexandrescu 概述了 std::allocator 接口的一些暴行，简短地强调了它实际上与分配无关，并提出了一种不同的思考方式来思考这些分配器，这将使它们更加可用和模块化。或者，引用描述：

std::allocator 有着不光彩的过去、阴暗的现在和无趣的未来。STL 引入分配器作为 1990 年代现在过时的分段内存模型的权宜之计。他们的设计是有限的，并且在很多方面甚至没有旨在帮助分配那么多。因为分配者在那里，他们只是继续在那里，直到他们变得不可能连根拔起或工作，尽管社区付出了英勇的努力。

本演讲讨论了从第一原理创建的内存分配器的完整设计。它是通用的、组件化的和可组合的，用于支持特定于应用程序的分配模式。

他针对当前 std::allocator 的主要观点包含在视频的这一部分中，但总结一下：

1. 分配器不应该关心被分配的类型，只关心大小和对齐方式。
2. 分配器不应该负责存储有关分配的大小信息，分配和释放应该对称地（分别）返回和接收Blk（ptr，大小）。
3. Rebind<U>::other很糟糕（他没有进一步详细说明）
4. 分配器不应该是无状态的（因为它们实际上给了你一些内存，它们怎么可能是无状态的？）
5. 分配器应该围绕组合的概念来定义；如果您查看现实世界的分配器，它们都由有条件运行的小型分配器组成。

自从我看了那场演讲后，我就期待着会从中得到某种建议，因为这个想法看起来非常合理和实用。过去我不得不使用 std::allocator ，当我的屏幕在候选函数不可行时向我尖叫时，它让我第一次理解了对 C++20 概念的需求。

但似乎没有任何东西来自它？那时我不在，但似乎 STL2 正在开发中，但后来已经停产了。是否已在某处确定概念足以至少调解 std::allocator 的症状（如果是，在哪里/何时？）还是向后兼容问题？未来 C++ 版本的路线图是否与此相关？

根据cppreference的说法，gcc 和 clang 最近都完成了P1102R2（“ Down with () !”）的实现，这意味着我们可以在 C++23 中更简洁地定义 lambda 表达式。

但我发现它们与某种形式不一致：

clang 接受这种形式，而 gcc拒绝它的语法。

我应该信任哪个编译器？这个 lambda 在 C++23 中格式正确还是格式错误？

更新：

可能是迫于舆论压力，在我举报后的五天内，clang 迅速修复了49736 。

当我进一步尝试时，我无意中发现 gcc 也拒绝了以下有效表单，这让我报告了99850，并在 2 周后修复。

当头文件中的这个类被添加到语言中时，我们将能够更轻松地处理哪些问题以及计划替换哪些语法？下面我将分享我从cppreference网站获得的代码。

班级std::stacktrace_entry

我创建了一个函数is_integer，它接受参数std::string_view并返回bool给定的字符串是否被限定为整数。

• 由于某些原因，-我包括了一元运算符。+
• 我使用starts_with方法来检查前缀。
• 我用containsfrom C++23orC++2b来检查指定的字符集是否包含这样的东西。

我的is_integer函数源代码：

测试：

如何用这些意想不到的结果解决这个问题？我的代码有什么问题吗（很有可能）？

所以我一直很期待元类。然后我听说它不会出现在c++23中，因为他们认为我们首先需要在语言中进行反射和具体化，然后才能添加元类。

查看c++23反射，似乎有具体化能力。它们是否足以解决元类的作用？即，元类只是语法糖吗？

使用当前的提案，我们可以复制某人编写如下类型：

并生成如下类型：

更进一步，采取类似于

并且能够生成

Live example，这两个都是我对元类感到兴奋的例子。

我不太担心语法（能够编写一个库并简单地创建多边形值或接口是有用的，确切的语法不是），但我担心它能够做到这一点。