hcnbakk@cs.vu.nl (Bakker HCN) (10/01/90)
Is there anybody out there who has experience with or information about: - the possibility to access a database form C++ in general, - the use of embedded SQL in C++ and - the coupling between INGRES and C++? Thanks in advance, Huub Bakker Department of Computer Science hcnbakk@cs.vu.nl Vrije Universiteit, Amsterdam
bg0l+@andrew.cmu.edu (Bruce E. Golightly) (10/02/90)
I don't see why not. One of the fundamental assumptions is that embedded DMLs are transparent to the host language. SQL in particular is supposed to be portable from language to language, so that an EXEC SQL ... remains the same wether you're using COBOL, C or whatever. One of the things that makes this possible is that Ingres uses a pre-processor to handle the DML. Thus, the SQL instructions are processed into a form compatible with the host language BEFORE the compiler ever sees the program. Of course, you should be aware that Ingres does not presently support objects very well at this point. They have something they call "user defined data types", but these are quite the same thing. This is the point at which an attempt to embed DML in C++ might break down. Good luck and good hunting...
jaa@hutcs.hut.fi (Jari Alasuvanto) (10/02/90)
We did something with C++ and Ingres about two years ago. As far as I remember, there where some problems: - Ingres preprocessor (at the time) wanted to have the function defined as in C instead of C++ - "class" was not understood by Ingres at all If you`re using 2.0, you will propably have to guess the prototypes for the functions which Ingres preprocessor generates. This may be supported now, I have not done it with newer releases. -- Jari Alasuvanto, Lab. of Info Proc. Sci, Helsinki Univ. of Techology, Finland Internet: jaa@hutcs.hut.fi tel: +358-0-451 3236 fax: +358-0-465 077 <All the statements are my own -- HUT can make its own>>
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (10/08/90)
>>>>> 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?
Jari> - "class" was not understood by Ingres at all
No doubt. :-(
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)
#include <std/disclaimer.h>
Thanks for the post,
Jari> Jari Alasuvanto, Lab. of Info Proc. Sci, Helsinki Univ. of Techology, Finland
Jari> Internet: jaa@hutcs.hut.fi tel: +358-0-451 3236 fax: +358-0-465 077
Jari> <All the statements are my own -- HUT can make its own>>
Chuck Phillips MS440
NCR Microelectronics chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp
--
Chuck Phillips MS440
NCR Microelectronics chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckpdavidm@uunet.UU.NET (David S. Masterson) (10/10/90)
In article <CHUCK.PHILLIPS.90Oct8082005@halley.FtCollins.NCR.COM> 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!"
basti@orthogo.UUCP (Sebastian Wangnick) (10/18/90)
hcnbakk@cs.vu.nl (Bakker HCN) writes: >Is there anybody out there who has experience with or information >about: >- the possibility to access a database form C++ in general, >- the use of embedded SQL in C++ and >- the coupling between INGRES and C++? Well, we will use the Informix ESQL/C within our C++ project; some tests proved that the generated C code is acceptable to a C++ compiler. Of course, the main problem is how to integrate such a database into an object oriented framework. We have some ideas on that but these are still preliminary. Does anyone have come to a good classwork already? Sebastian Wangnick (basti@orthogo.uucp)
davidm@uunet.UU.NET (David S. Masterson) (10/20/90)
In article <813@orthogo.UUCP> basti@orthogo.UUCP (Sebastian Wangnick) writes:
Well, we will use the Informix ESQL/C within our C++ project;
some tests proved that the generated C code is acceptable to
a C++ compiler.
If it works this way, great. However, you might be happier in the long run by
making all embedded SQL live in straight ANSI-C functions which are then
called from your C++ code. This will probably make it easier to live with
changes in the C++ compiler or the ESQL/C compiler or both.
Of course, the main problem is how to integrate such a database
into an object oriented framework. We have some ideas on that
but these are still preliminary. Does anyone have come to a
good classwork already?
There are two approaches to this.
One is to build your database interface on the idea that an entity in the
database equates to an object on your interface. This will tend to be a very
static way of looking at things and, therefore, your SQL interface will use
static SQL in dealing with the database (which is a performance advantage).
The problem will be dealing with strange queries, though (but maybe not much
of a problem). For instance, when joining two entities, which "object" has
control of the join (on which do you define it as a member function).
The other approach is to build your database interface on the idea that a
relational database is a form of object-oriented database. That is, build
objects of the form Database, Table, View, Tuple, Attribute, etc. This will
be a very dynamic approach using (potentially) a lot of dynamic SQL (thus it
may have performance problems). However, it is also a very flexible approach
that may allow you to do things simply that the first approach couldn't even
touch (adding new tables or views should be child's play).
The tradeoffs, though, are yours to decide on.
--
====================================================================
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!"awe@iclswe.icl.se (Anders Weister) (10/23/90)
basti@orthogo.UUCP (Sebastian Wangnick) writes: >hcnbakk@cs.vu.nl (Bakker HCN) writes: >>Is there anybody out there who has experience with or information >>about: >>- the possibility to access a database form C++ in general, >>- the use of embedded SQL in C++ and >>- the coupling between INGRES and C++? I know of a Swedish company that has managed to include Embedded SQL in c++ programs accessing INGRES databases. But I do not know how it was done. -- +---------------------------+ ! Anders Weister, M.Sc ! ! ICL Data AB ! ! S- 194 85 Upplands Vasby !