std.algorithm.joiner(string []，string)-为什么结果元素是dchar而不是char? [英] std.algorithm.joiner(string[],string) - why result elements are dchar and not char?

问题描述

我尝试编译以下代码:

import std.algorithm;
void main()
{
    string[] x = ["ab", "cd", "ef"]; // 'string' is same as 'immutable(char)[]'
    string space = " ";
    char z = joiner( x, space ).front(); // error
}

使用dmd进行的编译以错误结束:

Compilation with dmd ends with error:

 test.d(8): Error: cannot implicitly convert expression (joiner(x,space).front()) of type dchar to char

将char z更改为dchar z确实可以修复错误消息，但是我很感兴趣为什么它首先出现.

Changing char z to dchar z does fix the error message, but I'm interested why it appears in the first place.

为什么joiner(string[],string).front()的结果是dchar而不是char?

Why result of joiner(string[],string).front() is dchar and not char?

(在文档 http://dlang.org/phobos/std_algorithm中没有任何内容.html#joiner )

推荐答案

所有字符串均视为dchar的范围.这是因为dchar保证是单个代码点，因为在UTF-32中，每个代码单元都是一个代码点，而在UTF-8(char)和UTF-16(wchar)中，每个代码点的代码单元数量有所不同.因此，如果您对单个char或wchar进行操作，则将对部分字符而不是整个字符进行操作，这将非常糟糕.如果您对Unicode不太了解，建议您阅读Joel Spolsky撰写的本文.它解释得很好.

All strings are treated as ranges of dchar. That's because a dchar is guaranteed to be a single code point, since in UTF-32, every code unit is a code point, whereas in UTF-8 (char) and UTF-16 (wchar), the number of code units per code point varies. So, if you were operating on individual chars or wchars, you'd be operating on pieces of characters rather than whole characters, which would be very bad. If you don't know much about unicode, I'd advise reading this article by Joel Spolsky. It explains things fairly well.

在任何情况下，由于对单个char和wchar进行操作没有意义，因此char和wchar的字符串被视为dchar的范围(ElementType!string为)，这意味着就范围而言，它们没有length(hasLength!string是false-walkLength需要用于获取其长度)，是不可切片的(hasSlicing!string是false)，并且不可索引(isRandomAccess!string是false).这也意味着，从任何类型的字符串构建新范围的任何事物都将导致范围dchar. joiner是其中之一.有一些函数可以理解unicode和特殊情况下的字符串以提高效率，可以利用它们可以利用的长度，切片和索引，但是除非它们的结果最终是原始结果的一部分，否则必须返回它们的任何范围的dchar s.

In any case, because operating on individual chars and wchars doesn't make sense, strings of char and wchar are treated as ranges of dchar (ElementType!string is dchar), meaning that as far as ranges are concerned, they don't have length (hasLength!string is false - walkLength needs to be used to get their length), aren't sliceable (hasSlicing!string is false), and aren't indexable (isRandomAccess!string is false). This also means that anything which builds a new range from any kind of string is going to result in a range of dchar. joiner is one of those. There are some functions which understand unicode and special case strings for efficiency, taking advantage of length, slicing, and indexing where they can, but unless their result is ultimately a slice of the original, any range they return is going to have to be made of dchars.

因此，任何范围的字符上的front始终为dchar，而popFront始终弹出完整的代码点.

So, front on any range of characters will always be dchar, and popFront will always pop off a full code point.

如果您对范围不太了解，建议您阅读此.这是在线上有关D的书中的一章，是当前有关范围的最佳指南.我们确实应该在 dlang.org 上找到有关范围(包括它们如何使用字符串)的适当文章，但是还没有人写它.无论如何，您将至少需要对范围有基本的了解，才能使用很多D的标准库(尤其是std.algorithm)，因为它使用率很高.

If you don't know much about ranges, I'd advise reading this. It's a chapter in a book on D which is online and is currently the best tutorial on ranges that we have. We really should get a proper article on ranges (including on how they work with strings) onto dlang.org, but no one's gotten around to writing it yet. Regardless, you're going to need to have at least a basic grasp of ranges to be able to use a lot of D's standard library (especially std.algorithm), because it uses them very heavily.

这篇关于std.algorithm.joiner(string []，string)-为什么结果元素是dchar而不是char?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！