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
johnb@srchtec.UUCP (John Baldwin) (08/29/90)
In article <1716@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes: > >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. >.... >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. Huh? Isn't this a contradiction? It seems like you've shot your own horse, here. What machines are supported by Stepstone, besides MS-DOS PC's? Has anyone encountered any other vendors of Objective-C besides Stepstone? > >One possible solution is public domain C++ class libraries. > .... >There are a variety of third-party vendors that sell C++ class >libraries. See the monthly products posting in comp.lang.c++ This is not to start up the new O/O language Jihad, but it just seemed like the evidence presented in the referred posting had the opposite effect from that intended: C++ looks like it has both PD and multivendor/multiplatform support. Objective-C doesn't look like it has either of the above. Is this the case? Please bear in mind [as I step into the flame-retardant suit :-)] that I'm not firmly in any given O/O language camp. To rephrase, these are real, not rhetorical, questions. Thanks. -- John T. Baldwin | johnb%srchtec.uucp@mathcs.emory.edu Search Technology, Inc. | | "... I had an infinite loop, My opinions; not my employers'. | but it was only for a little while..."
noren@dinl.uucp (Charles Noren) (08/29/90)
In article <181@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes: >In article <1716@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes: I wrote: 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. .... 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. John Baldwin wrote (trying to piece togther my confusing style): Huh? Isn't this a contradiction? It seems like you've shot your own horse, here. What machines are supported by Stepstone, besides MS-DOS PC's? Has anyone encountered any other vendors of Objective-C besides Stepstone? Objective-C is supported by only one vendor, Stepstone. Sometimes this can be a hinderance in trying to purchase Objective-C in a corporate environment that is concerned about sole-source products and what happens if that company goes out of business. However, if you are not careful with C++ development, you could but subject to sole-source risks also, particularly if you are locked into a particular vendor's class library. For instance, we are using the C++ compiler from Object Design, Inc (ODI) which is tailored for Object Design's OODBMS called ObjectStore. The C++ compiler is a modification of AT&T's c-front, which, among other things, can accept parameterized types. This is the first C++ compiler to have parameterized types. The trade-rags indicate that AT&T will use ODI's implementation of parameterized types, but I put this information in the rumor category. ODI has a class library, which makes use of parameterized types. The class library is nice for general C++ work, but exremely useful for using the ObjectStore database. We are using the ODI class libraries because of its general utility and its power to use the database. So, we are locked into ODI's class library, which is locked in currently to ODI's C++ compiler. Currently, ODI's compiler and database only run on Sun 3's and Sun 4's. ODI is working to release their products on other machines, and announcements should be forth coming soon. But ODI is a new company (as with many other OO companies) -- and the products are *beta* products. We are running all sorts of risks, but we're doing a research project (I must say, however, that ODI seems to be getting lots of orders for a product that is well done). Objective-C is not limited to MS-DOS (which, is not its primary target environment). Objective-C can run on the following machines: 1. Apollo Domain 2. HP9000/300/HP-UX 3. PC/AT with MS-DOS (but not with windows and graphics libraries) 4. PS/2 OS/2 (but not with windows and graphics libraries) 5. IBM PC/RT with AIX 6. Sun 3, Sun 4, Sun 386i 7. VAX with ULTRIX and VAX with VMS. 8. NeXT 9. ...and I've just heard of a new port to the IBM RISC machine (R6000?). Then I also wrote in the previous article: One possible solution is public domain C++ class libraries. .... There are a variety of third-party vendors that sell C++ class libraries. See the monthly products posting in comp.lang.c++ ...and John Baldwin wrote: This is not to start up the new O/O language Jihad, but it just seemed like the evidence presented in the referred posting had the opposite effect from that intended: C++ looks like it has both PD and multivendor/multiplatform support. Objective-C doesn't look like it has either of the above. Is this the case? Please bear in mind [as I step into the flame-retardant suit :-)] that I'm not firmly in any given O/O language camp. To rephrase, these are real, not rhetorical, questions. The evidence is mixed. While my heart is with Objective-C, I will do the pragmatic thing (such as choosing C++ because I feel that Object Design's ObjectStore OODBMS is a good fit for our application). My point is that today, C++ and its development environments have rough edges. We've brought over several C++ public domain class libraries and have spent weeks getting them to work. One class library (InterViews) will not compile with our C++ compiler due to a bug in the compiler (which will be fixed with a new compiler release due any day). Objective-C, on the other hand, was a snap to load on our machine (a Sun 3). The Objective-C class libraries were loaded and tested in 30-minutes. Stepstone has done their homework. In time, the C++ environment will tame down also. Certainly C++ has major advantages of multi-vendor and public-domain activity and the rough edges will be smoothed out (but Stepstone is not standing still either). I must say, these are fun times and working in any OO language is better than going back to the dark ages :-) :-). Contacts for products mentioned: Object Design (makers of ObjectStore OODBMS) Object Design, Inc. One New England Executive Park Burlington, MA 01803 (617) 270-9797 Los Angeles regional office: (213) 412-8411 StepStone (makers of Objective-C) The Stepstone Corporation 75 Glen Road Sandy Hook, CT 06842 (203) 426-1875 (the contacts are included because I often get e-mail asking how companies can be contacted the I mention.) -- 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
lerman@stpstn.UUCP (Ken Lerman) (08/29/90)
In article <181@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes: > What machines are supported by Stepstone, besides MS-DOS PC's? Sun2, Sun3, Sun4, Sun386, SCO unix, DG Aviion, HPs(a few), Apollo, IBM PS2, IBM RISC/6000, Next, IBM PS2, DEC 3100, DEC VAX, MSDOS and OS-2 and I'm sure I've left out a few. >Has anyone encountered any other vendors of Objective-C besides Stepstone? IBM (announced, and delivered to us, at least) and Next. >-- >John T. Baldwin | johnb%srchtec.uucp@mathcs.emory.edu >Search Technology, Inc. | > | "... I had an infinite loop, >My opinions; not my employers'. | but it was only for a little while..." Please note that I work for Stepstone and DO have an axe to grind. In this context, I speak for myself, not for Stepstone. Ken
chip@tct.uucp (Chip Salzenberg) (08/30/90)
[ Does this discussion still belong in comp.lang.c++? ] According to noren@dinl.UUCP (Charles Noren): >Objective-C is supported by only one vendor, Stepstone. [...] >However, if you are not careful with C++ development, you could >be subject to sole-source risks also, particularly if you are locked >into a particular vendor's class library. For instance, we are using >the C++ compiler from Object Design, Inc (ODI) which is tailored for >Object Design's OODBMS called ObjectStore. The C++ compiler is a >modification of AT&T's c-front, which, among other things, can >accept parameterized types. ODI's compiler is NOT, repeat, NOT a C++ compiler. It does not compile the C++ language. Rather, it compiles a proprietary superset of C++. ODI's library is written in that superset of C++. Using ODI as an example of a C++ vendor is incorrect at best. Stick to vanilla C++ and you'll go far. Make extensions and you're on your own. These laws always apply to all languages, and therefore cannot be used to argue the relative merit of any language. >My point is that today, C++ and its development environments have >rough edges. A pronouncement such as this one must be made relative to a specific C++ product, or it is meaningless. Objective-C has a simple state, since it is available from only one vendor. Such is not the case with C++. It is mainly for this reason that I have promoted C++ for company use instead of Objective-C. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
lerman@stpstn.UUCP (Ken Lerman) (09/01/90)
In article <26DC7CC4.266D@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: [...stuff deleted...] > Objective-C has a simple state, >since it is available from only one vendor. Such is not the case with >C++. It is mainly for this reason that I have promoted C++ for >company use instead of Objective-C. >-- >Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> I know Chip didn't originate the statement that Objective-C is available from only one vendor, so this is not a flame at Chip, but I feel that I must reiterate (Chuck Noren are you listening? :-)): Objective-C is available from: The Stepstone Corporation 1 IBM +1 NeXt +1 ------- 3 Objective-C is available (and supported by) three vendors (that I know of). Not one. Of course I have an axe to grind, I work for The Stepstone Corporation. Ken
noren@dinl.uucp (Charles Noren) (09/05/90)
In article <26DC7CC4.266D@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >ODI's compiler is NOT, repeat, NOT a C++ compiler. It does not >compile the C++ language. Rather, it compiles a proprietary superset >of C++. ODI's library is written in that superset of C++. Using ODI >as an example of a C++ vendor is incorrect at best. > ...yes, the Object Design Inc (ODI) C++ compiler is a proprietary superset of C++. I gave a poor example. However, while the ODI C++ compiler does not make sense for a general C++ application, it was designed for use with ObjectStore, the Object-Oriented Database Management System from ODI -- and it makes very good sense to use it in an OODBMS application. ODI's C++ with ObjectStore provides a seamless interface between the C++ applicaton and the OODBMS. Sure you will not be compatable with the rest of the world, but I don't see how that can be avoided with any other OODBMS I've looked at (admittedly a small subset, ObjectStore, OntoLogic, Gemstone), since you are locked into their proprietary interface and class library. The best that could be done, I think, is to encapsulate the OODBMS interface into some classes that would be rewritten if a port to a different OODBMS is necessary. -- 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
dricejb@drilex.UUCP (Craig Jackson drilex1) (09/05/90)
In article <5514@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: |In article <26DC7CC4.266D@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: |[...stuff deleted...] |> Objective-C has a simple state, |>since it is available from only one vendor. Such is not the case with |>C++. It is mainly for this reason that I have promoted C++ for |>company use instead of Objective-C. | |I know Chip didn't originate the statement that Objective-C is |available from only one vendor, so this is not a flame at Chip, but I |feel that I must reiterate (Chuck Noren are you listening? :-)): | |Objective-C is available from: | The Stepstone Corporation 1 | IBM +1 | NeXt +1 | ------- | 3 |Objective-C is available (and supported by) three vendors (that I know of). |Not one. | |Of course I have an axe to grind, I work for The Stepstone Corporation. 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}
rae@gpu.utcs.toronto.edu (Reid Ellis) (09/05/90)
In article <181@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes: |What machines are supported by Stepstone, besides MS-DOS PC's? In <5505@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: |Sun2, Sun3, Sun4, Sun386, SCO unix, DG Aviion, HPs(a few), Apollo, IBM |PS2, IBM RISC/6000, Next, IBM PS2, DEC 3100, DEC VAX, MSDOS and OS-2 |and I'm sure I've left out a few. | |Please note that I work for Stepstone and DO have an axe to grind. | |In this context, I speak for myself, not for Stepstone. | |Ken A lot of people are still waiting for a Macintosh port. Are there any rumours of exclusivity contracts with NeXT and/or IBM that might preclude any port of Objective C to the Macintosh in the future? [followups directed to comp.sys.mac.programmer] Reid -- Reid Ellis 264 Broadway Avenue, Toronto ON, M4P 1V9 Canada rae@gpu.utcs.toronto.edu || rae%alias@csri.toronto.edu || +1 416 487 1383
jmd@swbatl.sbc.com (Jim Doherty 5-0804 11-Y-03) (09/06/90)
In article <1723@dinl.mmc.UUCP>, noren@dinl.uucp (Charles Noren) writes: > In article <26DC7CC4.266D@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > > >ODI's compiler is NOT, repeat, NOT a C++ compiler. It does not > >compile the C++ language. Rather, it compiles a proprietary superset > >of C++. ODI's library is written in that superset of C++. Using ODI > >as an example of a C++ vendor is incorrect at best. > > > > ...yes, the Object Design Inc (ODI) C++ compiler is a proprietary > superset of C++. I gave a poor example. However, while the ODI C++ > compiler does not make sense for a general C++ application, it was > designed for use with ObjectStore, the Object-Oriented Database > Management System from ODI -- and it makes very good sense to use it in > an OODBMS application. I agree that this is a good implementation however if you are developing any type of time critical (real time, with usual disclaimers about real time) you will find that ObjectStore blocks on I/O and therefore your concurency within a process is well single threaded at that point ! >ODI's C++ with ObjectStore provides a seamless > interface between the C++ applicaton and the OODBMS. Sure you will not > be compatable with the rest of the world, but I don't see how that can > be avoided with any other OODBMS I've looked at (admittedly a small > subset, ObjectStore, OntoLogic, Gemstone), since you are locked into > their proprietary interface and class library. The best that could be > done, I think, is to encapsulate the OODBMS interface into some classes > that would be rewritten if a port to a different OODBMS is necessary. chuck makes a good point here in our case we have decided to roll our own interface to Sybase(which is what ObjectStore uses I believe) as a backend storage dbms. At some point you will have to hide your apps from the dbms or of course role your own. > > > -- > 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 -- James M Doherty - SWBT - Advanced Technology Planning One Bell Center Room 11-Y-03 St. Louis, Mo. 63101 UUCP: { pyramid, ihnp4, bellcore }...!swbatl!jmd PHON: 314-235-0804 FAX: 314-235-0727
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
dlw@odi.com (Dan Weinreb) (09/08/90)
I'd like to clear up a few things about ObjectStore (the object-oriented database system from Object Design), which was mentioned in a few recent postings. ObjectStore does not use Sybase as a back-end (or in any other way). ObjectStore has its own back-end. The ObjectStore server includes remote network access, concurrency control, and log-based recovery, and it uses lightweight processes, so it resembles the Sybase server in some respects in its overall design, but it is completely independent software. Chip Salzenberg is right that ODI is not a provider of C++ compilers; we're a database company. As Charles Noren himself said, ObjectStore isn't a good example for the original discussion, which had to do with whether certain languages were supported by more than one vendor. The ObjectStore database system, like many relational database systems, can be used either of two ways: with an "embedded DML" (data-manipulation language), or with ordinary function calls to a library, from either C++ or C. Currently, the "embedded DML" is implemented by a modified version of cfront, although in the future it may be done by a pre-processor that emits C++ code. If you use ObjectStore with the library, you can use an ordinary C++ compiler or an ordinary C compiler to compile your program, and just link to the library. Daniel Weinreb dlw@odi.com Object Design, Inc. 1 New England Executive Park Burlington MA 01803