是否存在阻止采用D范围的C ++语言障碍？ [英] Are there any C++ language obstacles that prevent adopting D ranges?

问题描述

这是C ++ / D交叉问题。 D编程语言具有范围 rel = noreferrer> Boost.Range -不是基于迭代器对。官方的 C ++范围研究小组似乎在制定技术规范时陷入了困境。

This is a C++ / D cross-over question. The D programming language has ranges that -in contrast to C++ libraries such as Boost.Range- are not based on iterator pairs. The official C++ Ranges Study Group seems to have been bogged down in nailing a technical specification.

问题：当前的C ++ 11或即将推出的C ++ 14标准是否有阻碍采用D范围的障碍？作为< algorithm> -批发的合适范围版本？

Question: does the current C++11 or the upcoming C++14 Standard have any obstacles that prevent adopting D ranges -as well as a suitably rangefied version of <algorithm>- wholesale?

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

I don't know D or its ranges well enough, but they seem lazy and composable as well as capable of providing a superset of the STL's algorithms. Given their claim to success for D, it would seem very nice to have as a library for C++. I wonder how essential D's unique features (e.g. string mixins, uniform function call syntax) were for implementing its ranges, and whether C++ could mimic that without too much effort (e.g. C++14 constexpr seems quite similar to D compile-time function evaluation)

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

Note: I am seeking technical answers, not opinions whether D ranges are the right design to have as a C++ library.

推荐答案

我认为C ++中没有固有的技术限制，使得无法使用C ++定义D样式范围和相应算法的系统。最大的语言级别问题是基于C ++范围的 for 循环要求 begin（）和 end（）可以在范围内使用，但是假设我们会尽力使用D样式范围定义库，扩展基于范围的 for -循环来处理它们似乎是一个微不足道的改变。

I don't think there is any inherent technical limitation in C++ which would make it impossible to define a system of D-style ranges and corresponding algorithms in C++. The biggest language level problem would be that C++ range-based for-loops require that begin() and end() can be used on the ranges but assuming we would go to the length of defining a library using D-style ranges, extending range-based for-loops to deal with them seems a marginal change.

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

The main technical problem I have encountered when experimenting with algorithms on D-style ranges in C++ was that I couldn't make the algorithms as fast as my iterator (actually, cursor) based implementations. Of course, this could just be my algorithm implementations but I haven't seen anybody providing a reasonable set of D-style range based algorithms in C++ which I could profile against. Performance is important and the C++ standard library shall provide, at least, weakly efficient implementations of algorithms (a generic implementation of an algorithm is called weakly efficient if it is at least as fast when applied to a data structure as a custom implementation of the same algorithm using the same data structure using the same programming language). I wasn't able to create weakly efficient algorithms based on D-style ranges and my objective are actually strongly efficient algorithms (similar to weakly efficient but allowing any programming language and only assuming the same underlying hardware).

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

When experimenting with D-style range based algorithms I found the algorithms a lot harder to implement than iterator-based algorithms and found it necessary to deal with kludges to work around some of their limitations. Of course, not everything in the current way algorithms are specified in C++ is perfect either. A rough outline of how I want to change the algorithms and the abstractions they work with is on may STL 2.0 page. This page doesn't really deal much with ranges, however, as this is a related but somewhat different topic. I would rather envision iterator (well, really cursor) based ranges than D-style ranges but the question wasn't about that.

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

One technical problem all range abstractions in C++ do face is having to deal with temporary objects in a reasonable way. For example, consider this expression:

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

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

In dependent of whether ranges::sort() or ranges::unique() are lazy or not, the representation of the temporary range needs to be dealt with. Merely providing a view of the source range isn't an option for either of these algorithms because the temporary object will go away at the end of the expression. One possibility could be to move the range if it comes in as r-value, requiring different result for both ranges::sort() and ranges::unique() to distinguish the cases of the actual argument being either a temporary object or an object kept alive independently. D doesn't have this particular problem because it is garbage collected and the source range would, thus, be kept alive in either case.

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

The above example also shows one of the problems with possibly lazy evaluated algorithm: since any type, including types which can't be spelled out otherwise, can be deduced by auto variables or templated functions, there is nothing forcing the lazy evaluation at the end of an expression. Thus, the results from the expression templates can be obtained and the algorithm isn't really executed. That is, if an l-value is passed to an algorithm, it needs to be made sure that the expression is actually evaluated to obtain the actual effect. For example, any sort() algorithm mutating the entire sequence clearly does the mutation in-place (if you want a version doesn't do it in-place just copy the container and apply the in-place version; if you only have a non-in-place version you can't avoid the extra sequence which may be an immediate problem, e.g., for gigantic sequences). Assuming it is lazy in some way the l-value access to the original sequence provides a peak into the current status which is almost certainly a bad thing. This may imply that lazy evaluation of mutating algorithms isn't such a great idea anyway.

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

In any case, there are some aspects of C++ which make it impossible to immediately adopt the D-sytle ranges although the same considerations also apply to other range abstractions. I'd think these considerations are, thus, somewhat out of scope for the question, too. Also, the obvious "solution" to the first of the problems (add garbage collection) is unlikely to happen. I don't know if there is a solution to the second problem in D. There may emerge a solution to the second problem (tentatively dubbed operator auto) but I'm not aware of a concrete proposal or how such a feature would actually look like.

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

BTW, the Ranges Study Group isn't really bogged down by any technical details. So far, we merely tried to find out what problems we are actually trying to solve and to scope out, to some extend, the solution space. Also, groups generally don't get any work done, at all! The actual work is always done by individuals, often by very few individuals. Since a major part of the work is actually designing a set of abstractions I would expect that the foundations of any results of the Ranges Study Group is done by 1 to 3 individuals who have some vision of what is needed and how it should look like.

这篇关于是否存在阻止采用D范围的C ++语言障碍？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！