|
Archive-name: Objective-C/answers
Version: $Id: answers,v 3.64 1998/09/17 12:51:31 tiggr Exp $ See reader questions & answers on this topic! - Help others by sharing your knowledge Answers to FREQUENTLY ASKED QUESTIONS concerning Objective-C This is the first in a series of three informational postings concerning comp.lang.objective-c. This first part answers FAQs; the second part lists available class libraries and the third part is a simple sample Objective-C program. This document answers the following questions: 1 What is Objective-C? 2 What exactly is it that makes Objective-C have `classes similar to Smalltalk', and what are the resulting capabilities of Objective-C? 3 What are the differences between Objective-C and C++? 4 What are the differences between Objective-C and Java? 5 What are the `nice features' of Objective-C? 6 What are some problems of the language and how can I work around them? 7 What object encapsulation does Objective-C provide? 8 What are protocols? 9 Does Objective-C employ garbage collection? 10 How do I debug Objective-C using an unaware gdb? 11 I get this `Floating exception'... 12 Why am I lectured by gcc about `#import'? 13 What written information concerning Objective-C is available? 14 History 15 Major compilers 16 Compiler differences 17 Objective-C support per platform 18 What are the newsgroups or mailing lists to read? 19 Are there any FTP sites with Objective C code? Where? 20 Is there any information on the Net concerning Objective-C? 21 For more information... (To find a question search on the question number starting a line.) 1 What is Objective-C? Objective-C is an object oriented computer programming language. It is a superset of ANSI C and provides classes and message passing similar to Smalltalk. Objective-C includes, when compared to C, a few more keywords and constructs, a short description of which follows. For a complete example see part 3 of this FAQ. `@interface' declares a new class. It indicates the name of the class, the name of its superclass, the protocols adhered to (see Q7), the layout of the instance variables (similar to the definition of a struct, but including encapsulation information (see Q6)) and declares the methods implemented by this class. A class' interface usually resides in a file called `<classname>.h'. `@implementation' defines a class. The implementation is no more than a collection of method definitions. Without an implementation, a class does not exist at run time. The implementation of a class usually resides in a file called `<classname>.m'. A category is a named collection of method definitions which are added to an existing class, possibly at run time. Thus, you use a category to add methods to a class. Some Objective-C implementations allow a category to even replace methods. Objective-C includes the predefined type `id' which stands for a pointer to some object. Thus, `id obj;' declares a pointer to an object. The actual class of the object being pointed to is almost irrelevant, since Objective-C does run-time binding. `-message;' declares a method called `message'. The `-' indicates that the message can be sent to objects. A `+' instead indicates the message can be sent to class objects. A method is similar to a function in that it has arguments and a return value. The default return type is `id'. If a method has nothing useful to return, it returns `self', which is a pointer to the object to which the message was sent (similar to `this' in C++). [obj message], [obj message: arg1] and [obj message: arg1 with: arg2] are examples of sending a message to the object OBJ with 0, 1 and 2 arguments respectively. The name of the message is called the selector. In this example, the selectors are: `message', `message:' and `message:with:', respectively. 2 What exactly is it that makes Objective-C have `classes similar to Smalltalk', and what are the resulting capabilities of Objective-C? Objective-C is as close to Smalltalk as a compiled language allows: * Much of the syntax, i.e. both Smalltalk and Objective-C use method names like `a:method:name:'. In Objective-C, the message sending construct is enclosed in square brackets, like this: [anObject aMessage: arg] whereas Smalltalk uses something like anObject aMessage: arg * The basic class hierarchy: single inheritance with the `Object' class as the root of the tree. * Most method names in the Object class are the same like, for example, `respondsTo:'. What is called `doesNotUnderstand:' in Smalltalk is unchanged in the POC, but it is called `doesNotRecognize:' in GNU and Apple Objective-C. * Smalltalk normally uses `doesNotUnderstand:' to implement forwarding, delegation, proxies, etc. In [GNU, Apple] Objective-C, such functionality is implemented by `forward::'. * Objective-C has class objects and meta classes mostly like Smalltalk. * You can add or delete methods and classes at runtime. A subclass can pose as its superclass. * Objective-C does not have class variables like Smalltalk, but pool variables and globals are easily emulated via static variables. * Objective-C is compiled---Smalltalk is only partially compiled. The current Objective-C implementations are all *much* faster than any Smalltalk. For example ParcPlace Smalltalk-80/4 is at least 3 times slower than both the GNU and NeXT Objective-C's. (This was measured using the Self/Smalltalk benchmark suite available by FTP from `self.stanford.edu:pub/Self-2.0.1'.) The big difference of course is that Objective-C is a hybrid between Smalltalk and C. One can choose to represent a string as a `char *' or as an object, whereas in Smalltalk everything is an object. This is one reason for Objective-C being faster. On the other hand, if every bit of information in an Objective-C program would be represented by an object, the program would probably run at a speed comparable to Smalltalk and it would suffer from not having optimizations performed on the basic classes, like Smalltalk can do. 3 What are the differences between Objective-C and C++? C++ is a multi-paradigm language; Objective-C is object orientation on top of C. In this answer, only the OO aspects of both languages will be discussed. In Objective-C, the value of a variable denoting an object is always a reference to the object. In C++ it is, in addition, possible for the variable's value to be the actual object. In Objective-C, all method invocations are dynamically bound. In C++, invocations of virtual member functions are dynamically bound. Other (non-virtual) member functions are more like scoped normal functions with a different syntax. In Objective-C, the dynamic binding is safe: it will be signaled if an object does not implement the requested method; in C++, the results will be unpredictable. In Objective-C, the safe dynamic binding mechanism underlies method forwarding and easy delegation. The selector type and perform: methods further increase the usefulness of dynamic binding. Objective-C only allows single inheritance, with the Object class residing at the root of the inheritance tree. C++ allows multiple inheritance where direct superclasses must be distinct and conspicuous use of `virtual' defines whether a repeatedly inherited superclass is shared or repeated in the subclass. In Objective-C, static typing is optional, though commonly used; in C++ static typing is mandatory. In C++ (member) functions can be overloaded on argument types. Operators can be overloaded too. Both are not possible in Objective-C. Other differences include C++' implicit invocation of constructor and destructor functions when objects enter and exit scope, respectively; and the concept of `friend' classes and functions. Objective-C protocols resemble C++ signatures. In Objective-C, a class is an object like any other; C++ classes do not exist at run time. 4 What is the difference between Objective-C and Java? The most obvious difference is syntax: Java's syntax is based on C++' whereas Objective-C employs the C syntax (and semantics) with the syntax of object declaration and manipulation based on Smalltalk. The Java object model comes straight from Objective-C. Nested classes do not change that since they are retrofitted, in Java 1.1, onto the original Java 1.0 object model for compatibility with 1.0 tools. Features that Java adds include mandatory typing, exception and thread support in the language, security managers, name spaces, predefined class libraries (java.lang, awt), etc. Features that Java misses include categories and the selector type. No categories means that a class can not be amended to suit your needs (a problem suffered by more OO languages, including C++). No selector type means that `forward::' and `perform:' methods do not exist, and that the possibilities of dynamic binding are limited; e.g. you can't tell an array to say `@selector (hello)' to all its elements, and the buttons in your GUI won't be able to use the target/action paradigm employed by the OPENSTEP AppKit (and which is why inner classes were invented in Java 1.1). Java currently enjoys a lot of `compile-once run-anywhere' hype. Even though Objective-C in this respect suffers the portability problems of C, OPENSTEP provides a foundation that could be described as `compile-once-for-each-platform run-on-each-platform': OPENSTEP enables application deployment on platforms ranging from MS Windows to Solaris. This is without modifications to the source, which is what `compile-once' is all about. 5 What are the `nice features' of Objective-C? The possibility to load class definitions at run time. The possibility to extend a class at compile, link, or run time, through a category or class posing. Objects are dynamically typed: full type information (name and type of instance variables; name, argument and return types of methods, etc) is available at run time. Every method invocation is dynamically bound. Add to this the selector type, forward:: and perform: methods, and you get flexibility not easily matched by other OO languages. Object archiving and distributed objects (`remote method invocation' in Java speak) are easy, not just to implement but also to use. 6 What are some problems of the language and how can I work around them? The underlying language is C: use Objective-C and you get all of C's problems for free. There are some `common problems': There is no innate multiple inheritance. Protocols address the absence of multiple inheritance (MI) to some extent: Technically, protocols are equivalent to MI for purely "abstract" classes (see the answer on `Protocols' below). To get around the absence of MI, you can create a compound class, i.e. a class with instance variables that are references to other objects. Instances can specifically redirect messages to any combination of the objects they are compounded of. (It isn't that much of a hassle and you have direct control over the inheritance logistics.) Of course, this is not `getting around the problem of not having multiple inheritance', but just modeling the world slightly different in such a way that you don't need multiple inheritance. There are no class variables. You can get around this by defining a static variable in the implementation file, and defining access methods for it. This is actually a more desirable way of designing a class hierarchy, because subclasses shouldn't access superclass storage (this would cause the subclass to break if the superclass was reimplemented), and allows the subclass to override the storage (if the classes access all their own variables via methods). To get the effect of class variables for which each subclass has a distinct value, more elaborate schemes are needed. An often used solution is to use a hash table to store the value of the `variable', keyed on the class. 7 What object encapsulation does Objective-C provide? Object encapsulation can be discerned at two levels: encapsulation of instance variables and of methods. In Objective-C, the two are quite different. Instance variables: The keywords @public, @private and @protected are provided to secure instance variables from prying eyes to some extent. @public anyone can access any instance variable. @protected only methods belonging to this object's class or a subclass thereof have access to the instance variables. @private only methods of this class may access the instance variables. This excludes methods of a subclass. If not explicitly set, all instance variables are @protected. Some people advocate that only @private should be used. It is generally agreed upon that @public if prohibited. Note: Instance variable encapsulation is enforced at compile-time. At run-time, full typing information on all instance variables is available, which sort-of makes all variables @public again. Methods: To the Objective-C runtime, all methods are @public. The programmer can only show his/her intention of making specific methods not public by not advertising them in the class' interface. In addition, so-called private methods can be put in a category with a special name, like `secret' or `private'. However, these tricks do not help much if the method is declared elsewhere, unless one employs static typing. And the runtime doesn't care about all this and any programmer can easily circumvent the tricks described. Thus, all methods really are always @public. 8 What are Protocols? Protocols are an addition to Objective-C that allows you to organize related methods into groups that form high-level behaviors. Protocols are currently available in NeXTSTEP (since 3.0) and derivatives, and GNU CC (since 2.4). In short, a protocol is a set of method declarations. A protocol can inherit from multiple other protocols, and a class can inherit multiple protocols. The protocol hierarchy is unrelated to the class hierarchy. The type of a variable can be `id <P>' to denote that the class of the object pointed to does not matter, as long as the class implements all methods prescribed by the protocol P. Protocols provide `multiple inheritance of interface'. They are matched by Java interfaces and C++ signatures. Protocols address the MI issue. When you design an object with multiple inheritance, you usually don't want *all* the features of both A and B, you want feature set X from A and feature set Y from B. If those features are methods, then encapsulating X and Y in protocols allows you to say exactly what you want in your new object. Furthermore, if someone changes objects A or B, that doesn't break your protocols or your new object. This does not address the question of new instance variables from A or B, only methods. Protocols allow you to get type-checking features without sacrificing dynamic binding. You can say "any object which implements the messages in Protocol Foo is OK for this use", which is usually what you want - you're constraining the functionality, not the implementation or the inheritance. Protocols give library builders a tool to identify sets of standard protocols, independent of the class hierarchy. Protocols provide language support for the reuse of design, whereas classes support the reuse of code. Well designed protocols can help users of an application framework when learning or designing new classes. Here is a simple protocol definition for archiving objects: @protocol Archiving -read: (Stream *) stream; -write: (Stream *) stream; @end Once defined, protocols can be referenced in a class interface as follows: /* MyClass inherits from Object and conforms to the Archiving protocol. */ @interface MyClass: Object <Archiving> @end Unlike copying methods to/from other class interfaces, any incompatible change made to the protocol will immediately be recognized by the compiler (the next time the class is compiled). Protocols also provide better type checking without compromising the flexibility of untyped, dynamically bound objects. MyClass *obj1 = [MyClass new]; // OK: obj1 conforms to the Archiving protocol. id <Archiving> obj2 = obj1; // Error: obj1 does not conform to the TargetAction protocol. id <TargetAction> obj3 = obj1; 9 Does Objective-C employ garbage collection? No. Some libraries conventionally use a reference counting scheme, but since such a scheme is implemented outside the language, it needs a lot of extra typing (by the programmer, on the keyboard) with all the usual consequences: errors caused by not properly maintaining an object's reference count. Hans Boehm's garbage collector can be used with Objective-C. Depending on the Objective-C compiler and library you use, integration is automatic or needs some work. Garbage Collection in an Uncooperative Environment Garbage collection of chunks of memory obtained through (its replacement of) malloc(3). Works for C, C++, Objective-C, etc. @article{bw88, title="Garbage Collection in an Uncooperative Environment", author="Hans J\"urgen Boehm and Mark Weiser", journal="Software Practice and Experience", pages=807-820,volume=18,number=9,month=sep,year=1988} Available as `ftp://parcftp.xerox.com/pub/gc/gc4.10.tar.gz' (check the directory for a newer version). 10 How do I debug Objective-C using an unaware gdb. On August 20 1996, Michael Snyder of NeXT posted patches to GDB 4.16 to make it Objective-C aware for GNU Objective-C code. This was tested on HP-UX, Solaris and MS Windows. As he did not supply an URL for these patches, I've made the postings available as ftp://ftp.ics.ele.tue.nl/pub/users/tiggr/objc/gdb-gnu-objc.diff.gz.uue and ftp://ftp.ics.ele.tue.nl/pub/users/tiggr/objc/gdb-gnu-objc.README. Debugging Objective-C using a non-Objective-C aware gdb has been documented by Martin Cracauer <cracauer@wavehh.hanse.de> on http://www.cons.org/cracauer/objc-hint-gdb.html. It comes down to understanding that you can very well look at Objective-C from the C perspective, a language very well understood by gdb. 11 I get this `Floating exception'... This answer describes possible solutions for the floating exception problem when using GNU Objective-C on i386 machines. [This problem existed some time ago; it should not exist any more with recent versions of the libraries/software.] If the problem you're having does not fit either description, try applying the hack described in ftp://ftp.ics.ele.tue.nl/pub/users/tiggr/objc/README.387, which has been reported to work for Linux, FreeBSD, and DJGPP (2.7.2). If it does not solve the problem, ask. If you're running Linux, adding `-lieee' to the linker invocation could help. Thomas March <amadeus@bga.com> reported that on several occasions, on systems running Linux ELF, with libc.so.5.0.9 and libm.so.5.?.?, the problem was reproducible and adding `-lieee' did not solve the problem. However, switching to a newer libc (libc.so.5.2.18 and libm.so.5.0.5) both solved the problem and removed the need for `-lieee' (i.e. a back to normal situation). If you're using DJGPP, you might want to take a look at the DJGPP FAQ, especially http://www.delorie.com/djgpp/v2faq/faq082.html. 12 Why am I lectured by gcc about `#import'? GNU CC issues the following multi-line warning about the how the use of `#import' is discouraged (output from GNU CC 2.7.0): foo.m:1: warning: using `#import' is not recommended The fact that a certain header file need not be processed more than once should be indicated in the header file, not where it is used. The best way to do this is with a conditional of this form: #ifndef _FOO_H_INCLUDED #define _FOO_H_INCLUDED ... <real contents of file> ... #endif /* Not _FOO_H_INCLUDED */ Then users can use `#include' any number of times. GNU C automatically avoids processing the file more than once when it is equipped with such a conditional. In short, use `-Wno-import' as an argument to gcc to stop it from producing this. Another possibility is to compile gcc after having changed the line reading `static int warn_import = 1' into `static int warn_import = 0' in `cccp.c' (line 467 in GNU CC 2.7.1); this way, `-Wno-import' is the default setting. Whether or not using `#import' is desirable (obviously) has to do with how to prevent multiple inclusions of the same file. Most include files, when included multiple times, either do nothing new (possibly due to guards being used) or (without the guards) cause the emission of C code on which the compiler will choke (due to, for instance, repeated typedefs). Thus, if everybody were to use `#import' everybody would be happy, since it does not seem to matter. However, a notable exception to this rule is `assert.h', which changes the definition of the `assert' macro depending on the setting of the NDEBUG macro. There is one point to be made in favor of the warning: if the _user_ of an include file uses `#include' instead of `#import', the guards will be necessary. Thus, actually, the warning should be issued when a file is imported that appears not to be guarded. Apart from the more-or-less religious (and thus useless) debate whether `#import' or `#include'-with-guards is better, it has been observed that `#import' does not catch re-reading a linked and/or duplicated file, whereas the guards do. However, this is, of course, a highly unlikely and probably undesirable situation for which neither was designed to catch. The reason for the existence of `#import' probably is historical: the first implementation of Objective-C (by Stepstone) was as a preprocessor to C, run after a modified cpp. `#import' was the include-once directive to that cpp. Since it is part of the Objective-C language, it has made it into GNU CC's cpp. 13 What written information concerning Objective-C is available? Books on Objective-C, or object oriented programming in general: Brad J. Cox, Andrew J. Novobilski: `Object Oriented Programming: An Evolutionary Approach', Addison-Wesley Publishing Company, Reading, Massachusetts, 1991. ISBN: 0-201-54834-8 (Japanese: 4-8101-8046-8). This is the original book on Objective-C, which actually is a book on object oriented system development using Objective-C. Object-Oriented Programming and the Objective-C Language. Originally published as `Nextstep Object-Oriented Programming and the Objective-C Language' by Addison-Wesley in 1993 with ISBN 0-201-63251-9 (Japanese: 4-7952-9636-7). In its current [Tue Aug 26 1997] incarnation it is available on-line from http://devworld.apple.com/dev/SWTechPubs/Documents/OPENSTEP/ObjectiveC/objctoc.htm This is a good book on OO programming in general, which focuses on Objective-C as the implementation language. It is also the definitive source of information for the Objective-C language as implemented by NeXT (and GNU). Lewis J. Pinson, Richard S. Wiener: Objective-C: Object Oriented Programming Techniques. Addison-Wesley Publishing Company, Reading, Massachusetts, 1991. ISBN 0-201-50828-1 (Japanese: 4-8101-8054-9). Includes many examples, discusses Stepstone's and NeXT's versions of Objective-C, and their differences. Timothy Budd: An Introduction to Object-Oriented Programming. Addison-Wesley Publishing Company, Reading, Massachusetts. ISBN 0-201-54709-0 (Japanese: 4-8101-8048-4). An intro to the topic of OOP, as well as a comparison of C++, Objective-C, Smalltalk, and Object Pascal Simson L. Garfinkel, Michael K. Mahoney: NeXTSTEP Programming Step ONE: Object-Oriented Applications. TELOS/Springer-Verlag, 1993 (tel: (800)SPR-INGE). It's updated to discuss NeXTSTEP 3.0 features (Project Builder, new development environment) but doesn't discuss 3DKit or DBKit. Articles `Why I need Objective-C', by Christopher Lozinski. Journal of Object-Oriented Programming (JOOP) September 1991. Contact info@bpg.com for a copy and subscription to the BPG newsletter. This article discusses the differences between C++ and Objective-C in great detail and explains that Objective-C is a better object oriented language. `Concurrent Object-Oriented C (cooC)', by Rajiv Trehan et. al. ACM SIGPLAN Notices, Vol. 28, No 2, February 1993. This article discusses cooC, a language based on the premise that an object not only provides an encapsulation boundary but should also form a process boundary. cooC is a superset of Objective-C. `Porting NEXTSTEP Applications to Microsoft Windows', by Christopher Lozinski. NEXTWORLD EXPO Conference Proceedings, San Francisco, CA, May 25-27, 1993. Updated version of the article available from the author. Contact info@bpg.com. This article describes how to develop Objective-C applications for both Microsoft Windows and NEXTSTEP. GNU Documentation The GNU project needs a free manual describing the Objective-C language features. Because of its cause, GNU cannot include the non-free books in the GNU system, but the system needs to come with documentation. Anyone who can write good documentation, please think about giving it to the GNU project. Contact rms@gnu.ai.mit.edu. 14 History Objective-C was developed by Brad Cox, who founded the Stepstone corporation in 1983 to develop and support the language, a compiler, and supporting libraries. Stepstone never really made it big, fostering Objective-C in a niche similar to that of Smalltalk. In 1985, Steve Jobs left Apple and started NeXT, a company that developed m68k machines and the NeXTSTEP operating system. The user interface of these machines was provided by Display PostScript and the AppKit, which, written in Objective-C, made Objective-C the language of choice on NeXT computers. Brad Cox and Andrew Novobilski write `Object Oriented Programming: An Evolutionary Approach' in 1986, the first book on Objective-C. NEXTSTEP 1.0a was released in 1989. The Objective-C compiler is based on gcc 1.34. In 1991, the Objective-C related modifications by NeXT to gcc find their way back into the FSF GNU CC distribution. By version 1.99, gcc (the compiler) supports Objective-C. NEXTSTEP 3.0 is released in 1992. The compiler supports Objective-C++, and the Objective-C language has been extended with `@protocol'. In the same year, gcc 2.0 comes supplied with an Objective-C runtime library. In 1993, gcc supports protocols by version 2.4. NeXT stops the production of hardware. With NEXTSTEP 3.1 they include support for PC's. NeXT starts creating other products not bound to a particular operating system, such as Portable Distributed Objects (PDO), which comes with its own Objective-C compiler and debugger. OPENSTEP, an Objective-C API, is made public in 1994. NEXTSTEP 3.3 is released in 1995; it adds support for HP hppa and Sun sparc machines. Also in this year, NeXT acquires all rights to the Objective-C programming language and trademark from Stepstone. Sun includes support for Objective-C++ in their SparcCompiler in 1996. They release OPENSTEP for Solaris. NeXT releases OPENSTEP 4.0 for PC hardware. Support for hppa and sparc has vanished. OPENSTEP for Windows NT is released. Early 1997, Apple acquires NeXT and starts work on the next Macintosh operating system, code named Rhapsody, based on the technology they got from NeXT. In the same year, Sun fosters the success of Java and subsequently kills OPENSTEP for Solaris. [Entry updated Tue Feb 17 1998. Credits to Norihiro Ito, Hajime Murao, KATO Tsuguru, and Hironobu Suzuki.] 15 Major compilers There are 4 major Objective-C compilers, provided by Apple, GNU, Stepstone, and Portable Object Compiler. The Stepstone and POC are preprocessors that emit vanilla C code, which makes them very portable. The GNU compiler compiles directly to assembly, as does Apple's, which is based on the GNU compiler. Apple The Apple (formerly NeXT) Objective-C compiler comes bundled with OpenStep Developer, current Rhapsody seeds, and various other products like Portable Distributed Objects (PDO) and WebObjects. Bundled with the operating systems is the FoundationKit general class library and the AppKit GUI library. OpenStep is available for NeXT hardware and PC compatible Intel machines. Rhapsody is the current name for the next-generation Apple Macintosh operating system; it is based on OpenStep. Rhapsody will be available for PowerPC-based Macintoshes and Intel-based PC compatibles. Apple Computer, Inc. 1 Infinite Loop Cupertino, CA 95014 voice: 408-996-1010 www: http://www.apple.com/ [Entry up to date as of Sun Sep 21 1997.] GNU GNU CC, since version 2, comes with an Objective-C compiler. The current distribution of GNU CC (version 2.8.0) includes an Objective-C compiler and runtime library. The latter includes the `Object' and `NXConstantString' classes. Some people are working on GNU libraries, see part 2 of this FAQ (The ClassWare Listing) for details or visit http://www.gnustep.org/. Free Software Foundation 59 Temple Place -- Suite 330 Boston, MA 02111 +1-617-542-5942 General questions about the GNU Project can be asked to gnu@prep.ai.mit.edu. For information on how to order GNU software on tape or cd-rom, and printed GNU manuals, check the file etc/ORDERS in the GNU Emacs distribution, ftp the file /pub/gnu/GNUinfo/ORDERS on prep, or e-mail a request to: gnu@prep.ai.mit.edu By ordering your GNU software from the FSF, you help us continue to develop more free software. Media revenues are our primary source of support. Donations to FSF are deductible on US tax returns. The above software will soon be at these ftp sites as well. Please try them before prep.ai.mit.edu as prep is very busy! thanx -gnu@prep.ai.mit.edu ASIA: ftp.cs.titech.ac.jp, tron.um.u-tokyo.ac.jp/pub/GNU/prep cair-archive.kaist.ac.kr/pub/gnu, ftp.nectec.or.th/pub/mirrors/gnu AUSTRALIA: archie.au/gnu (archie.oz or archie.oz.au for ACSnet) AFRICA: ftp.sun.ac.za/pub/gnu MIDDLE-EAST: ftp.technion.ac.il/pub/unsupported/gnu EUROPE: irisa.irisa.fr/pub/gnu, ftp.univ-lyon1.fr:pub/gnu, ftp.mcc.ac.uk, unix.hensa.ac.uk/mirrors/uunet/systems/gnu, src.doc.ic.ac.uk/gnu, ftp.ieunet.ie:pub/gnu, ftp.eunet.ch, nic.sunsite.cnlab-switch.ch/mirror/gnu, ftp.win.tue.nl/pub/gnu, ftp.nl.net, ftp.informatik.rwth-aachen.de/pub/gnu, ftp.informatik.tu-muenchen.de, ftp.etsimo.uniovi.es/pub/gnu, ftp.funet.fi/pub/gnu, ftp.denet.dk, ftp.stacken.kth.se, isy..se, ftp.luth.se/pub/unix/gnu, ftp.sunet.se/pub/gnu, archive.eu.net SOUTH AMERICA: ftp.inf.utfsm.cl/pub/gnu, ftp.unicamp.br/pub/gnu WESTERN CANADA: ftp.cs.ubc.ca/mirror2/gnu USA: wuarchive.wustl.edu/systems/gnu, labrea.stanford.edu, ftp.digex.net/pub/gnu, ftp.kpc.com/pub/mirror/gnu, f.ms.uky.edu/pub3/gnu, jaguar.utah.edu/gnustuff, ftp.hawaii.edu/mirrors/gnu, uiarchive.cso.uiuc.edu/pub/gnu, ftp.cs.columbia.edu/archives/gnu/prep, archive.cis.ohio-state.edu/pub/gnu, gatekeeper.dec.com/pub/GNU, ftp.uu.net/systems/gnu [Entry up to date as of Sun Sep 21 1997. GNU FTP mirror site list up to date as of Tue Jan 13 1997.] GNU/EGCS EGCS (at http://www.cygnus.com/egcs/) is a variation of GCC. From the EGCS FAQ: In brief, the three biggest differences between egcs and gcc2 are these: More rexamination of basic architectual decisions of gcc and an interest in adding new optimizations; working with the groups who have fractured out from gcc2 (like the Linux folks, the Intel optimizations folks, Fortran folks) including more front-ends; and finally An open development model (see below) for the development process. Like GCC, EGCS supports Objective-C. Stepstone Steptone provides Objective-C compilers and runtime for: Apple Macintosh (running Mac Programmers Workshop), DEC (Open VMS, OSF/1, ULTRIX), HP9000/700, 800 (HPUX), IBM RISC System/6000 (AIX), MIPS, NeXT, PC (MS-DOS, OS/2, MS Windows 3.1/95/NT, SCO Unix), Sun 3/4/SPARC (SunOS, Solaris), Silicon Graphics INDIGO (IRIS). Other ports available by market demands or consulting services. The ICpak101 Foundation Class Library is available on all the above. The ICpak201 GUI Class Library is available on platforms that support XWindows, Motif, OpenWindows and SunView. The Stepstone Corporation 75 Glen Road Sandy Hook, CT 06482 voice: 203 426 1875 voice: 800 BUY OBJEct fax: 203 270 0106 www: http://www.stepstn.com/ [Entry up to date as of Sun Aug 31 1997.] Portable Object Compiler The Portable Object Compiler is available on Windows 95, Windows NT, OS/2, Macintosh MPW, Amiga, BeOS, Linux, Linux/Alpha, MkLinux, FreeBSD, NetBSD, AIX, SunOS, Solaris, NeXTstep, HP-UX, SGI IRIX, OSF/1 Digital UNIX, Apple Rhapsody, and CRAY Unicos. It's an Objective C compiler, developed under the GNU Library General Public License, compatible with several C compiler environments, including GNU cc, lcc, SGI cc, MIPSpro cc, HP-UX cc, AIX cc, DEC cc, SUN acc, DJGPP gcc, Cray cc, pgcc, WATCOM wcc, Microsoft Visual C, Metrowerks MWCPPC, Metrowerks/BeOS mwcc and IBM Visual Age icc. The Portable Object Compiler supports C and C++ as base languages, and comes with an extensive set of collection class objects, including objects for arbitrary precision arithmetic. Most of the collection class objects compile on, and work with, Stepstone Objective C, GNU Objective C and NeXT Objective C. Additional interesting features of the compiler are support for Objective-C blocks, an option for garbage collection and an inline cache, pure C messenger. The Portable Object Compiler is obtainable from a few sites, http://www.can.nl/~stes/compiler.html http://cage.rug.ac.be/~stes/compiler.html http://hydrogen.ch.ntu.edu.tw:8080/~david/OBJC/software.html. [Entry up to date as of Sun Jan 25 1998.] 16 Compiler differences This section lists differences between the various Objective-C compilers that are available. The following compilers are compared: -------------------------------------------------------------------------- Compiler Description -------------------------------------------------------------------------- gcc GNU CC, version 2.8.0 or later apple The (GNU CC based) compiler supplied with Rhapsody (previously known as the NeXT compiler supplied with NextStep/OpenStep). stepstone Stepstone Objective-C compiler objc Portable Object Compiler -------------------------------------------------------------------------- The following table lists features of only the compiler and runtime library. Any other libraries normally supplied or associated with the compiler are not taken into account. -------------------------------------------------------------------- Feature gcc apple stepstn objc -------------------------------------------------------------------- supports blocks (1) no no no yes categories yes yes no yes replacing methods yes yes ? ? garbage collection no (3) no no yes (2) Objective-C++ no yes no yes protocols yes yes no no static method binding no no yes ? static/automatic allocation no no yes ? supports =-style class defs no no ? yes method decls in implementation no no ? yes multithreading yes yes ? yes +initialize method yes yes yes yes +load method yes yes ? ? @"string objects" yes yes no no @class forward declarations yes yes ? ? source available yes no no yes method binding mechanism sparse class ? inline array cache cache exception handling mechanism yes yes ? yes -------------------------------------------------------------------- notes 1: Described as `Action Expressions' in http://www.virtualschool.edu/cox/CoxTaskMaster.html 2: Using Hans Boehm's garbage collector (see question 9). 3: Work in progress; some next release of gcc/ecgs will have support for using Boehm's garbage collector. 17 Objective-C support per platform Below is a list of compilers supporting Objective-C, and which are not NeXT's, Stepstone's or plain GCC. DOS, Windows, OS/2 BPG BPG provides the Borland Extensions to Objective-C which allows the Objective-C translator to be used with the Borland Compiler, and makes it easy to develop Objective-C application for Microsoft Windows. BPG provides the Smalltalk Interface to Objective-C which makes Objective-C objects look like Smalltalk Objects. It can be used to build Graphical User Interface on portable Objective-C objects, or to sell Objective-C libraries to Smalltalk developers. BPG provides the Objective-C Message Bus which sends Objective-C messages across heterogeneous computer platforms. BPG has a library of objects for modeling Objective-C programs. A browser application has been built on this library. Other potential applications include adding class variables to Objective-C, adding runtime information about instance variables, and method argument types, generating object versions, and eventually building a browser/translator. Christopher Lozinski BPG 35032 Maidstone Court Newark, CA 94560 Tel: +1 510 795-6086 fax: +1 510 795-8077 email: info@bpg.com DJGPP DJGPP includes Objective-C support [though I do not know to which extent]. From the DJGGP homepage at http://www.delorie.com: DJGPP is a complete 32-bit C/C++ development system for Intel 80386 (and higher) PCs running DOS. It includes ports of many GNU development utilities. The development tools require a 80386 or newer computer to run, as do the programs they produce. In most cases, the programs it produces can be sold commercially without license or royalties. GCC/EMX The EMX port of GCC implements Objective-C, and with RSX (or RSXNT) it runs on DOS/DPMI boxes (or NT) too. EMX is available for anonymous ftp on at following locations: ftp://ftp.uni-stuttgart.de/pub/systems/os2/leo/devtools/emx+gcc/ ftp://ftp-os2.cdrom.com/pub/os2/lang/emxtools/ ftp://ftp.leo.org/pub/comp/os/os2/devtools/emx+gcc/ ftp://src.doc.ic.ac.uk/packages/os2/ftp.cdrom.com/lang/emxtools/ RSX is available from ftp://ftp.uni-bielefeld.de/pub/systems/msdos/misc/ Without RSX EMX is limited to DOS/VCPI and OS/2 >=2.0) [Thanks to <huug@poboxes.com> for this information.] GCC for Win32 Hyungjip Kim <hjkim@namo.co.kr> provides GCC 2.7.2 binaries for Win32. This GCC is modified to generate CodeView compatible debug information, to enable the use of existing Windows debuggers. Visit http://www.darkland.co.kr/~hjkim/objc/ for more information, and the binaries. GNU-Win32 The GNU-Win32 project aims at providing the GNU tools (including GCC) for Windows NT/95. [I do not know to which extent Objective-C is supported.] Below is a description of the project, taken from http://www.cygnus.com/misc/gnu-win32: The GNU-Win32 tools are ports of the popular GNU development tools to Windows NT/95 for the x86 and powerpc processors. Applications built with these tools have access to the Microsoft Win32 API as well as the Cygwin32 API which provides additional UNIX-like functionality including UNIX sockets, process control with a working fork and select, etc... With these tools installed, it is now possible to: write Win32 console or GUI applications that make use of the standard Microsoft Win32 API and/or the Cygwin32 API. easily configure and build many GNU tools from source (including rebuilding the gnu-win32 development tools themselves under x86 NT). port many other significant UNIX programs to Windows NT/95 without making significant changes to the source code. have a fairly full UNIX-like environment to work in, with access to many of the common Unix utilities (from both the bash shell and command.com). The GNU-Win32 project is run by Cygnus; for more information see http://www.cygnus.com. Macintosh Metrowerks Preliminary Objective-C support for the MacOS will be included in CodeWarrior Professional 1, to be released at the end of May 1997. [Entry written Thu May 15 1997.] Metrowerks Corporation 2201 Donley Drive Austin, TX 78758 http://www.metrowerks.com/ phone: 1-800-377-5416, +1 512 873 8313 email: info@metrowerks.com Tenon Tenon CodeBuilder supports Objective-C. This product is based on GNU CC and targeted at the Power Macintosh. http://www.tenon.com/products/codebuilder/ Sun SPARC Sun Sun's SPARCcompiler C++ 4.1 understands Objective-C, though it does not come with the relevant include files and libraries. At one time, Sun provided OpenStep on Solaris; it now seems that they are trying very hard to forget that: Sun's WWW site no longer provides any relevant information on either OpenStep or Objective-C. 18 What are the newsgroups or mailing lists to read? Read comp.lang.objective-c, which is bound to discuss current events. Also, threads on comp.sys.next.programmer are Objective-C specific on occasion. There is a mailing list on GNU Objective-C: gnu-objc@gnu.ai.mit.edu. To subscribe to this list, send a mail with your request to `gnu-objc-request@gnu.ai.mit.edu.' There's a mailing list for Portable Object Compiler users. Send email to 'objc-users-request@peti.gmd.de' to subscribe. GNUstep has several newsgroups devoted to it: gnu.gnustep.announce and gnu.gnustep.discuss to name but a few. Furthermore, the various kits that are being developed each come with their own mailing list. See part 2 of this FAQ for more information. 19 Are there any FTP sites with Objective C code? Where? All Rhapsody/NextStep/OpenStep sites carry Objective-C material. To name a few: ftp://next-ftp.peak.org/pub/next/ (NEXTSTEP) ftp://ftp.leo.org/pub/comp/platforms/next/ ftp://ftp.informatik.uni-muenchen.de ftp://ftp.gnustep.org/pub/ (GNUStep) ftp://ccrma-ftp.stanford.edu/pub/NeXT/ (MusicKit a.o.) See also part 2 of this FAQ. 20 Is there any information on the Net concerning Objective-C? Basic and related Objective-C (and/or NeXTSTEP) information is available at the following places: Apple Enterprise Group at http://www.enterprise.apple.com/ with the book at http://gemma.apple.com/techinfo/techdocs/rhapsody/apple.html Steve deKorte's Objective-C page at http://www.slip.net/~dekorte/Objective-C/, Brad Cox's Objective-C page at http://www.virtualschool.edu/mon/Cox/ObjectiveC.html, the GNUStep project at http://www.gnustep.org/, with a mirror at http://www.nmr.embl-heidelberg.de/GNUstep the libobjects FAQ at ftp://ftp.cs.rochester.edu/pub/u/mccallum/libobjects/Gnustep-FAQ.html, the NEXTSTEP/OpenStep Information Service at http://www.stepwise.com/, the eduStep initiative at http://www.nmr.embl-heidelberg.de/eduStep/, Cetus Links (http://www.rhein-neckar.de/~cetus/) has many links on OO; Objective-C is on http://www.rhein-neckar.de/~cetus/oo_objective_c.html, Nelson Minar's Objective-C page at http://www.santafe.edu/projects/swarm/ObjC/objective-c.html Tiggr's Objective-C page at http://www.ics.ele.tue.nl/~tiggr/objc/, Portable Object Compiler homepage at http://www.can.nl/~stes/compiler.html Norihiro Itoh's page at http://www.fsinet.or.jp/~nito/index-j.html, and of course the HTML versions of this FAQ and associated information at the addresses listed below. 21 For more information... Visit one of the places mentioned in #20, or see part 2 of this FAQ, Objective-C/classes a.k.a. the ClassWare Listing, for an [incomplete!] overview of available Objective-C classes and libraries. See part 3 of this FAQ, Objective-C/sample a.k.a. the Simple Sample Program, for an example Objective-C program. A World Wide Web hypertext version of this FAQ is maintained by Steve Dekorte <dekorte@suite.com> at http://www.slip.net/~dekorte/Objective-C/. A Japanese language version of this FAQ, maintained by Norihiro Itoh <nito@fsinet.or.jp>, resides at http://www.fsinet.or.jp/~nito/index-j.html. The early version of this FAQ was compiled by Bill Shirley, with the aid of many people. The current version is being maintained by Pieter Schoenmakers <tiggr@gerbil.org>, aided by input from a lot of people, including: Per Abrahamsen, Paul Burchard, Brad Cox, Christopher Lozinski, Mike Mahoney, Jon F. Rosen, Paul Sanchez, Lee Sailer, David Stes, Paul Sanchez, Bill Shirley, Subrata Sircar, Ted Slupesky, Richard Stallman, and Kersten Krab Thorup. Send your suggestions, additions, bug reports, comments and fixes to tiggr@gerbil.org. The information in this file comes AS IS, WITHOUT ANY WARRANTY. You may use the information contained in this file or distribute this file, as long as you do not modify it, make money out of it or take the credits. User Contributions:
[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
Send corrections/additions to the FAQ Maintainer: tiggr@gerbil.org
Last Update March 27 2014 @ 02:11 PM
|
comp.lang.objective-c FAQ, part 1/3: Answers
Search the FAQ Archives
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
comp.lang.objective-c FAQ, part 1/3: Answers
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Cities ]
Comment about this article, ask questions, or add new information about this topic: