noren@dinl.uucp (Charles Noren) (08/27/90)
In article <4998@pegasus.ATT.COM> hansen@pegasus.ATT.COM (Tony L. Hansen) writes: >Objective C has a number of class C++ has a number of class >libraries available from libraries available from a variety >Stepstone. of sources. Both Objective-C and C++ have class libraries, however, only Objective-C has "standard" class libraries available from the vendor (Stepstone) -- as pointed out in the posting. The difference is significant. With C++, various C++ compiler vendors are producing class libraries which are incompatable with each other. Use a vendor class library and you are tied to that vendor and to only the machines that the vendor supports, which for most (if not all) vendors, is a very few machines. Sure, C++ is available on *many* machines, but each particular vendor (with its own class library) runs on a few machines. There are standard classes emerging in C++, such as I/O streams, complex math, and tasking classes, but this does not come near the richness of the Objective-C classes. One possible solution is public domain C++ class libraries. The public domain libraries include: o National Institute of Health Class Library (NIHCL). This is available via anonymous ftp from [128.231.128.251]. This is a "Smalltalk-like" general class library. o Free Software Foundation's g++lib. This is available via ftp from [36.8.0.47]. This is a general class library. o InterViews class library. Available via ftp at [36.22.0.175] or [36.22.0.14]. This is a toolkit that runs on top of xlib of X-Windows. o ET++ class library. Available via ftp from [192.5.53.209] with patches to compile on g++ found at [128.42.4.38]. [I think] this is a toolkit that runs on top of X-Windows. There are a variety of third-party vendors that sell C++ class libraries. See the monthly products posting in comp.lang.c++ for a list of those (this is where I "stole" a lot of the PD information, another ftp number to know about is [128.6.7.38] which contains an ftp list of goodie sites). The problem with public domain or third party class libraries is that it may require some work to get it to run with your machine and C++ compiler. The amount of work will vary, depending on your version of C++ and possibly some of the quirks of your C++ compiler (your know, features, what some people call bugs :-)). The documentation that comes with the class libraries varies in quality. The NIHCL has an outstanding book (I am told, my copy is still on order) by the creators of NIHCL. InterViews has limited documentation (the quality is execellent, but more is needed) with nice example programs (including a graphics editor and class browser). Finally, the libraries are not guaranteed to be compatable. It will take some amount of work to get two different class libraries to run together. Objective-C, on the other hand, has several major class libraries that all work together. This is due to the fact that Objective-C is made by only one vendor (Stepstone) which has as one of its major goals to produce an outstanding development environment. These class libraries include: o ICpak 101. This is a general "Smalltalk-like" class library. This comes standard with the Objective-C compiler. o ICpak 201. This is the window class library. o ICpak 301. This is the graphics class library. Since Objective-C runs on a multitude of machines, you will probably not have as many portability problems as you currently have with C++. Further, the documentation and examples supplied with the class libraries is outstanding, with excellent support from the Stepstone staff. The class libraries are **EASY** to install. Finally, unlike other compiler vendors, you get **SOURCE** with the class libraries. One other comment about the C++ and the Objective-C environment. Objective-C comes with an outstanding browser, which I feel is crucial in serious OO development. Currently the browser is does read-only browsing of the source-code, but future enhancements will allow editing of the code. There are some C++ browsers in the public domain: o iclass (from InterViews). This is an example program that scans the header files of C++. o cbrowse (from Brown University). This is part of a very good C++ (and C) development evironment called Field, which includes an integrated development environment that runs on top of X-Windows. This is available via ftp from Brown University at [128.148.32.66]. Read the read-me files and notices because it will requiire a password to download the Field environment (if you have problems, you can call Brown University at 401 863-7627 or e-mail to redsoft@cs.brown.edu). cbrowse will graphically display your class hierarchy and recreate the class information that your header files have. The problem with the C++ browsers is that none them show the *SOURCE* of your C++ programs (except the header file info). The Objective-C browser, on the other hand, shows Objective-C source. I feel this is an essential feature of a browser. One C++ company who I expect will produce a good browser in the future is the ObjectWorks C++ environment by ParcPlace Systems (a maker of Smalltalk). Contacts for companies mentioned: o Stepstone (makers of Objective-C). The Stepstone Corporation 75 Glen Road Sandy Hook, CT 06482 (203) 426-1875 FAX (203) 270-0106 o ParcPlace (makers of ObjectWorks). ParcPlace Systems 1550 Plymoth St. Mountian View, CA 94043 (415) 691-6720 -- Chuck Noren NET: dinl!noren@ncar.ucar.edu US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260, Denver, CO 80201-1260 Phone: (303) 971-7930
sdm@cs.brown.edu (Scott Meyers) (08/28/90)
In article <1716@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes: > o cbrowse (from Brown University). This is part of a very good > C++ (and C) development evironment called Field, which includes > an integrated development environment that runs on top of > X-Windows. This is available via ftp from Brown University > at [128.148.32.66]. Note: the ftp number is now 128.148.31.66. ^^ >The problem with the C++ browsers is that none them show the *SOURCE* >of your C++ programs (except the header file info). A non-graphical approach we (Brown University) have been exploring to source browsing is implemented as a package for Gnu emacs. In this package, functions to query the FIELD database (the same database used by cbrowse) are bound to emacs keystrokes, so it is possible to perform queries that are dependent on the current cursor location. For example, given the statement, theSPG->_allNodes.insert(node); you can put your cursor on any of the tokens and ask to see its declaration or definition. For example, if the cursor is on "insert" and you invoke the function "XREF:find-function-def," emacs looks at _allNodes to find out its declared type (class), then looks in that class for a declaration of a function called insert. If it finds it, it then locates the function definition and opens a new buffer on that file at the approprate line. You can also ask to see base and derived classes; complete class interfaces (i.e., all members defined in all base classes); and lots more. And of course you retain all the nifty features of Gnu emacs, i.e., multiple buffers, electric buffers, etc.. In combination with cbrowse, this offers a nice environment for seeing high-level relationships (in cbrowse) while also being able to semantically manipulate source at a detailed level (in Emacs). The prototype implementation of the Emacs interface was written by Moises Lejter, who'll be presenting a paper on it at the C++ at Work conference next month. The current implementation is slow and buggy, but still impressive (or at least interesting). If you're interested in giving it a try, it's available via anonymous ftp at the above address in the file ~ftp/pub/mlm/fieldxref.tar.Z. Scott PS - For the record, it probably wouldn't be difficult to write code so that cbrowse and Emacs communicated via FIELD. In that case, when a class/member was selected in cbrowse, it would notify Emacs, which would perform the relevant query and then update its buffer to show the current source. As far as I know, however, no one here is working on that.
sdm@cs.brown.edu (Scott Meyers) (08/28/90)
Regarding the Emacs interface to FIELD, I wrote: | The prototype implementation of the Emacs interface was written by Moises | Lejter, who'll be presenting a paper on it at the C++ at Work conference | next month. The current implementation is slow and buggy, but still | impressive (or at least interesting). Moises would have preferred that I had written "somewhat slow and buggy," so I stand corrected :-). At any rate, it's usable, and one whole heck of a lot better than nothing. Scott
edwardj@microsoft.UUCP (Edward JUNG) (09/07/90)
In article <15409@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes: >In article <5514@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: [...] >|Objective-C is available (and supported by) three vendors (that I know of). >|Not one. > [...] >Perhaps it would be more correct to say that there is only one basic >implementation of Objective-C commercially available, whereas there >are several independent implementations of C++? However, the real point >is that there is an implementation of C++ (G++) which is available at >negligable cost, especially to the academic/research community where copyleft >is not a concern. If there were a "GNU Objective-C" in existence, a lot >more people would think it to be a fine language. >-- >Craig Jackson >dricejb@drilex.dri.mgh.com >{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb} The NeXT implementation of Objective-C after version 0.9 of their OS is an independent implementation. Moreoever, it is based upon GCC from the Free Software Foundation and therefore falls under the free software policy of FSF. NeXT's object library is significantly different from that of Stepstone and the various IC-Paks. I believe that IBM implementation is a port of NeXT's implementation, but I am uncertain how much of the NeXT code remains in the IBM version. The latest FSF newsletter, as I remember, mentioned that version 2.0 of GCC would compile Objective-C (I assume this ability is derived from the NeXT GCC). Reflexively, version 2.0 of NeXT's compiler will apparently compile C++. So let's watch the world get smaller and happier and less religious about languages. I hope to see whether Objective-C and C++ can be mixed along the lines suggested by Brad Cox or if it just isn't as elegant as we might think. . Edward Jung I do not represent Microsoft