Update UnsafeRawPointer proposal #507
Conversation
Updates the examples to use the new MemoryLayout APIs and fixes a few typos.
|
@atrick Can you review? |
| let p = UnsafeMutableRawPointer.allocate(bytes: sizeof(Int.self), | ||
| alignedTo: alignof(Int.self)) | ||
| let p = UnsafeMutableRawPointer.allocate(bytes: MemoryLayout<Int>.stride, | ||
| alignedTo: MemoryLayout<Int>.alignment) | ||
|
|
||
| initRawAorB(p, isA: true) | ||
| printA(p.assumingMemoryBound(to: A.self)) |
There was a problem hiding this comment.
@atrick Calling initRawAorB(p, isA: true) and then initRawAorB(p, isA: true) in this function violates the stated preconditions for initializeMemory(as:to:), since the second call initializes memory for B that is already initialized for A. Is this permitted because A is a trivial type and A and B are layout compatible, or is deinitialization required here?
There was a problem hiding this comment.
It's ok to reinitialize trivial types. It doesn't even matter here that they are layout compatible (as long as the allocated memory is large enough and properly aligned). I think there was initially some concern about exposing the term "trivial type" in these doc comments. But that cat is out of the bag.
I'll fix the doc comments:
swiftlang/swift#4560
|
Awesome. Looks great! |
|
a5afale |
Updates the examples to use the new
MemoryLayoutAPIs and fixes afew typos.