Interacting with C Pointers(developer.apple.com)
developer.apple.com
Interacting with C Pointers
https://developer.apple.com/swift/blog/?id=6
14 comments
I, too have found the type system to be a bit tedious at times, especially with Carbon. It also doesn't help that SourceKit crashes often while doing crazy things with types. I've just been reverting back to ObjC for these specific things (plus better error messages and tooling).
But looking back, the first versions of ObjC were also kind of tedious (no @property declarations, no blocks, etc) and it's gone a long way.
But looking back, the first versions of ObjC were also kind of tedious (no @property declarations, no blocks, etc) and it's gone a long way.
Hopefully the pace of language development will be a little faster!
Putting snark to one side, is it a general principle that languages evolve/develop more quickly now than in olden times...
Putting snark to one side, is it a general principle that languages evolve/develop more quickly now than in olden times...
> I'm a little disappointed with the scope of this writeup.
There's a teaser at the end that there will be a follow-up article about UnsafePointer.
I just hope they hurry up and post it soon. I have half a large app that relies on UnsafePointers, and I could really use some clear documentation to reassure myself that I'm not abusing them.
There's a teaser at the end that there will be a follow-up article about UnsafePointer.
I just hope they hurry up and post it soon. I have half a large app that relies on UnsafePointers, and I could really use some clear documentation to reassure myself that I'm not abusing them.
Likewise, I'm running into UnsafePointers with IOKit.
"For safety, Swift requires the variables to be initialized before being passed with &. This is because it cannot know whether the method being called tries to read from a pointer before writing to it."
I've not written any Swift code yet, so can someone enlighten me -- is this actually true? This seems unnecessarily restrictive (and absurd -- Swift can't tell if a pointer's being read?)
I've not written any Swift code yet, so can someone enlighten me -- is this actually true? This seems unnecessarily restrictive (and absurd -- Swift can't tell if a pointer's being read?)
If you've got an easy way to tell if a C pointer is being read at compile time I'd certainly like to hear of it, would save quite a bit of valgrinding
[deleted]
If the source to the method being called is not available, then it's certainly possible for the compiler not to be able to tell how a pointer passed to that method might be used.
In the case of an optional it can be initialised to nil (and it will be implicitly).
Swift can tell from static analysis if it might be read at compile time and raise an issue if it isn't initialised on all oaths to the access. If passed as an inout parameter it has to assume it may be read[0] and for safety require that it must be initialised.
[0] at least if it is calling into a library even if it can check the current version it couldn't know for sure that a different library version won't behave differently.
Swift can tell from static analysis if it might be read at compile time and raise an issue if it isn't initialised on all oaths to the access. If passed as an inout parameter it has to assume it may be read[0] and for safety require that it must be initialised.
[0] at least if it is calling into a library even if it can check the current version it couldn't know for sure that a different library version won't behave differently.
>> For safety, Swift requires the variables to be initialized before being passed with &. This is because it cannot know whether the method being called tries to read from a pointer before writing to it.
Isn't the 'maybeError' var being used uninitialized in the example right about this passage?
Isn't the 'maybeError' var being used uninitialized in the example right about this passage?
It actually does get initialized, albeit intialized to "nil". Someone asked the same question on the devforums. https://devforums.apple.com/thread/238423?tstart=0
For example, CGImageSourceCreateWithURL() returns an Unmanaged<CGImageSource>!. You can't pass that object to CGImageSourceCreateImageAtIndex(), because it expects a CGImageSource!. Instead, you have to call takeUnretainedValue() on the Unmanaged to extract the raw pointer. Not terribly difficult, just mildly annoying and not well documented. In C/ObjC, you'd just take the return value of the first function and pass it right into the second.
Another example: CMSampleBufferGetImageBuffer() returns a CVImageBuffer!. And CVPixelBufferLockBaseAddress() takes a CVPixelBuffer! as its argument. In C/ObjC, CVPixelBufferRef is typedef'd to CVImageBufferRef, but that doesn't carry over in Swift. I tried to figure out the opaque-pointer voodoo required to convert from one to the other, and eventually gave up, wrote the function in Objective-C, and moved on.
Swift is shaping up to be an excellent language, but at this point, the casting/wrapping/unwrapping hurdles make it difficult for newcomers and experienced developers alike to take advantage of Apple's 15+ year corpus of powerful APIs.