Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!dinl!noren
From: noren@dinl.uucp (Charles Noren)
Newsgroups: comp.lang.c++
Subject: Re: OO Development Environments
Keywords: C++, Object Design Inc, ODI
Message-ID: <1723@dinl.mmc.UUCP>
Date: 4 Sep 90 20:46:19 GMT
References: <1716@dinl.mmc.UUCP> <181@srchtec.UUCP> <1719@dinl.mmc.UUCP> <26DC7CC4.266D@tct.uucp>
Reply-To: noren@dinl.UUCP (Charles Noren)
Organization: Martin Marietta I&CS, Denver CO.
Lines: 29

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