为什么用string_view而不是一般的container_view< T&gt ;？ [英] Why string_view instead of generalized container_view<T>?

问题描述

我发现新的C ++ 17标准的string_view有点多余。

I've found string_view from new C++17 standard a bit redundant.

我们已经收集了非常详细的简单机制，用于将数据传递给被调用方，没有太多的开销，现在又有了另一种，也只针对一种容器类型。

We've got a quite verbose collection of simple mechanisms for passing data to callee, without much overhead and now there is one another which is also specific only to one container type.

我不明白为什么只提供这种设备用于字符串，而不是用于其他容器的更通用的类型。一个明智的答案是，我们已经有了这类解决方案。例如，在 C ++ 17及更高版本演示文稿string_view解释为 observer_ptr< T> （或T *）表示字符串。

I don't understand why providing this machinery only for string and not some more generalized type for other containers. One sensible answer is that we've already had these kinds of solutions. For example in C++17 and beyond presentation string_view is explained as observer_ptr<T> (or T*) for string.

请针对更通用的container_view声明参数，而不是C ++ 17引入的string_view。

Please state the arguments against a more general container_view, in contrast to the string_view introduced by C++17.

推荐答案

广义的 container_view 更恰当地称为 range 。我们有一个完全用于范围概念的TS航路。

A generalized container_view is more properly called a range. We have a TS en-route devoted entirely to range concepts.

现在，我们有 string_view 作为单独的类型因为它具有专门的字符串专用接口来匹配 basic_string 的字符串专用接口。或者至少要匹配const /非分配接口。

Now, we have string_view as a separate type because it has a specialized, string-specific interface to match basic_string's string-specific interface. Or at least, to match the const/non-allocating interfaces.

请注意， container_view 或您所说的任何东西将无法删除其与生成它的容器的连接。或者至少在每次访问/操作时都没有付出类型擦除开销。

Note that container_view or whatever you called it would be incapable of erasing its connection to the container that generated it. Or at least, not without paying type-erasure overhead on each access/operation.

相比之下， string_view 是基于 const char * 和整数。那个班级不在乎字符串的来源；无论谁拥有它，它都能提供一个连续字符阵列的视图。之所以可以这样做是因为它知道源是一个连续的数组，因此将指针用作其迭代器的核心。

By contrast, string_view is based on const char*s and integers. That class doesn't care where the string came from; it provides a view into a contiguous array of characters no matter who owns it. It can do this because it knows that the source is a contiguous array, and therefore uses pointers as the core of its iterator.

您不能对任意容器执行此操作。您的 container_view< vector> 具有与 container_view< list> 或其他类似的迭代器。这将必须。这意味着，如果将 container_view 作为函数参数，则必须选择要使用的特定容器（强制用户提供确切的容器类型），然后将函数设置为模板，或使用类型擦除的迭代器范围（因此速度较慢）。

You can't do that for arbitrary containers. Your container_view<vector> would have different iterators from container_view<list> or whatever. It would have to. Which means if you take a container_view as a function parameter, you must either pick a specific container to use (forcing the user to provide exactly that container type), make your function a template, or use a type-erased iterator range (thus being slower).

对于CSL类型的 span 和 mdspan 。前者表示连续数组的可修改视图。后者表示您将多维数组视为连续数组的可修改视图。

There are also post-C++17 proposals for the GSL types span and mdspan. The former represents a modifiable "view" of a contiguous array. The latter represents a modifiable "view" of a contiguous array that you treat as multi-dimensional.

这篇关于为什么用string_view而不是一般的container_view< T&gt ;？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！