手动构造Swift UnsafeMutablePointer时，必须在分配后销毁/取消分配吗? [英] When constructing a Swift UnsafeMutablePointer manually, is destroy/dealloc obligatory after alloc?

问题描述

假设在Swift中，我手动构造了一个C数组并将其传递，如下所示:

override func drawRect(rect: CGRect) {
    let c = UIGraphicsGetCurrentContext()
    var arr = UnsafeMutablePointer<CGPoint>.alloc(4)
    arr[0] = CGPoint(x:0,y:0)
    arr[1] = CGPoint(x:50,y:50)
    arr[2] = CGPoint(x:50,y:50)
    arr[3] = CGPoint(x:0,y:100)
    CGContextStrokeLineSegments(c, arr, 4)
}

(我知道我没有要做那件事，但请忍受我.)如果我没有在此UnsafeMutablePointer上调用destroy和/或dealloc，我是吗?泄漏了四个CGPoint的内存?

解决方案

UnsafeMutablePointer的文档非常清楚:

///                      This type provides no automated
/// memory management, and therefore the user must take care to allocate
/// and free memory appropriately.

因此，如果您分配但不取消分配，则会泄漏内存.销毁指针对象不会自动取消分配.

关于是否应该在分配之前销毁，这也很清楚:

/// The pointer can be in one of the following states:
///
/// - memory is not allocated (for example, pointer is null, or memory has
/// been deallocated previously);
///
/// - memory is allocated, but value has not been initialized;
///
/// - memory is allocated and value is initialized.

但是请记住，您可以在这些状态之间来回转换.因此，在分配然后初始化然后取消初始化(也就是销毁)对象之后，内存不再处于已初始化"状态，因此您可以重新初始化或取消分配它.您也可以进行分配，然后再进行分配，而无需进行初始化.

当调用dealloc时:

/// Deallocate `num` objects.
...
/// Precondition: the memory is not initialized.
///
/// Postcondition: the memory has been deallocated.

因此，您必须在调用dealloc之前对所有初始化的对象调用destroy.您可能是对的，因为类似CGPoint的东西是完全惰性的(只是两个浮点数的结构)，因此可能不会对调用destroy而不造成任何危害，然后再调用dealloc，但是您不能确定是否不知道实现(可能是指针struct和编译器的实现，因为标准库是语言的准组成部分，可能会有一些优化的方法)，通常，它是只是不习惯养成这种习惯.迟早您会忘记销毁String，然后您会后悔的.

(这些都不涉及move操作btw，该操作将初始化新内存与销毁旧内存结合在一起)

如果您希望通过UnsafePointer进行某种自动的内存自动清理，我认为这不可能，因为a)这是一种结构，因此无法实现deinit来自动执行-超出范围时取消分配，并且b)它不跟踪其自身大小-您必须跟踪分配的数量，并在对deallocate的调用中显式提供.

标准库中有一些东西可以自动重新分配内存，而您不必自己做-HeapBufferStorage，这是标准库中唯一的类.大概这是一个专门从deinit实现中受益的类.还有HeapBuffer可以用来管理它，并且它有一个方便的isUniquelyReferenced()函数，它使您可以知道是否已复制它(即使它是一个结构)，因此可以实现类似于以下功能的写时复制功能数组和字符串.

Let's say that in Swift I construct a C array manually and pass it, like this:

override func drawRect(rect: CGRect) {
    let c = UIGraphicsGetCurrentContext()
    var arr = UnsafeMutablePointer<CGPoint>.alloc(4)
    arr[0] = CGPoint(x:0,y:0)
    arr[1] = CGPoint(x:50,y:50)
    arr[2] = CGPoint(x:50,y:50)
    arr[3] = CGPoint(x:0,y:100)
    CGContextStrokeLineSegments(c, arr, 4)
}

(I know I don't have to do that, but just bear with me.) If I don't call destroy and/or dealloc on this UnsafeMutablePointer, am I leaking the memory for four CGPoints?

解决方案

The documentation for UnsafeMutablePointer is pretty clear:

///                      This type provides no automated
/// memory management, and therefore the user must take care to allocate
/// and free memory appropriately.

So if you allocate but don’t deallocate, you will leak memory. There’s no auto-deallocation on destruction of the pointer object.

Re whether you should destroy before deallocating, it’s also pretty clear:

/// The pointer can be in one of the following states:
///
/// - memory is not allocated (for example, pointer is null, or memory has
/// been deallocated previously);
///
/// - memory is allocated, but value has not been initialized;
///
/// - memory is allocated and value is initialized.

But bear in mind you can transition back and forth between these states. So after allocating then initializing then de-initialzing (aka destroying) the objects, the memory is no longer in the "initialized" state, so you can either re-initialize or deallocate it. You can also allocate, then deallocate, without ever initializing.

And when calling dealloc:

/// Deallocate `num` objects.
...
/// Precondition: the memory is not initialized.
///
/// Postcondition: the memory has been deallocated.

Therefore you must call destroy on any initialized objects before calling dealloc. You are probably right in that since something like CGPoint is totally inert (just a struct of two floating point nums) it probably doesn’t do any harm not to call destroy before you call dealloc but you can’t be certain without knowing the implementation (of both the pointer struct and the compiler probably, since the standard lib is a quasi-part of the language there could be some baked-in optimizations), and generally, it’s just not a good habit to get into. Sooner or later you’ll forget to destroy a String, and then you’ll be sorry.

(none of this accounts for the move operations btw which combine initializing new memory with destroying old memory)

If you were hoping for some kind of automated self-cleanup of memory by UnsafePointer, I don’t think this would be possible as a) it’s a struct, so can’t implement a deinit to auto-deallocate when going out of scope, and b) it doesn’t track it’s own size – you have to track how much you allocate, and supply that back explicitly in the call to deallocate.

There is something in the standard library that does auto-deallocate memory without you having to do it yourself – HeapBufferStorage, the one and only class in the standard library. Presumably it’s a class specifically to benefit from an implementation of deinit. There’s also HeapBuffer to manage it with, and this has a handy isUniquelyReferenced() function that allows you to tell if it’s been copied (even though it’s a struct) and so would allow you to implement copy-on-write capability similar to arrays and strings.

这篇关于手动构造Swift UnsafeMutablePointer时，必须在分配后销毁/取消分配吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！