如何在 Swift 中证明 String 类型的“写时复制”

正如标题所说，我试图证明自己，Swift 中的 String 支持 COW(copy on write)。但我找不到证据。在尝试以下代码后，我在数组和字典上证明了 COW：

func address(of object: UnsafeRawPointer) -> String {
    let addr = Int(bitPattern: object)
    return String(format: "%p", addr)
}

var xArray = [20, 30, 40, 50, 60]
var yArray = xArray

// These two addresses were the same
address(of: xArray) 
address(of: yArray)

yArray[0] = 200
// The address of yArray got changed
address(of: yArray)

但对于 String 类型，它不起作用。

var xString = "Hello World"
var yString = xString

// These two addresses were different
address(of: xString)
address(of: yString)

我从官方 Swift 代码仓库中转储了测试函数。

func _rawIdentifier(s: String) -> (UInt, UInt) {
    let tripe = unsafeBitCast(s, to: (UInt, UInt, UInt).self)
    let minusCount = (tripe.0, tripe.2)
    return minusCount
}

但这个函数似乎只转换指向的实际值而不是地址。因此，两个具有相同值的不同字符串变量将具有相同的 rawIdentifier。仍然无法向我证明 COW。

var xString = "Hello World"
var yString = "Hello" + " World" 

// These two rawIdentifiers were the same
_rawIdentifier(s: xString)
_rawIdentifier(s: yString)

那么 COW 在 Swift 中如何处理 String 类型呢？

编译器只为两者创建一个存储"Hello World" and "Hello" + " World".

您可以通过检查汇编代码来验证这一点 从...获取

swiftc -emit-assembly cow.swift
  

它只定义了一个字符串文字

    .section    __TEXT,__cstring,cstring_literals
L___unnamed_1:
    .asciz  "Hello World"
  

一旦字符串发生变化，字符串存储的地址就会改变 缓冲区（该“神奇”元组的第一个成员，实际上_baseAddress of struct _StringCore，定义于StringCore.swift https://github.com/apple/swift/blob/master/stdlib/public/core/StringCore.swift） 变化：

var xString = "Hello World"
var yString = "Hello" + " World"

print(_rawIdentifier(s: xString)) // (4300325536, 0)
print(_rawIdentifier(s: yString)) // (4300325536, 0)

yString.append("!")
print(_rawIdentifier(s: yString)) // (4322384560, 4322384528)

为什么你的

func address(of object: UnsafeRawPointer) -> String

函数显示相同的值xArray and yArray， 但 不是为了xString and yString?

通过一个array向采用不安全指针的函数传递 第一个数组元素的地址，两者相同 数组（如果它们共享存储）。

通过一个string向采用不安全指针的函数传递一个 指向一个的指针暂时的字符串的 UTF-8 表示形式。 即使对于相同的字符串，该地址在每次调用中也可以不同。

此行为记录在“Using Swift with Cocoa and Objective-C”参考UnsafePointer<T>争论，但显然 对于以下情况同样适用UnsafeRawPointer论据。