问题描述
随着即将到来的Ranges库的出现，用两个迭代器来表示范围的需求几乎消失了。例如，而不是
With the upcoming Ranges library, the need to denote a range with two iterators is pretty much gone. For example, instead of
if (std::equal(begin(foo), end(foo), begin(bar), end(bar)))
我们有
if (std::ranges::equal(foo, bar))
后者之所以可以说是优越的，不仅因为它的简洁性，还因为它避免了省略 end（bar）并欢迎绑定错误的常见陷阱。
The latter is arguably superior not only because of its conciseness, but also because it prevents the common pitfall of omitting end(bar) and welcoming bound errors.
下面的代码怎么样？
std::vector<int> vec{begin(foo), end(foo)};
其中 foo 是一个范围。使用Ranges，我希望将其简化为
where foo is a range. With Ranges, I'd expect simplifying it into
std::vector<int> vec{foo};
但是，我在或。 Ranges库也不会引入一组新的容器。
However, I fail to find any mention of it in [vector] or [container.requirements]. Nor does the Ranges library introduce a new set of containers.
为什么Ranges库不支持某个范围内的容器初始化？
Why does the Ranges library not support container initialization from a range? What is the rationale?
推荐答案
C ++ 20的目标是获得范围！在克服这些障碍之前，要克服几个障碍，但是一旦克服了这些障碍，委员会就认为最好引入一个可能的功能库，该功能库可能功能不完整，而不是根本没有功能。
The goal for C++20 was to get ranges in! There were several hurdles to get over before that could happen, but once those were overcome it's quite probable the committee believed it's best to introduce a workable ranges library that is perhaps not feature complete, instead of no ranges at all.
这并不是说此功能是不受欢迎的，只是关于此功能尚有一些悬而未决的问题，但它仍在进行中（请参阅）。
That is not to say that this feature is undesirable, only that there were just some open questions left regarding it, but it's still in the works (see p1206).
如果您阅读了本文修订版1的原理，就会提到将构造函数添加到标准容器中被证明是行不通的。可能是因为标准容器在初始化时进行了很多改装，以至于过载解析成为一场噩梦。
If one reads the rationale for revision 1 of the paper, it mentions that adding constructors to the standard containers proved unworkable. Likely because the standard containers have so much retrofitted on their initialization that overload resolution becomes a nightmare.
这篇关于为什么即将发布的Ranges库不支持某个范围的容器初始化？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！