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)
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.
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?
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.
What is the Objective-C equivalent of the Java Language Specification or the C++ Standard?
Is it this:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html ?
(I'm just looking for an (official) authoritative document which will explain the little nitty-gritties of the language. I'll skip the why for now :)
Appendix A of the document you linked to is a description of all of the language features, which is the closest we have to a specification (Appendix B used to be a grammar specification, but they've clearly removed that from the later versions of the document).
There has never been a standardisation of Objective-C and it's always been under the control of a single vendor - initially StepStone, then NeXT Computer licensed it (and ultimately bought the IP) and finally Apple consumed NeXT Software. I expect there's little motivation to go through the labourious process of standardisation on Apple's part, especially as there are no accusations of ObjC being an anticompetitive platform which standardisation could mitigate.
There is none. The link you provided is the only 'official' documentation, which is essentially a prose description, and not a rigorous language specification. Apple employees suggest that this is sufficient for most purposes, and if you require something more formal you should file a bug report (!). Sadly, the running joke is the Objective-C standard is defined by whatever the compiler is able to compile.
Many consider Objective-C to be either a "strict superset" or "superset" of C. IMHO, for 'classic' Objective-C (or, Objective-C 1.0), I would consider this to be a true statement. In particular, I'm not aware of any Objective-C language addition that does not map to an equivalent "plain C" statement. In essence, this means the Objective-C additions are pure syntactic sugar, and one can use the C standard in effect to reason about the nitty gritty. I'm not convinced that this is entirely true for Objective-C 2.0 with GC enabled. This is because pointers to GC managed memory need to be handled specially (the compiler must insert various barriers depending on the particulars of the pointer). Since the GC pointer type qualifiers, such as __strong, are implemented as __attribute__(()) inside gcc, this means that void *p; and void __strong *p; are similarly qualified pointers according to the C99 standard. The problems that this can cause, and even the ability to write programs that operate in a deterministic manner, are either self evident or not (consult your local language lawyer or compiler writer for more information).
Another problem that comes up from time to time is that the C language has continued to evolve relative to the Objective-C language. Objective-C dates back to the mid 1980's, which is pre-ANSI-C standard time. Consider the following code fragement:
NSMutableArray *mutableArray = [NSMutableArray array];
NSArray *array = mutableArray;
This is legal Objective-C code as defined by the official prose description of the language. This is also one of the main concepts behind Object Oriented programming. However, when one considers those statements couched from the perspective of "strict superset of C99", one runs in to a huge problem. In particular, this violates C99's strict aliasing rules. A standards grade language specification would help clarify the treatment and behavior of such conflicts. Unfortunatly, because no such document exists, there can be much debate over such details, and ultimately result in bugs in the compiler. This has resulted in a bug in gcc that dates all the way back to version 3.0 (gcc bug #39753).
Apple's document is about the best you're going to get. Like many other languages, Objective-C doesn't have a formal standard or specification; rather, it is described mostly by its canonical implementations.
Further resources include:
The Objective-C Language and GNUstep Base Library Programming Manual.
The NeXT developers library
Apple (now) using clang of the llvm.org project.
Some of the language elements are defined in this context
e.g. Objective-C literals --> http://clang.llvm.org/docs/ObjectiveCLiterals.html
But i didn't found a clear overview of all elements.
--- updated --
The source of Apples clang is available (as open source) here:
http://opensource.apple.com/source/clang/