Mixing Objective-C with C and code organization

Question

I'm working on a desktop application that watch folders using the fileevent api, so basically this is my code :

#import "PNAppDelegate.h"

void callback(
              ConstFSEventStreamRef streamRef,
              void *clientCallBackInfo,
              size_t numEvents,
              void *eventPaths,
              const FSEventStreamEventFlags eventFlags[],
              const FSEventStreamEventId eventIds[]) 
{
    [(__bridge PNAppDelegate *)clientCallBackInfo reloadStatus];

};

@implementation PNAppDelegate

@synthesize window = _window;

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
    NSArray *pathsToWatch = [NSArray arrayWithObject: @"/Users/romainpouclet/Projects/foo"];

    void *appPointer = (__bridge void *)self;
    FSEventStreamContext context = {0, appPointer, NULL, NULL, NULL};

    FSEventStreamRef stream;
    CFAbsoluteTime latency = 3.0;

    stream = FSEventStreamCreate(NULL, 
                                 &callback, 
                                 &context, 
                                 (__bridge CFArrayRef) pathsToWatch, 
                                 kFSEventStreamEventIdSinceNow, 
                                 latency, 
                                 kFSEventStreamCreateFlagNone);

    NSLog(@"Schedule with run loop");
    FSEventStreamScheduleWithRunLoop(stream, CFRunLoopGetMain(), kCFRunLoopDefaultMode);
    FSEventStreamStart(stream);
    [self reloadStatus];
}

-(void)reloadStatus
{

}

@end

No problem, it works pretty well for a POC as simple as this one, BUT it feels kinda ugly (and it probably is, I'm not really used to mix Objective-C and C). So here are my questions :

where should I declare my callback? It feels weird having it at the top of my file, just because it worked there.
is it possible to have some kind of @selector-based approach instead of callbacks? (I find them reassuring :D)

Thanks for your time !

You could implement your callback in its own source file (optionally, grouped with other related C functions) and import a header with its forward declaration. But if the callback is 100% specific to this class and isn't needed anywhere else, it makes little sense. — Nicolas Miari, Jul 18 '12 at 20:53
Also, in your case the body of the callback needs access to the class declaration and at least one method. — Nicolas Miari, Jul 18 '12 at 20:54

score 2 · Answer 1 · answered Jul 18 '12 at 20:48

Why not put the callback declaration in either PNAppDelegate.h, or its own header file (if you don't want to spread it around your app). That way you can just include the header file and put the function definition anywhere you want. Doing so is standard C functionality.

// Header file callback.h
void callback(
              ConstFSEventStreamRef streamRef,
              void *clientCallBackInfo,
              size_t numEvents,
              void *eventPaths,
              const FSEventStreamEventFlags eventFlags[],
              const FSEventStreamEventId eventIds[]);


// PNAppDelegate.m
#import "PNAppDelegate.h"
#import "callback.h"

@implementation PNAppDelegate

...

@end

void callback(
              ConstFSEventStreamRef streamRef,
              void *clientCallBackInfo,
              size_t numEvents,
              void *eventPaths,
              const FSEventStreamEventFlags eventFlags[],
              const FSEventStreamEventId eventIds[]) 
{
    [(__bridge PNAppDelegate *)clientCallBackInfo reloadStatus];

};

It seems a bit cleaner this way. As for now that's the only callback I have, I'm not sure I need to put it in a dedicated file. Thanks! — Romain Pouclet, Jul 19 '12 at 11:00

score 1 · Accepted Answer · edited May 23 '17 at 10:34

You are correct, that code IS ugly. However, bridging C and Obj-C is no small task, so you really only have a few options:

Create an Objective-C wrapper around the C-based API. This would be my recommended approach, especially if the API is not too complex. It gives you the advantage of using either delegates or blocks, instead of functions.

Use blocks for callbacks, by getting their internal function pointer:

// internal structure of a block
struct blockPtr {
    void *__isa;
    int __flags;
    int __reserved;
    void *__FuncPtr;
    void *__descriptor;
};

int main()
{
    @autoreleasepool {
        __block int b = 0;        

        void (^blockReference)(void *) = ^(void *arg) {
            NSLog(@"<%s>: %i", arg, b++);
        };


        void *blockFunc = ((__bridge struct blockPtr *) blockReference)->__FuncPtr;
        void (*castedFunction)(void *, void *) = blockFunc;

        // the first argument to any block funciton is the block 
        // reference itself, similar to how the first argument to
        // any objc function is 'self', however, in most cases you
        // don't need the block reference (unless reading __block variables), it's just difficult to
        // get that first argument from inside the block
        castedFunction((__bridge void *) blockReference, "one");
        castedFunction((__bridge void *) blockReference, "two");
    }
}

I really don't think this is practical in most situations, but if you can find a way to make it work, more power to you.

Stick with how you are currently doing it. It sucks, but that is how C works.

Any example of what a wrapper would look like? That'd be the same problem with the callback definition, right? — Romain Pouclet, Jul 19 '12 at 01:42
@Palleas it's completely dependent upon the API. Most callback methods support a `context` argument, which could theoretically allow you to pass an object reference through to the function, in which case you would have one implementation which sends the message off to the context parameter's delegate. — Richard J. Ross III, Jul 19 '12 at 01:45
I see what you mean, I like the idea of calling the context parameter's delegate. The block solution is nice too, as I'll only have one callback... Thanks! — Romain Pouclet, Jul 19 '12 at 10:58

Mixing Objective-C with C and code organization

2 Answers2