I tend to use the .mm extension by default when creating new classes so that I can use ObjC++ later on if I require it.
Is there any disadvantage to doing this? When would you prefer .m? Does .m compile to a faster executable (since C is generally faster than C++)?
Before Xcode 4.0 (released in 2011), which can use the Clang frontend tool chain for both, the major disadvantage to using .mm over .m for "normal" Objective-C was that compile times are significantly higher for Objective-C++. This is because the C++ compiler takes longer than the C compiler.
A better strategy is to use .m by default. If you need to use Objective-C++ later in development, there is no harm in renaming the file to use a .mm extension. If you so from within Xcode, the project will be automatically updated to use the newly named file.
Of course all of the standard caveats apply once you try to compare Objective-C++ vs. Objective-C performance at run time. Since Objective-C++ is a C++ superset while Objective-C is a C superset, you are dealing with two different languages each with performance tradeoffs at runtime. Given that you're using Objective-X at all, you are likely writing a user-level application (not a systems level app) and the difference in performance between C and C++ wil likely be completely determined by your abilities to code efficient algorithms in each language. If you're a C++ developer, you'll likely code better than in C and visa versa. So, as always, use the appropriate tool for the job.
For reference, you may also be interested in this answer: C vs C++ (Objective-C vs Objective-C++) for iPhone
UPDATE Feb 17, 2012 As of Xcode 4.0 (with LLVM 3.0), Clang has supported Objective-C++. Even C++11 support is quite strong now.
If you only use C features, .mm files should generate code that performs very similar to .m
There is also no downside to renaming a file from .m to .mm later when you desire C++ features
Related
In C, C++ and Objective-C you can compile part of an executable into its own "object file" and use it (and/or a library containing multiple object files) from any other code by including a "header file". Highly-templatized C++ code notwithstanding, a "header" typically contains just the declarations needed to validate the correctness of calling code (and assist the IDE with autocomplete, etc.).
But Swift does not have header files.
Now, apparently it is not currently possible to make a Swift static library, but in the future how would a situation like the above work, wanting to use some existing precompiled code from "new" source code, given that Swift does not have headers?
Would it work something like how [I infer] Java must work, where the compiled form can be introspected enough for the compiler to verify it is being used properly? Does Bitcode in addition to its intermediate representation also provide the necessary "protocol" for retaining such metadata?
If Apple were to port Cocoa to Swift (and keep it closed source), how would it then be "imported" into Swift apps?
Although, really, this question is not anything to do with "closed source" per se but rather trying to understand the boundaries around compilation units in Swift. Based on a similar question for the Go language, mine here could be re-phrased as: can you link to a pre-compiled Swift library without the source?
Well, just consider Apple's Swift libraries. They are closed-source, and you can use them fine and you can see pseudo-"headers" for the stuff in the library in the compiler. The exact mechanism of how this works is not currently publicly documented, but it must exist.
In addition to #user102008, the good new is, Swift will be open sourced by the end of this year, and even ported to Linux by Apple. While we can't guarantee it will always work that way (as Apple has poor records on those kind of issues), people will found suitable solutions within this even if Apple has no interests in doing so.
Even more, afaik, Swift objects were actually Objective-C objects. There'll not be that different to make Swift things work than Objective-C. (More details: http://www.eswick.com/2014/06/inside-swift/) After they were compiled, just do a class dump (or load it into a debugger such as IDA) and you can easily create a .h to make it work like normal static library or a framework.
I made a cocoa touch static library in iOS in which I have C++ classes (.h and .cpp files).
I built the project successfully, but when I include this library (having .a extension) and any .h file, I get a compilation Error.
How can I add this library in my objective-C project and use the C++ classes?
Your problem is likely that the .h header contains C++ code. You should read up on "compilation units". In short, there's no way to tell what language a header file is written in for the compiler. Therefore, it always uses the language of the source file that includes the header. So if you include a C++ header from a .m file, it will not work.
But there is a solution: Apple invented a "new language" it calls Objective-C++ that lets you write both C++ and Objective-C statements in the same file. For every ObjC file that uses a C++ header, you have to change the file name suffix of the source file that uses it from .m (ObjC) to .mm (ObjC++), which means the source files will be able to compile both ObjC and C++ headers.
Of course, you may not want to change all your files to be ObjC++. For one, C++ (and by extension Objective-C++) is a language with much more complex syntax than C and Objective-C, so your compile times will be longer, and also, C++ behaves differently in some aspects than C (and by extension, ObjC++ behaves a bit differently than ObjC).
What people usually do is constrain the C++ parts to their implementation files, and keep C++ out of the header. They write an Objective-C class that "wraps around" the C++ class, and provides methods that call the corresponding C++ methods on the C++ object. Then any ObjC file in your project can include that class, without having to turn on the ObjC++ compiler itself, which internally ("secretly") uses ObjC++ to call the C++ code.
For some useful tricks on how to hide C++ code inside an ObjC class, see Can I separate C++ main function and classes from Objective-C and/or C routines at compile and link?
Most probably you just should rename your .m files which are objective-c specific to .mm files that can accept C++ code (objective-c++).
Second is to check if everything it depends on is properly included before your library header.
Also check the architecture you have built your library for. If you run on an emulator - it should be x86, if for deploying to device - arm.
If you built the .a on the same system, there shouldn't be a problem #includeing its headers and linking against it.
This is probably not a simple question so I am not looking for a definite answer but just some pointers to get me in the right direction.
I have absolutely no experience with C/C++ but have good knowledge of Objective-C. I also don't know much about different compilers and architectures so please be nice if I am talking stupid :)
I have some MatLab code that needs to be ported to Objective-C to run on an iPhone application. My first tentative path to get this done would be to check if MatLab can export the code as a static C/C++ library that I can call from within my Objective-C code.
This seems to be the case but I am not entirely sure what to do next, and what things I need to keep in mind when compiling the library on the MatLab side (i.e. architecture, compatibility, PC vs Mac, etc).
I have been provided with a .DLL and .LIB files which I believe are Windows compiled so they will not be useful for me, is this correct? From working with previous static libraries I can see they all have a .a extension - what do I need to do to get one that is compatible with the iPhone architecture?
And once I get the library compiled, how to I import and use it within my project? Will I just be able to call the public methods directly from within my code?
What else do I need to know or be aware of?
Any help is very much appreciated!
Thanks,
Rog
Static libraries contain binary code tailored for some specific operating system and platform. That means that it will use the OS to internally acquire memory (if it uses dynamic memory) or to perform any other OS specific operation (logging, output).
Even if the generated code was completely OS-agnostic (basic math could be implemented without OS support), the platform is completely different, matlab will generate code for an intel platform and the iPhone runs in an ARM architecture, with a different instruction set calling conventions...
Unless matlab is able to generate static libraries for the iPhone or at the very least for an ARM platform and make it OS-agnostic, you are out of luck.
Are there any open source libraries for doing SNMP GET/SETs using the Objective C/Cocoa Touch (for IPhone)?
Although there is no SNMP implementations in Objective-C (that i an aware of). There are in C & C++.
I've had success at using snmp++v2.8a. Just drop the .h and .cpp files required for the static libsnmp++.a into your x-code iphone project. And make the necessary tweaks for it to build. I had to add: "-D_XPG4_EXTENDED -DGCC -DLINUX" to Project Settings 'Other C++ Flags', and make some changes to the files. Then any file you are using the c++ objects from, rename from .m to .mm, to tell X-Code the file contains a mixture of objective-C and c++.
In my opinion, the C/C++ package called Net-SNMP (has nothing to do with .NET) is the best implementation of an SNMP library for both the manager (client) and the agent (server) sides. I've looked at a lot of them and used a lot of them, and Net-SNMP is the best of the lot. Open source.
I've spent some time working on building one of these for a project.
there's none for obj-c, or at least there weren't when I was looking last summer. there's a bunch of open source ones in c and c# that are a good starting spot for a port (or re-implementation).
I've never heard of one, and the only thing I'm finding on Google is "IP*Works!", but it seems to be a Mac framework (and might not work on iPhone if it's not compiled as a .a file).
Your best bet may be to roll your own. http://cocoabuilder.com has a couple emails in its archives about people asking for SNMP libraries, but no answers were ever received.
The readme included with the new Xcode 3.2.1 this week says the following:
Static code analysis is fully integrated within the Xcode IDE via the Build and Analyze option under the Build menu or via custom build settings
GCC 4.2 is the default system compiler for the 10.6 SDK
The optional LLVM compiler is included using two different front ends - the Clang compiler is a leading-edge parser that offers dramatically improved compile times. For maximum compatibility, the GCC LLVM compiler utilizes the LLVM back-end with the GCC 4.2 parser.
New optional Clang-LLVM 1.0 compiler uses the much faster Clang front-end parser coupled with the LLVM back-end compiler for fast compiles and fast executable code. Many projects will benefit from this compiler combination, although GCC 4.2 is still the system default. The Clang-LLVM 1.0 compiler will fall back to using LLVM-GCC 4.2 when it encounters C++ code.
Our company has existing projects that are pure C, Objective-C, and Objective-C++ for desktop and iphone. Can someone summarize at a high-level the differences between LLVM, GCC, CLANG, CLANG-LLVM, WordFoo et. al. and explain what they are and when we should be using each and for what? It would be nice to have links to more a detailed explanation, but I'm really just looking for a high-level overview.
In a nutshell:
Compilers are basically split into two parts. One being the front-end that contains the parser and semantic analysis for the programming language. The front-end produces some kind of intermediate representation of your code. Then there's the backend which takes the stuff the front-end produced, optimizes it, and eventually generates assembly code.
GCC: well known compiler, contains both front-ends for various languages and back-ends for many processor architectures
LLVM: a set of back-ends for various architectures (and other low-level stuff)
clang: a new front-end for C, Objective-C, and C++; uses the LLVM back-ends. You'll get more readable errors and warnings from your compiler and shorter compile times. You might also encounter incompatibilities or bugs; clang is a very young project.
LLVM-GCC: GCC's front-end with LLVM's back-end. LLVM's back-end is faster than GCC's.
clang's (Objective-)C++ support is far from being complete so it calls llvm-gcc when it encounters a C++ source file. It also contains the static analyzer that is now integrated into Xcode. Some people say LLVM's back-end generates better code than GCC's but your mileage may vary. LLVM also supports link-time optimizations (which you can enable in Xcode's project settings). They may produce faster code.
Apple wants to replace GCC with clang in the future because they have a policy against GPLv3 licensed code (GCC 4.2 is the last version that's licensed under GPLv2).