问题

I'm trying to convert an Objective-C app to swift.

I'd like to import classes in aurioTouch to Swift app, so I created the following Bridging-Header file:

#import "AudioController.h"

but I received following errors in DCRejectionFilter.h, BufferManager.h, FFTHelper.h:

Unknown type name 'class'; did you mean 'Class'?

Expected ';' after top level declarator

and also in AudioController.h:

Unknown type name 'BufferManager'

Unknown type name 'DCRejectionFilter'

Of course I use .mm instead of .m, but this does not work.

update

The simple swift project just including aurioTouch Library (with Obj-C and C++) is as follows: https://github.com/pika-shi/aurioTouch-Sample

回答1:

The present answer shows you how to solve the Bridging Header #import, and is a step-by-step tutorial on how to create an Objective-C wrapper object.

.mm does not mean Swift

.mm does not mean Objective-C either

It means Objective-C++, and merely renaming a file to .mm offers no improvement. Notice that you are still including the same .h files, and those are where the problem starts. These .h reference C++ classes, and they must be wrapped.

Wrap the C++ in Objective-C

The file AudioController.h is not an Objective-C file: it includes BufferManager.h which is a C++ file, and compilation stops right there.

You need to create a true wrapper, say AudioControllerBridge which .h is in Objective-C, and .mm can, in turn, make references to C++:

Absolutely, positively no C++ allowed, explicit, included, or else.

#import <Foundation/Foundation.h>
@interface AudioControllerBridge : NSObject
    // ...
@end

.mm

Objective-C++ tolerates all the C++ you need, as long as it is not exposed in the interface.

#import "AudioControllerBridge.h"
#import "AudioController.h"
@implementation AudioControllerBridge
    // ...
@end

Of course, you could simply modify the AudioController.h directly, but we will consider this bad practice: for the rest of this answer, we will assume that you are attempting to integrate aurioTouch as-is, with exactly 0 lines of code changed.

In the implementation of AudioControllerBridge, you can now instantiate the AudioController, and import all the C++ files you need for proper compilation, something you could not do in the .h. Remember that the .h you are exposing to Swift in Briding-Header must be a pure Objective-C interface.

// Bridging Header
#import "AudioControllerBridge.h"

ARC

You will soon see that you need to download CoreAudio/PublicUtility because some files, like CADebugPrintf are simply missing from the example, and somehow will not build in your new project, at least in DEBUG mode.

If you made it so far, you will then find out that you will get a dozen deprecated warnings, which you can ignore for now, and half as much ARC errors in AudioController.mm. Fix with -fno-objc-arc Compiler Flag:

If you made it so far (props), and have added:

Accelerate.framework
AudioToolbox.framework
AVFoundation.framework

to your target in Build Phases and compiled, you will find that it builds and links.

Wrapping it up

It took me 1h 47mins to reach that point (proof below). The next step is of course to actually put the wrapper code in AudioControllerBridge, so that it returns (wraps):

BufferManager*          _bufferManager;
DCRejectionFilter*      _dcRejectionFilter;
- (BufferManager*) getBufferManagerInstance;

which are the 3 non-Objective-C elements in that class.

It may be cleaner to to wrap BufferManager and DCRejectionFilter as well, so that they can be used freely in Swift. I will let that decision to the reader.