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).
Related
In this tutorial on how to use CocoaPods I am having trouble understanding the following paragraph:
Unlike Objective-C, the standard Swift runtime libraries aren’t
included in iOS! This means your framework must include the necessary
Swift runtime libraries. As a consequence, pods written in Swift must
be created as dynamic frameworks. If Apple allowed Swift static
libraries, it would cause duplicate symbols across different libraries
that use the same standard runtime dependencies.
Here are my questions:
What exactly are the "standard Swift Runtime Libraries"? Is the Swift Standard Library one such standard swift run time library, would a framework I write in swift be considered a swift run time library?
What exactly does "Swift runtime libraries are not included in iOS" mean? I guess I am having trouble inferring what "iOS" refers too.
Any additional insight, links, resources or explanations regarding this paragraph would be greatly appreciated!
Edit:
After reading the runtime library wiki article I am no longer confused about Q1. The following paragraph clarified this for me:
The concept of a runtime library should not be confused with an
ordinary program library like that created by an application
programmer or delivered by a third party, nor with a dynamic library,
meaning a program library linked at run time. For example, the C
programming language requires only a minimal runtime library (commonly
called crt0), but defines a large standard library (called C standard
library) that has to be provided by each implementation.
However I am still confused about Q2.
Objective C has a stable (unchanging) runtime library, so it makes sense for there to be one shared copy of the library, provided by the OS (macOS/iOS), available to all applications that need it. In contrast Swift is a rapidly evolving language, which means that its runtime library undergoes vast changes between versions. Because of this, Xcode bundles in a copy of the Swift runtime library as part of each app, to ensure that a copy of the correct version (the version the app uses) of the runtime library is available to the app.
Swift Standard Library vs Swift Run Time Library
[Swift Standard Library]
Swift Run Time Library is a part of Swift Standard Library
Before iOS v12.2 there were not ABI[About] stability on iOS level, that is why you could see a lot of frameworks(Swift standard library[About]) inside each built target
Also you are able to adjust it via Always Embed Swift Standard Libraries(ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES) for targets before iOS v12.2
I'm trying to figure out if the ASM code for the function neon_asm_convert() in the example here will run on all armv7/armv7s/arm64 processors (ie., iPhone 4S/5/5S).
Unfortunately, I don't own all of these devices, so a simple run-test is out of the question.
However, I'm developing an app (testing it only using armv7) which uses the __asm__() from the neon_asm_convert(), and I would like to find out if the ASM code will also run on arm64.
I think I read that ASM code that runs on armv7/armv7s won't run on arm64 but I can't seem to find that reference anymore.
Does anyone have any pointers that cold help me out?
Looks like it's not going to run on arm64. As this answer says:
arm64 is a new ISA. The actual NEON instructions and register layout are entirely new. You will need to re-write or adapt assembly code for the new architecture.
As Tomer said, no. arm64 is a new architecture with a new instruction syntax and register layout.
However, fast implementations of this sort of colorspace conversion are available in the SDK as part of the Accelerate.framework. Except in special circumstances, you shouldn’t need to write your own assembly code for this. Specifically, you can use the vImageConvert_AnyToAny function, which provides high-performance implementations of this and many, many other common conversions that work on all of the architectures that Apple ships (armv7, armv7s, arm64, i386, x86_64).
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.
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
i'm using windows xp what would be a good c compiler?
i want to learn c so that i can better understand the objective-c language for the iphone.
i have a great background in php so hopefully something will make sense
ps:
what sections should i put more focus on when learning c in getting prepared for objective-c?
thanks
Duplicate:
c compiler for windows
C/C++ Compiler for windows
Which C Compiler do you recommend for windows
GCC is a free, open source, high quality, compiler. You can get it with cygwin.
Microsoft makes a C compiler that comes with Visual Studio, which is Microsoft's integrated development environment. You can download the "Express" edition of Visual C++ to give it a try.
Also, Intel makes a good compiler.
The iphone uses the gcc compiler. This is available for windows using MinGW/MSYS or other compatibility packages.
Apple has Objective-C tutorials which assume very little C experience; I'd be tempted to just dive in. If you get stuck, then get K&R. (I don't know if php has types and pointers, otherwise you'll get stuck straight away)
Visual C++ express is free, has a really nice IDE and compiles C code.
I'd use gcc by downloading cygwin.
Gcc is the way, you can install mingw which is a native windows port.
I also recommend gcc, but don't get too used to GNU extensions such as asprintf() if you want to write portable code. On some systems, strdup() is lacking, amongst many others. The compiler itself won't spoil you, but glibc will.
On the one hand you have POSIX, on the other hand you have ISO/c89/c99, then you have gcc.
I highly recommend gcc, with the above warnings in mind while you continue to explore other compilers. For instance, it can be fun to code around the limits of Lestes if you enjoy dabbling in C++.
In any event, gcc is very powerful, boasts superior optimizations and can be so -pedantic that you think its out to get you. But, don't forget about portable code .. or where/if portability kludges are actually appropriate.
Cygwin is also highly recommended, as DasBoot posted.
You could have a look at this free e-book Programming in C in 7 days as a starter where they use Dev-CPP for windows
Note
It includes only the first 7 lessons of the more complete e-book “Quickly
Learn Programming in C”
Normally I would recommend Pelles C for programming C in windows. It is a good user friendly programming environment that has the best c99 compliance that i've seen... However, here I'm going to tell you that you should use gcc right off but not on windows. Use Linux (maybe Ubuntu?).
The reason I say to use gcc on Linux is because you want to develop for the iphone. I would suggest getting comfortable with the tools you are likely to use. I don't imagine you using the official iphone sdk (you'd need a Mac for that) so I think you'll be using the free tool chain. It does not compile on windows so switch to a supported platform and get comfortable with the tools.
I personally recommend MinGW. You can download it off SourceForge. It even works on a 64 bit configuration. I don't think it supports objective C. However, I found it useful while running C code on windows.
I don't have any idea about objective C and what parts of C you need to focus on while learning so as to make the transition easy. I'll leave that to someone with more experience.
gcc included in cygwin is a perfect first choice if you want to learn C on your Window XP platform. cygwin/gcc includes a basic Objective-C environment.
Anyway if you want to target iPhone, the best move would be to change to a Mac platform (which can natively run XP for smoothing the switch) in order to get Xcode, the Mac and iPhone development environment. You will also be able to learn CocoaTouch, the iPhone OS.
In parallel, you can register to the iPhone Dev Center for accessing all resources for learning iPhone programming.
If you're after a compiler that can compile both C and Objective-C, a GCC port to Windows is probably your best bet.
When learning C, concentrate on pointers, arrays, strings and memory management - those are the things that will trip you up coming from a managed environment of any kind.
The best thing about gcc is that it has a lot of features and supports the latest language standard. But for fast compilation and a nice programming environment you can't beat Lcc-Win32.
GCC is the cheapest compiler, Intel the fastest, MSVC the most featured.