Re: New Pro*C 2.0 and C++

In article <tssmithCvx85x.1GL_at_netcom.com>, tssmith_at_netcom.com (Tim Smith) writes:
|> jhalpin_at_netcom.com (Joe Halpin) writes:
|>
|> >In article <tssmithCvw2DI.D8J_at_netcom.com> tssmith_at_netcom.com (Tim Smith) writes:
|> >>choang_at_tdkt.mn.org (Carl Hoang) writes:
|> >>>How come the new Pro*C 2.0 won't work with C++ compiler? It says right in
|> >>>the doc and gives no explanation. The old version can. I really don't
|> >>>understand this move. Thanks.
|> >>
|> >>The reason is because Pro*C 2.0 includes a C parser, but not a C++
|> >>parser. I believe this was mentioned in the manual, but I don't have a
|> >>copy here at home to verify that. The C parser (with a preprocessor)
|> >>offers a lot of advantages for C people.
|> >>
|> >>Pro*C 2.1 (with Oracle 7.2, and soon to be in beta) will be compatible
|> >>with C++.
|> >>
 

|> >But you could just put all the Pro*C sections of the code into their own
|> >(ANSI C) modules, then compile and link them with the C++ code, right?
|> >Are there problems with Pro*C code being in different modules, (static
|> >variables, etc)?
|>
|> I believe this is possible, but haven't actually done it myself.
|>
|> --Tim (tssmith_at_netcom.com) (tssmith_at_oracle.com) (Not speaking for Oracle.)
|>

This is the correct (and supported) way of doing this. Embedd SQL in pure C code, and compile it with your C compiler. Link this module with your C++ code, and call the C functions from C++. Received on Mon Sep 12 1994 - 18:41:55 CEST