All of our C++ headers use a .h extension. Eclipse thinks these are C headers and flags them with lots of syntax errors on things like classes and namespaces.
I've tried to change the file type association from:
Preferences > C/C++ > File types
but it's "locked".
Interestingly, "*.h" is associated with both C and C++ headers, but it seems to be using C. How can I get Eclipse to treat .h files as C++?
Try creating a new project and specify your source area as the location. However, be sure you select C++ project (I usually use the makefile option). This is all you should have to do in order to make the parser recognize C++ syntax.
Related
I want to make an app in Swift that simply record via the mic of the iPhone and then play the sound recorded.
For that, I'd like to use the lib Superpowered that is a static library with header files.
For that, I tried to drag and drop the .a and headers files in my project (Xcode create for me a bridging header file), add the .a in "Linked Frameworks and Libraries" in Xcode > Target > General (and so in Xcode > Target > Build phases > "Link Binary With Libraries" too) and index the .h files path in Xcode > Target > Build Settings > Search Paths > Library Search Paths.
But with that I have the error "ld: symbol(s) not found for architecture arm64"
Exactly the same as here XCode: Undefined symbols for architecture arm64 error and I tried all the solutions that I found on the web for that, still no way to compile.
SO !
Superpowered gives us a sample app to show how to mix Objective-C++ and use their lib within a Swift project (Here's a link to the git if you want https://github.com/superpoweredSDK/Low-Latency-Android-Audio-iOS-Audio-Engine).
Here is some screenshots of the sample project with what I understand and what I don't :
The Bridging-Header-File with the prototypes of the methods of the lib that I want to use within my Swift code (I don't like this but if it's the only way...).
The viewController file where the code in Swift is, and where I can create a Superpowered object thank's to the Bridging-Header-File, and call the methods that I've put in it.
And wtf I don't even understand why this Objective-C++ file is here and what it contains. It comes out from nowhere, not even their lib files.
So with this sample project in mind, I've created my own project, here is some screenshots :
The same Bridging-Header-File that in the sample project except that I include SuperpoweredIOSAudioIO.h so I can use SuperpoweredIOSAudioIODelegate.
My viewController file where the code in Swift is, and where I can create a Superpowered object thank's to the Bridging-Header-File, and call the methods that I've put in it.
Until here, it's great, except that I can't for exemple create a SuperpoweredRecorder object. If I try to include the SuperpoweredRecorder.h file in my Bridging-Header-File I have these errors :
So I saw that it is because SuperpoweredRecorder.h includes some .cpp files and I have to create a wrapper for cpp (a little bit like I did with the bridging header, no ?) but that includes a .h and a .mm file and I don't know what I have to put in that .mm file (the code of SuperpoweredRecorder.cpp ? But I don't have access to it)
So yes, I'm a little bit confused with all that stuff, can you help me to understand how can I use all the Superpowered lib in my Swift project please ?
As I said in comment to #OmniProg, I had a little conversation with the CTO of Superpowered that helped me a lot to find the solution below.
So, as Swift cannot interact directly with C++ but can with Objective-C, I had to create objects in Objective-C++ (.mm file, a mix between C++ and Objective-C) that wrap C++ classes of the lib Superpowered.
Here is an example with the SuperpoweredRecorder object from the lib :
Here I create a .h file where I prototype my wrapper with the name SuperpoweredRecorderWrapped, and I also prototype in it all the methods of the SuperpoweredRecorder of the lib that I want to use.
Then I create a new .m file that I rename .mm and I implement SuperpoweredRecorderWrapped on it.
I import both SuperpoweredRecorderWrapped.h and SuperpoweredRecorder.h.
I create a SuperpoweredRecorder object as property named _wrapped and in my methods, I call the corresponding method of the _wrapped object.
With that, when I'll call start of a SuperpoweredRecorderWrapped in my Swift code, this one will call start of _wrapped, a SuperpoweredRecorder object. See the trick ?
And finally I include all the wrapped classes in my Bridging-Header, like that I can instantiate my wrapped objects from Swift.
NOTE: All the C++ code HAVE to be in .mm files, that's why I make my #include of .h that contains C++ code in my .mm file and not in my .h file.
I haven't programmed in Objective-C++, but I do have experience with C, C++, Objective-C, and Swift, so here are some observations and ideas based on looking at the Superpowered SDK and sample code.
A bridging header lets Swift interface directly with Objective-C, and since Objective-C is a strict superset of C, this implies interfacing with C as well. However, you cannot interface directly with C++, and that's where Objective-C++ comes to the rescue. From what I'm seeing you can mix Objective-C and C++ code in Objective-C++, which allows Objective-C to use C++ classes.
Now on to some specifics.
The bridging header in the SuperpoweredFrequencies example that you looked at introduces a new Objective-C class, Superpowered, which is not part of the library, but of the example, and is implemented in Superpowered.mm. It is an Objective-C++ file, because Superpowered calls some C++ code.
Looking at Superpowered.mm, you will see that it imports Objective-C headers:
#import "SuperpoweredFrequencies-Bridging-Header.h"
#import "SuperpoweredIOSAudioIO.h"
as well as C and C++ headers:
#include "SuperpoweredBandpassFilterbank.h"
#include "SuperpoweredSimple.h"
We could have used import instead of include for C++ code, too, but they are probably using include just to emphasize that it is C++ code. Looking at SuperpoweredBandpassFilterbank.h, we see that SuperpoweredBandpassFilterbank is a C++ class. It is used in Superpowered.mm by the Superpowered Objective-C++ class, see the filters member, which is a pointer to a SuperpoweredBandpassFilterbank object.
In the project you attempted to build, I see where the Superpowered interface is declared in the bridging header, but I don't see an implementation. The failure to #import SuperpoweredRecorder.h is due to SuperpoweredRecorder.h being a C++ header. The #include should be in your Objective-C++ (.mm) file, it's useless in the bridging header, since Swift can't make sense of C++ anyhow.
Hopefully this is helpful. Welcome to the world of C++.
I'm a bit surprised that you would have to provide prototypes of method.
I used Objective C libraries in my Swift project before and I only had to add the header files in my bridging header.
See example from my project. The bridging header contains just that:
// Use this file to import your target's public headers that you would like to expose to Swift.
//
#import "QTouchposeApplication.h"
#import <FBSDKCoreKit/FBSDKCoreKit.h>
#import <FBSDKLoginKit/FBSDKLoginKit.h>
#import <VungleSDK/VungleSDK.h>
I have a question about using C++ header files in Objective-C++ modules in Xcode. Specifically, why can I #include them in source files but not header files?
Here is a specific example.
I'm using Xcode 7.2.1 and have two projects. The first is a C++ framework I package into "myFramework.framework". It exposes "myFramework.h", which in turn pulls in "myLib.h". At the top of "myLib.h" is an "#include <string>".
The second project is an Objective-C iOS app which consumes the above framework. In this project, "myViewController.mm" (Objective-C++ source) has "#import "myFramework/myFramework.h" at the top and makes reference to things defined in that header file.
At this point all is well and good. It builds and runs with no issues.
When I move the "#import myFramework/myFramework.h" line to "myViewController.h", the compile fails because it cannot locate the "" header dependency.
It doesn't matter if I change the file type for "myViewController.h" to Objective-C++ header from plain old "C Header". Either way, Xcode's header search paths don't look for standard C++ headers.
So my main question is why does it behave this way? Why is a #include/#import treated differently just because it's in a header file?
My second question is if there's some way to make Xcode treat the #include/#import the same when it's in the header file instead of the source file?
Thanks much!
Are you sure that you get the error while compiling the myViewController.mm file?
Check if myViewController.h is imported into some other, non ObjC++ file (and that that one is the file that fails to compile).
I suspect the issue with including C++ headers inside other headers is that an Objective-C source file gets to see the C++ header file, which upsets it.
If you have mixed C++/Objective-C++/Objective-C then you are probably better off only exposing a pure Objective-C interface to other modules in the project and include any C++ header files in the Objective-C++ source files only.
Alternatively make everything Objective-C++ and then you don't need to worry about it at all.
Hopefully this answers your second question as well.
I have been thinking this problem for a while but still no idea about it, if my project is mainly cpp file, should a c file name as .c, or should be named as .cpp to consistent with other .cpp file?
I just list some advantage and disadvantage (in my current knowledge) of using .c (I don't know if the following idea is correct):
advantage of .c:
fast to know it does not contain c++ content (e.g.:class,std::string)
easy to separate from .cpp file by searching name
disadvantage of .c:
not consistent with other files (because other files mostly .cpp)
may need to rename it as .cpp if I want to change the function as using oop or want to add some oop features into it
some scripts or files may need to add *.c as file input if the original version only handles *.cpp, (e.g.: need to add *.c in Android.mk in android jni)
Also I don't know if compiler handles .c and .cpp in different way,also don't know if it affects other behaviour (e.g.:performance,platform or compiler specific issues...), is anyone have idea about it?
Depends what you mean by "C" code.
Are you going to compile it with a C compiler?
Call it file.c
Or do you just mean "C-like" C++ code? C++ code that, at time of writing, happens to also be valid C?
Call it file.cpp
Rule of thumb - name it according to which compiler you intend to use for it. This keeps your makefiles nice and simple.
So if your "C code" is C++ code that could be compiled as valid C but that's not what you are doing, then name it *.cpp and let your makefile invoke the C++ compiler on it.
If your code is actual C, to be compiled with a C compiler, then name it *.c - and remember the (appropriately-#ifdefed) extern "C" in the header file so that C++ built against it can link successfully.
C++ fully supports c code. So the compiler would be just fine with c code in a .cpp file.
And like Quentin mentioned above. If your c code is never used in a c only project I would leave it in an cpp file.
Can I include and make use of header files if I have C++ header and C++ Source?
How can I do so in VB 2008?
eg. I have genlib c++ header and genlib c++ source.
I want to use all functions in source to be accessible in my program when I type #include genlib.h
How can I do it when such headers and source are in bulk and may depend on each other.
eg. StanfordCs106BHeaderandSOurce
And Is there any solution so that I dont have to add any addition dependencies whenever I create a project,just like .
May be copping and pasting in program file
I have added some objective C files and c++ files to an existing iOS project. When I import a .h file of a .mm file into a .h file with a corresponding .m file I get all kinds of errors.
When I change the .m file of the .h file importing the new code to .mm I then get the same previous errors but with new errors regarding the new .mm file.
Im not really sure how to fix this.
I am using ARC if this has any effect.
It complains about namespace (unknown type), also Unknown name issues with an imported .mm file, expected expression error on a statement containing :: in a .h file of a .mm file. What I dont get is that these files work correctly in the project I copied them over from. I only took the source from the project. And have added header search paths to the directory. I also selected create references to the added directories option.
For some reason the files arent in the compile source section, and when I try to add them, the file selector tree doesnt contain these source files I added. The added directory is also blue instead of yellow, but empty.
As you know, C++ code can only be used from .mm files. When the compiler complains about namespace being an unknown type, it typically means that the Objective C compiler is being used when the Objective C++ compiler should be used. More simply: you have a .m file that needs to be a .mm.
Speaking generally, there are two options you can pursue. Every time an Objective C file complains, change it to a .mm. This is a slippery slope, and generally results in your entire project cascading into a giant ball of Objective C++. The other option is to quarantine the C++, so that only a bare minimum of your Objective C files need the .mm extension.
Obviously, the latter is the better choice. The likely cause of the confusion is #importing a header file that contains C++ code from elsewhere in your app that doesn't actually require C++. If the C++ is an implementation detail of an Objective C class, you can try to keep the C++ out of the class' header file by leveraging Class Extensions. Otherwise, you can create an Objective C class whose only purpose is to wrap the C++ in its own implementation, while exposing a clean header file for other classes to consume.
Basically, If you can keep your headers clean, then you won't have to worry about accidentally indirectly #importing some C++ into an unsuspecting compilation unit.