Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases Subject: Re: C++ Interface to SQL Message-ID: Date: 24 Jan 91 19:39:33 GMT References: <1991Jan24.034312.20923@infonode.ingr.com> Sender: davidm@cimshop.UUCP Distribution: comp.databases Organization: Consilium Inc., Mountain View, California Lines: 25 In-reply-to: tensmekl@infonode.ingr.com's message of 24 Jan 91 03:43:12 GMT X-Posting-Software: GNUS 3.12 [ NNTP-based News Reader for GNU Emacs ] >>>>> On 24 Jan 91 03:43:12 GMT, tensmekl@infonode.ingr.com (Kermit Tensmeyer) said: Kermit> Has anybody come up with either a C++ base object for manipulating Kermit> Oracle tables or a good C data/method hiding module source set. One of Kermit> the problems with dealing with Pro*C and C++ is that each set thinks Kermit> that it's the only preprocessor to Old C. Has anyone come up with a Kermit> good set of makefile rules for dealing with this combination? In general, put the SQL calls in C ONLY! functions and build your C++ code to call these functions at an appropriate time. Mark the functions as 'extern "C"' in your C++ code an compile everything normally into object modules. The last step would be to link the SQL/C object modules with the C++ object modules and let the linker resolve everything. No hassling with trying to get a preprocessor (say Pro*C) to recognize something it wasn't set up for (C++ code) as each preprocessor only works on stuff that it knows. Then you establish file naming conventions like .SC for Pro*C files and .CXX for C++ files and define your makefile rules accordingly. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"