

Interacting with C Pointers - speednoise
https://developer.apple.com/swift/blog/?id=6

======
msarnoff
I'm a little disappointed with the scope of this writeup. I just finished my
first full Swift app this weekend, and by far, the most bothersome part was
interacting with the C APIs (CoreMedia, ImageIO, etc.) I would have loved to
see more examples of interacting with framework objects like CGImageSources,
CMSampleBuffers, etc.

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.

~~~
chillacy
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.

~~~
pacaro
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...

------
plus9z
"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?)

~~~
msu8
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

------
nextstep
>> 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?

~~~
charlesism
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](https://devforums.apple.com/thread/238423?tstart=0)

