As I understand correctly, besides the fact that Objective-C language is a strict superset of a "clean" C, added OOP paradigm is simulated by a set of functions partially described in Objective-C Runtime Reference.
Therefore, I'm expecting a possibility to somehow compile Objective-C code in an intermediate C/C++ file (maybe with some asm inserts).
Is it generally possible ?
You could use the clang rewriter to convert to C++. Not aware of a way to go to C though.
The rewriter is available via the "-rewrite-objc" command line option.
As far as I know, there is no software that preprocesses Objective-C code into intermediate C code.
But you could write your Objective-C program entirely in C by calling directly into the Objective-C runtime. The trouble is just that the code might vary between implementations or even different versions of the same runtime.
The question is, is it actually worth the trouble?
Related
Is Microsofts C++/CLI built on top of the C++ Standard (C++98 or C++11) or is it only "similar" and has deviations?
Or, specifically, is every ISO standard conforming C++ program (either C++98 or C++11), also a conforming C++/CLI program?
Note: I interpret the Wikipedia article above only comparing C++/CLI to MC++, not to ISO Standard C++.
Sure, it is an extension to C++03 and can compile any compliant C++03 program that doesn't conflict with the added keywords. The only thing it doesn't support are some of the Microsoft extensions to C++, the kind that are fundamentally incompatible with managed code execution like __fastcall and __try. MC++ was their first attempt at it, kept compatible by prefixing all added keywords with underscores. The syntax was rather forced and not well received by their customers, C++/CLI dropped the practice and has a much more intuitive syntax. Stanley Lippman of C++ Primer fame was heavily involved btw.
The compiler can be switched between managed and native code generation on-the-fly with #pragma managed, the product is a .NET mixed-mode assembly that contains both MSIL and native machine code. The MSIL produced from native C++ source is not exactly equivalent to the kind produced by, say, the C# or VB.NET compilers. It doesn't magically become verifiable and doesn't get the garbage collector love, you can corrupt the heap or blow the stack just as easily. And no optimizer love either, the MSIL gets translated to machine code at runtime and is optimized just like normal managed code with the time restrictions inherent in a jitter. Getting too much native C++ code translated to MSIL is a very common mistake, the compiler hides it too well.
C++/CLI is notable for introducing syntax that got later adopted into C++11. Like nullptr, override, final and enum class. Bit of a problem, actually, it begat __nullptr to be able to distinguish between a managed and a native null pointer. They never found a great solution for enum class, you have to declare it public to get a managed enum type. Some C++11 extensions work, few beyond the ones it already had, auto is fine but no lambda expressions, quite a loss in .NET programming. The language has been frozen since 2005.
The C++/CX language extension is notable as well, one that makes writing C++ code for Store and Phone apps palatable. The syntax resembles C++/CLI a great deal, including the ref class and hats in the syntax. But with objects allocated with ref new instead of gcnew, the latter would have been too misleading. Otherwise very different from C++/CLI at runtime, you get pure native code out of C++/CX. The language extension hides the COM interop code that's underneath, automatically reference-counting objects, translating error codes into exceptions and mapping generics. The resemblance to C++/CLI syntax is no accident, they basically perform the same role. Mapping C++-like syntax to a foreign type system.
CLI is a set of extensions for standard C++. CLI has full support of standard C++ and adds something more. So every C++ program will compile with enabled CLI, except you are using a CLI reserved word and this is the weakness of the extension, because it does not respect the double underscore rule for extensions (such reserved words has to begin with __).
You can deactivate those extensions in the GUI by:
Configuration Properties -> General -> Common Language Runtime Support
Even Bjarne Stroustrup calls CLI an extension:
On the difficult and controversial question of what the CLI binding/extensions to C++ is to be called, I prefer C++/CLI as a shorthand for "The CLI extensions to ISO C++". Keeping C++ as part of the name reminds people what is the base language and will help keep C++ a proper subset of C++ with the C++/CLI extension
Language extensions could always be called deviations from the standard, because it will not compile with a compiler without CLI support (e.g. the ^ pointer).
I'm just curious, does Objective-C compile into C code or does the Objective-C runtime work like a layer of abstraction above the program? Sorry in advance if I don't know what I'm talking about!
A little history lesson:
Both C++ and Objective C originally started out as preprocessors for C. So you typed in your ObjC code, and it would effectively run a search-and-replace over the code and translate the Objective-C commands into straight C code that used a little helper library (the stuff in objc/runtime.h and similar files).
As the language started getting more complex, it was changed into a full parser that replaced/extended the parser in a C compiler with/into one specific to Objective-C. So while it would be perfectly possible to compile Objective-C into straight C, current ObjC compilers don't do it that way anymore.
Compiling Objective-C into C doesn't make sense, because then it would need to parse the C code and compile it.
Objective-C compiles into machine code. Remember that the language (Objective-C, C, C++) only defines the rules to correctly write code. The compiler checks to see if your code is correct and compiles it, i.e., translates it into executable code.
Also, don't confuse Objective-C language, and the Objective-C runtime. The language defines the syntax, the runtime allows the compiled code to run (in a way it's like you say, it is a layer, but it doesn't get compiled every time with your program).
EDIT:
The runtime implements the core behavior of a computer language. The runtime contains compiled code of functions in a similar way a library does. In C, for example, when you call printf() your code is compiled into machine code and linked with the library containing the implementation of that function; what this machine code does is passing parameters to the executable code in the library.
Speaking strictly from Xcode, the code is compiled with the LLVM compiler. Here is more information about the LLVM compiler. You'll be able to find more information about how the LLVM compiler works online through simple Google searches.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is there something like Matlab's eval statement in Objective-C 2.0?
Is there an eval function (as in lisp, javascript, python, ruby...) in Objective-C?
What I mean by eval is a function that can take in arbitrary Objective-C code (possibly having class definitions, side effects, instrospection, etc) as a string (not a block or an NSInvocation or IMP or something like that), and evaluate each expression, respecting the current runtime environment state, side effects, class definitions, etc.
If not, is it possible to implement within the confines of the existing runtime?
Neither the language nor Apple's frameworks directly support such a thing. However, one of the goals of LLVM is to be an embeddable compiler suite. I'm pretty sure it can generate executable code right into memory. The hard part would be providing that code with access to the pre-existing environment of the calling code. For example, compiling code which references a local variable or something like that.
(Mind you, this approach is forbidden for the iOS App Store, but it could maybe be workable on Mac OS X.)
Absolutely not. Objective-C is a fully compiled language. Only interpreted languages can do that sort of thing.
No. Code eval is the feature for dynamic language. Although objective-C has dynamic feature , and even Cocoa runtime , it is still considered as a static language (generally).
Where can i find a concrete document or a dos and donts documentation on using C++ with Objective-C?
Apple seems to have removed that document from their website and i am all puzzled with collating bits of information from blogs and questions posted here.
Anyone can guide about the same.
When do we use .mm file, while mixing syntax or while using an object in .m file which belongs to a C++ class ?
While passing objects between functions belonging to two different language like passing objective-c object to a function in cpp file is it necessary to collect it in void * or can I use (ObjectiveC inteface)*?
You need to use Objective-C++ whenever you are either #include/#importing or directly writing both Objective-C and C++ code in the same file. It's usually obvious with explicit code; the #includes are often less so, and you need to take care to avoid "leaking" one of the languages into too much of the other. Your example of #importing a C++ header file is clear-cut: you can only do that with Objective-C++. Note that if your Cplusplus was a struct type, you could forward-declare it as such instead of #importing a C++ header.
If you do this in a header, it will "poison" the header to only work in that mode. You'll need to actively avoid this, or your whole project will soon end up with only .mm files. I have documented some techniques in this article and previously, in this earlier article. For newer versions of Objective-C, you can also add ivars to classes in category extensions. This means you can define C++-typed ivars in your .mm file, not the header, which allows .m files to #import it.
For your second question (Please only ask one question at a time): the id type is defined in the objc.h header file in terms of C and thus will work in both Objective-C and C++. Likewise, the Objective-C runtime API is exposed in terms of C functions, which will work from C++, too. If you actually want to send messages and access properties on Objective-C objects with the canonical syntax from C++ code, you'll need to switch that file to Objective-C++.
Use .mm files when you have a c++ syntax in your code or when including file(s) which contain c++ code.
Mixing C++ with objective-c may be a bit confusing but if you think pointer-wise than it is not a big deal. Treat C++ object instance methods as you would in C++ and the same goes for objective c objects.
Or in more practical terms: If I compile a file containing just Obj-C code or just C++ code under Objective-C++, can I be sure they'll behave exactly as they did before? In what ways might they differ?
More or less, that is true; anything that compiles under either C++ or Objective-C will compile with the Objective-C++ compiler.
However, there are some edges where this doesn't hold true and a handful of behavioral differences.
I'm not aware of any specific at-runtime behavioral differences, though. The differences should generally show up during compilation and mostly as problems caused by C++'s "enhanced" notion of types.
Operator overloading can be exceedingly problematic, however. If a body of code makes extensive use of operator overloading, that can cause issue when mixing Objective-C in for the first time. But, again, typically as compiler warnings and rarely as at-runtime bugs.
Objective-C is a superset of C only. You can mix C++ with Objective-C - that is called Objective-C++ - however there are certain rules that you have to follow.
Here you can see all the rules that have to be followed: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html
EDIT: This is a quote from the developer website: "Apple’s Objective-C compiler allows you to freely mix C++ and Objective-C code in the same source file. This Objective-C/C++ language hybrid is called Objective-C++. With it you can make use of existing C++ libraries from your Objective-C applications.".
So it clearly says, that the mixture of C++ and Objective-C is called Objective-C++, but that is not a superset of C++, but it's two languages that with some rules can be used together. (For instance you can't mix objective-c and c++ classes during inheritance, but there are others as well.)
I guess there's at least one example of valid Objective-C code that's not valid Objective-C++:
void SayHello()
{
char* this = "hello!";
printf("%s", this);
}
(what someone would be doing naming a variable 'this', I don't know)