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.
Related
I want to run a function of Cocoa's Quartz Window Services on Mac called CGWindowListCopyWindowInfo using a library called objc from Rust, is it possible?
I can't figure out how to run function it with send_msg!.
First, you're linking to the Swift version of the API, you really want the objective C version.
Second, Objective-C is for "methods" on objects, that is why send_msg! takes a subject (obj). CGWindowListCopyWindowInfo is part of a "core" service, which means it's pretty much straight C. Now I don't know if there are bindings for that, apparently Servo once maintained CG bindings but it seems like they're deprecated. You can probably BYO as if you were binding to a regular C library (by hand or using bindgen).
I would recommend learning how macOS APIs and frameworks work first, though.
From the Swift documentation:
Any Objective-C framework (or C library) that’s accessible as a module
can be imported directly into Swift. This includes all of the
Objective-C system frameworks—such as Foundation, UIKit, and
SpriteKit—as well as common C libraries supplied with the system.
Where can I find the full list of available modules? I'm particularly interested in the common C libraries part.
It's the same modules that can be imported in Objective-C using the #import statement (except the Swift module, which is the Swift standard library that is only available in Swift and is always imported in Swift anyway). So what you can do to discover them is:
Open an Objective-C project, turn support for modules on in build settings
type #import ... and type some letter, delete it, and the autocomplete should show you a list of all the modules you can import.
From what I can tell, besides the standard Cocoa system frameworks (like Foundation), the only potentially useful ones are:
Darwin - most of the C standard library, plus many POSIX things
ObjectiveC (also imported by Foundation) - the Objective-C runtime library (#import <objc/*>)
Dispatch (also imported by Foundation) - the dispatch library (#import <dispatch/dispatch.h>)
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?
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/
Objective-C has an amazing API for reading and changing its own runtime environment, but I can only find documentation for this API from Apple. Is the API only available on machines running a Darwin OS or is it actually part of Objective-C in general?
If its specific to Darwin is it at least available in the GNUstep framework?
Edit - What I'm Looking for Specifically
Specifically I am writing an XSD based serializer/deserializer and I would like to be able to create/modify class definitions based on XSD documents that are parsed during runtime, in order to make the framework more intuitive.
All the versions of Objective-C that I've seen have some facilities for mucking about with introspection and/or dynamic generation of classes at runtime.
The details will be different per different runtime and they may not all have feature parity (example; the apple runtime has blocks and that hasn't been ported everywhere).
Your updated question indicates you specifically wish to add/modify class definitions.
Following the reference Objective-C Compiler and Runtime FAQ mentioned above in the comments we find about libobjc2 which is part of GUNStep, and it’s runtime.h contains the method:
Class objc_allocateClassPair(Class superclass, const char *name, size_t extraBytes);
for creating classes - this appears to be the same as the one in Cocoa.
You might find Mike Ash's Creating Classes at Runtime in Objective-C helpful.
HTH