c++ - 是否存在阻止采用D范围的C++语言障碍？

Question

这是一个C++/D交叉问题。与D programming language之类的C++库相比，ranges具有Boost.Range而不基于迭代器对。官方C++ Ranges Study Group似乎在制定技术规范时陷入了困境。

问题:当前的C++ 11或即将发布的C++ 14标准是否有阻碍采用D范围以及<algorithm>的适当范围版本的任何障碍？

我不十分了解D或其范围，但它们似乎很懒惰且可组合，并且能够提供STL算法的超集。鉴于他们声称D会取得成功，因此拥有C++库似乎很不错。我想知道D的独特功能(例如，字符串混合，统一函数调用语法)对于实现其范围是多么重要，以及C++是否可以在不花费太多精力的情况下模仿它(例如，C++ 14 constexpr看起来与D编译时函数评估非常相似) )

注意:我在寻求技术答案，而不是在考虑D范围是否是作为C++库具有的正确设计。

Answer 1

我认为C++没有任何固有的技术限制，因此不可能在C++中定义D样式范围和相应算法的系统。最大的语言水平问题是，基于C++范围的for -loops要求可以在范围上使用begin()和end()，但是假设我们将尽力使用D样式范围定义库，扩展了基于范围的for-处理它们的循环似乎是微不足道的。

在C++中使用D风格范围的算法进行实验时，遇到的主要技术问题是，我无法使算法的执行速度与基于迭代器(实际上是游标)的实现一样快。当然，这可能只是我的算法实现，但是我还没有看到有人在C++中提供我可以针对的一组合理的基于D风格范围的算法。性能很重要，C++标准库至少应提供算法的低效率实现(如果将算法的通用实现应用于数据结构的速度至少与该算法的自定义实现一样快，则该算法的通用实现称为弱效率使用相同数据结构，使用相同编程语言的算法)。我无法基于D样式范围创建效率较低的算法，而我的目标实际上是效率较高的算法(类似于效率较低的算法，但允许使用任何编程语言，并且仅假设使用相同的底层硬件)。

在试验基于D风格的基于范围的算法时，我发现该算法比基于迭代器的算法更难以实现，并且发现有必要解决纠缠以解决其某些局限性。当然，用C++指定算法的当前方法也不是完美的。有关如何更改算法及其使用的抽象的概述，请参见STL 2.0页面。但是，此页面实际上并不涉及范围，因为这是一个相关但有些不同的主题。我宁愿设想基于迭代器(很好，实际上是游标)的范围，而不是D样式的范围，但是问题不在于此。

C++中所有范围抽象所面临的一个技术问题是必须以合理的方式处理临时对象。例如，考虑以下表达式:

auto result = ranges::unique(ranges::sort(std::vector<int>{ read_integers() }));

取决于ranges::sort()或ranges::unique()是否是懒惰的，需要处理临时范围的表示形式。对于这两种算法，仅提供源范围的 View 都是不可行的，因为临时对象将在表达式的末尾消失。一种可能是移动范围(如果范围以r值形式出现)，则ranges::sort()和ranges::unique()要求使用不同的结果以区分实际参数是临时对象还是独立保持 Activity 的对象的情况。 D没有这个特殊的问题，因为D是被垃圾收集的，因此无论哪种情况，源范围都将保持 Activity 状态。

上面的示例还显示了可能存在延迟评估算法的问题之一:由于可以通过auto变量或模板化函数推导任何类型，包括无法以其他方式拼写的类型，因此没有任何强制最后的延迟表达式因此，可以从表达式模板中获得结果，并且该算法并未真正执行。也就是说，如果将l值传递给算法，则需要确保对该表达式进行了实际求值以获得实际效果。例如，任何使整个序列发生突变的sort()算法都明确地进行了原位突变(如果您希望版本不就地进行突变，只需复制容器并应用就地版本；如果您只有非就地版本，您无法避免可能是直接问题的额外序列，例如，对于巨大序列)。假设它在某种程度上是惰性的，那么对原始序列的左值访问可以使当前状态达到最高峰，这几乎肯定是一件坏事。这可能意味着对变异算法的惰性评估无论如何都不是一个好主意。

无论如何，C++的某些方面使得不可能立即采用D-sytle范围，尽管相同的考虑因素也适用于其他范围抽象。因此，我认为这些考虑也超出了该问题的范围。另外，第一个问题(添加垃圾回收)的明显“解决方案”不太可能发生。我不知道D中是否有第二个问题的解决方案。可能会出现第二个问题的解决方案(暂时称为operator auto)，但我不知 Prop 体的建议或该功能的外观喜欢。

顺便说一句，Ranges Study Group并没有被任何技术细节所困扰。到目前为止，我们仅试图找出我们实际上要解决的问题，并扩大解决方案的范围。此外，小组通常根本不完成任何工作!实际的工作总是由个人完成的，通常是很少的个人。由于工作的主要部分实际上是设计一组抽象，因此我希望Ranges Study Group的任何结果的基础都由1-3个人组成，他们对所需的内容以及外观有一定的了解。