Xref: utzoo comp.lang.c++:9881 comp.object:1923 comp.databases:7474 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++,comp.object,comp.databases Subject: Re: C++ and INGRES Message-ID: Date: 9 Oct 90 17:01:54 GMT References: <7797@star.cs.vu.nl> <1990Oct2.064421.3285@santra.uucp> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 59 In-reply-to: Chuck.Phillips@FtCollins.NCR.COM's message of 8 Oct 90 07:20:05 GMT In article Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) writes: >>>>> On 2 Oct 90 06:44:21 GMT, jaa@hutcs.hut.fi (Jari Alasuvanto) said: Jari> We did something with C++ and Ingres about two years ago. As far as I Jari> remember, there where some problems: Jari> - Ingres preprocessor (at the time) wanted to have the function Jari> defined as in C instead of C++ Under C++ 2.x could this be circumvented by using "extern C" declarations? After which, your interface from C++ to SQL becomes C. Not everyone has gotten to C++ 2.0 yet (boohoo). Jari> - "class" was not understood by Ingres at all No doubt. :-( Nor would you expect "class" to be supported in an SQL/C preprocessor. Jari> If you`re using 2.0, you will propably have to guess the prototypes Jari> for the functions which Ingres preprocessor generates. This may be Jari> supported now, I have not done it with newer releases. I certainly _hope_ so, especially since ANSI C is now official. You don't need C++ for full prototypes to be _very_ useful. It would also promote the use of interpreters, which make use of all the type information available, even when the source isn't. (e.g. Saber C, which I _highly_ recommend) Jari seemed to be talking about the functions that the Ingres preprocessor generates. Before running the preprocessor, there is no way to determine what those functions might look like. Therefore, its not possible to declare those functions in such a way that C++ will recognize them without muching with the C code that the SQL/C preprocessor output (I take it Jari is trying to run the C++ preprocessor after the SQL/C preprocessor). The point about embedding SQL in a C++ program and then trying to interpret it with an SQL/C preprocessor is that *it won't work well*. No matter how well the outputted C code from the preprocessor is, it will not always be up to snuff with the rigors of C++. The best bet is to either wait for an SQL/C++ preprocessor or isolate the SQL code into "pure" C functions and then rely on the linker to put it together with the other language (which would work whether the "other" language was C++, Pascal, Fortran, or whatever). As far as C++ is concerned, these functions can then be put into inlined functions so that there is not much of a performance hit from the double function call (once to a member function, then once more to the "C" function with the SQL). If this last paragraph didn't make it plain, I have been "bit" by embedding SQL code in C++ and having to compensate for the vagueries of two language preprocessors that are still changing (we're still in C++ 1.2 -- I shudder what will happen with C++ 2.0). Wish we could have done it over... -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"