I'm guessing I would only use UIKIT_EXTERN if there is a chance of C++ code in my project that may use the variable.
If this is the case wouldn't it just be safe to declare all your externally available constants with UIKIT_EXTERN?
How come I don't see this more?
I'm guessing I would only use UIKIT_EXTERN if there is a chance of C++ code in my project that may use the variable.
Right. This is the primary reason. This happens because C and C++ symbols use different naming conventions.
There is a less common reason: UIKIT_EXTERN also specifies default visibility.
Note: More generally, "symbol" -- not "variable" since extern could also be applied to constants, functions, et cetera.
If this is the case wouldn't it just be safe to declare all your externally available constants with UIKIT_EXTERN?
Short Answer: It would be good practice (read: 'safe') to use this form, but it's usually best for your library to declare its own equivalent of UIKIT_EXTERN.
UIKIT_EXTERN is a UIKit declaration. Libraries should not depend on this declaration, and just define their own synonym -- and many do, but I find it is more common in C and C++ because these programs often target more platforms and a good percentage of iOS programs are not developed to support other platforms. Otherwise, Objective-C programs which do not require UIKit could depend on UIKit because of this declaration, so they would have to import UIKit (so that UIKIT_EXTERN's declaration is visible).
Furthermore, UIKit is not available on all platforms where iOS programs could be run (i.e. it could be C, C++, or depend on Foundation and portable to OS X). So even if somebody (curiously) insisted declaring their own were a bad idea, choosing CF_EXPORT (CoreFoundation's equivalent) would be a more portable option because it could also be used for C, C++, and on OS X. Furthermore, your library would only need to include CoreFoundation (at minimum).
If your library depends on UIKit and the framework's must be imported by your library, then it is highly unlikely that using their synonym would cause a problem for your library.
But this is a pretty big set of conditions -- it's very easy for your library to simply declare its own. In short, a well written and portable library should (almost) never use 'raw' extern, nor should unnecessary library dependencies be a good thing (UIKit in this case).
It would be a bad design choice to use UIKIT_EXTERN unless your library were inseparable from UIKit -- such as a collection of UIView subclasses.
If your library just deals with Foundation types, then importing UIKit means that your library will be (unnecessarily) unusable on OS X (until that UIKit import is removed).
People who haven't much experience using C++ with C (including supersets) may not know that symbol names are different, so they may just use extern directly. Finally, some programs were not initially designed to be used outside of C and/or Objective-C translations, so they may have simply used extern without conditional decoration for the translation.
Finally, UIKIT_EXTERN may not do exactly what you expect/want since it specifies:
an extern C symbol
which has default visibility
For library symbols visible to ObjC translations, this is perfect.
It is primarily to make a class visible outside the current library/executable. It is likely you won't need to use it, unless you are developing libraries.
As you point out, the main advantage of using the macro is that it builds in the extra C++ extern protection, so if you are indeed developing a library, this is definitely a good idea (otherwise the caller has to be aware and add the extern C declaration).
This is covered in the ADC documentation here:
Symbol Visibility
and is fairly well answered here:
UIKIT_EXTERN_CLASS and UIKIT_EXTERN, for what these 2 constants are?
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).
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)
I've found references online that talk about two different root classes for ObjC, either objc/Object.h or Foundation/NSObject.h. They require different compiler flags (-lobj vs. -lobjc -framework Foundation, and have different selectors for initializing & releasing objects. Is NSObject a replacement, or do they have different applications? Obviously NSObject.h would be better for NextStep-type stuff, but does Object.h have advantages that would make it better in certain situations?
FWIW, the updated FAQ from comp.lang.objective-c seems to indicate the NSObject.h is correct; an older version mentions Object.h
My understanding of the situation is there are two runtime libraries for Objective-C. Apple's library, which uses NSObject, and the GNU library which uses Object. If you are developing for an Apple platform, use their runtime. If you're developing for a non-Apple platform, you use the other.
What is the Objective-C equivalent of Java packages? How do you group and organize your classes in Objective-C?
Question 1: Objective-C equivalent of Java packages?
Objective-C doesn't have an equivalent to Java packages or C++ namespaces. Part of the reason for this is that Objective-C was originally a very thin runtime layer on top of C, and added objects to C with minimum fuss. Unfortunately for us now, naming conflicts are something we have to deal with when using Objective-C. You win some, you lose some...
One small clarification (although it's not much for consolation) is that Objective-C actually has two flat namespaces — one for classes and one for protocols (like Java's interfaces). This doesn't solve any class naming conflicts, but it does mean you can have a protocol and class with the same name (like <NSObject> and NSObject) where the latter usually adopts ("implements") the former. This feature can prevent "Foo / FooImpl" pattern rampant in Java, but sadly doesn't help with class conflicts.
Question 2: How to [name] and organize Objective-C classes?
Naming
The following rules are subjective, but they are decent guidelines for naming Objective-C classes.
If your code can't be run by other code (it's not a framework, plugin, etc. but an end-user application or tool) you only need to avoid conflicts with code you link against. Often, this means you can get away with no prefix at all, so long as the frameworks/plugins/bundles you use have proper namespaces.
If you're developing "componentized" code (like a framework, plugin, etc.) you should choose a prefix (hopefully one that's unique) and document your use of it someplace visible so others know to avoid potential conflicts. For example, the CocoaDev wiki "registry" is a de facto public forum for calling "dibs" on a prefix. However, if your code is something like a company-internal framework, you may be able to use a prefix that someone else already does, so long as you aren't using anything with that prefix.
Organization
Organizing source files on disk is something that many Cocoa developers unfortunately gloss over. When you create a new file in Xcode, the default location is the project directory, right beside your project file, etc. Personally, I put application source in source/, test code (OCUnit, etc.) in test/, all the resources (NIB/XIB files, Info.plist, images, etc.) in resources/, and so on. If you're developing a complex project, grouping source code in a hierarchy of directories based on functionality can be a good solution, too. In any case, a well-organized project directory makes it easier to find what you need.
Xcode really doesn't care where your files are located. The organization in the project sidebar is completely independent of disk location — it is a logical (not physical) grouping. You can organize however you like in the sidebar without affecting disk location, which is nice when your source is stored in version control. On the other hand, if you move the files around on disk, patching up Xcode references is manual and tedious, but can be done. It's easiest to create your organization from the get-go, and create files in the directory where they belong.
My Opinion
Although it could be nice to have a package/namespace mechanism, don't hold your breath for it to happen. Class conflicts are quite rare in practice, and are generally glaringly obvious when they happen. Namespaces are really a solution for a non-problem in Objective-C. (In addition, adding namespaces would obviate the need for workarounds like prefixes, but could introduce a lot more complexity in method invocation, etc.)
The more subtle and devious bugs come from method conflicts when methods are added and/or overridden, not only by subclasses, but also be categories, which can cause nasty errors, since the load order of categories is undefined (nondeterministic). Implementing categories is one of the sharpest edges of Objective-C, and should only be attempted if you know what you're doing, particularly for third-party code, and especially for Cocoa framework classes.
They use long names...
Article on coding style & naming in Cocoa / Objective-C
Discussion whether Obj-C needs namespaces (deleted, archive here)
See
What is the best way to solve an Objective-C namespace collision?
for a discussion of how Objective-C has no namespaces, and the painful hacks this necessitates.
Unfortuantely objective c doesn't have any equivalent to namespace of C#,c++ and package of java....
The naming collisions could be solved by giving contextual name for example if u gonna give a name to method it should imply the class and module that it comes in so that...these problems could be avoided.
Go through the following url to know more on naming convention as advised by apple
http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/ProgrammingWithObjectiveC/Conventions/Conventions.html
What about something like this (inside a directory)?
#define PruebaPaquete ar_com_oxenstudio_paq1_PruebaPaquete
#interface ar_com_oxenstudio_paq1_PruebaPaquete : NSObject {
and importing it like this:
#import "ar/com/oxenstudio/paq1/PruebaPaquete.h"
PruebaPaquete *p = [[PruebaPaquete alloc] init];
and when you have name collision:
#import "ar/com/oxenstudio/paq1/PruebaPaquete.h"
#import "ar/com/oxenstudio/paq2/PruebaPaquete.h"
ar_com_oxenstudio_paq1_PruebaPaquete *p = [[ar_com_oxenstudio_paq1_PruebaPaquete alloc] init];
ar_com_oxenstudio_paq2_PruebaPaquete *p2 = [[ar_com_oxenstudio_paq2_PruebaPaquete alloc] init];
Well, I think all the other answers here seem to focus on naming collisions, but missed at least one important feature, package private access control that java package provides.
When I design a class, I find it is quite often that I just want some specific class(es) to call its methods, b/c they work together to achieve a task, but I don't want all the other unrelated classes to call those methods. That is where java package access control comes in handy, so I can group the related classes into a packaged and make those methods package private access control. But there is no way to do that in objective c.
Without package private access control I find it is very hard to avoid people writing code like this, [[[[[a m1] m2] m3] m4] m5] or [a.b.c.d m1].
Update: Xcode 4.4 introduced "An Objective-C class extension header", in my opinion, that is in some way to provide "package private access control", so if you include the extension header, you can call my "package private" methods; if you only include my public header, you can only call my public API.