Re: Pro*C++: Useless when working with multithreaded C++ applications?

I'd suggest that you try separating the Oracle Pro*C calls into a separate C library, and having your C++ code make calls to the C library. That's worked for us.

There are plenty of C constructs that the Pro*C precompiler can't deal with, not to mention C++ constructs.

The name of the precompiler used to Pro*C, it's relatively recently that they've made enough modifications to allow the precompiler to be renamed Pro*C/C++.

"Ed prochak" <ed.prochak_at_alltel.com> wrote in message news:e51b160.0111061016.63f63baf_at_posting.google.com...
> I don't have a solution for you, but I'm added a few comments.
>
> apinge_at_carl.org (Atul Pinge) wrote in message
news:<5939461c.0110311045.de6a989_at_posting.google.com>...
> > Hello everybody,
> >
> [rant removed]
> >
> > 1. First and the biggest problem is it does not understand
> > C++ program structure at all.
>
> well, yes that's precisely true.
> It's documented in the manual that this is a PREPROCESSOR. it does
> little more than text substitution. Did you really expect ORACLE to
> write a regular compiler for each of the languages they support?
>
> > If you want to write C++ programs
> > you need to add code=cpp as preprocessor option. As soon as you
> > do that the default option parse=partial has to be added. If
> > you do that you preprocessor does not understand variables
> > defined outside EXEC SQL DECLARATION SECTION BEGIN and END
> > statements. That means that I cannot include private variables
> > of the class used as host variables. (Cool!)
>
> Not quite sure you like this or hate this.
>
> >
> > 2. Then Pro*C++ preprocessor after preprocessing creates lots
> > of global variables in the file. So we need to put all the
> > EXEC SQL statements only in one .cpp file. Because otherwise
> > we get compilation errors saying that same global variables
> > are defined at multiple places.
>
> yes, painful, but not overwhelming.
>
> >
> > 3. Since every host variable needs to be defined between
> > EXEC SQL DECLARATION SECTION BEGIN and END statements you
> > cannot even pass host variables as arguments to the functions.
>
> this does lead to a lot of data copying between host and local
> variables.
>
> >
> > 4. Sometimes there are ugly work arounds possible. But that
> > makes your code look really really ugly. To give an example,
> > since you cannot define a argument variable to be used as a
> > host variable you can pass in a variable and then copy it
> > into a variable defined between EXEC SQL DECLARATION SECTION
> > BEGIN and END. Or since you cannot define a private class
> > variable as an host variable, define a local variable in
> > EXEC SQL DECLARATION SECTION BEGIN and END in EACH method
> > and copy the private variable into it.
>
> so items 3&4 are the same.
>
> >
> > 5. Most of the example programs given in Oracle documentation
> > are written using C and NOT C++. So they do not address all
> > the problems mentioned above at all. Hence the documentation
> > is pretty much useless in many cases.
>
> I work mainly in C, so I haven't missed the C++ examples. You've got
> another valid concern here.
>
> >
> > 6. It's extremely difficult to get any help for the problems.
> > I tried to post messages in newsgroups. No answers. Many
> > times people just ask me to contact Oracle customer support.
>
> and have they (ORACLE support) helped at all?
>
> > If I search in Oracle metalinks database, many of the problems
> > are reported as bugs. And if they are not, then there are
> > really ugly work arounds available which may not even be
> > practical to do (For the problem I was facing it was suggested
> > that declaration of cursor, opening of cursor and fetching
> > should be done in one function or method! What if I cannot
> > do that?!!!).
>
> Are you sure you cannot?
>
> >
> > 7. When I contacted Oracle customer support, all they keep
> > saying is upgrade to the next version. In our case, we have
> > about 500 customer sites. If we want to upgrade all of these
> > sites its quite a project in itself!
>
> (here's the answer to my question on item 6) but,
> what version are you using? Maybe the answer really is to upgrade.
> Must you upgrade the database, or just the Pro*C++ preprocessor?
>
> >
> > Pro*C++ is the first Oracle product I started using and I must
> > say I'm not impressed with it. I'm writing this post hoping
> > that somebody still has answers to all these questions otherwise
> > they know what kind of problems will they be facing using Pro*C++.
> > I wish I had seen an article like this before I stared.
> >
> > Atul
>
>
> Sorry, Atul that you have had so much problems. Part seems to extend
> from high expectations on your part (ProC++ understanding C++ syntax)
> and some from possible problems in the product itself.
>
> Some of the "workarounds are not really that ugly:
> encapsulating embedded SQL in a single data services package
> migrating some of the functionality to other languages (eg move
> queries to functions in PL*SQL packages and invoke the functions, or
> move sql to a straight C library and invoke the functions that way.)
>
> Multithreaded applications can be very difficult to wrote with or
> without ProC++ issues. I wish you good luck in finding acceptable
> solutions.
>
> Ed Prochak
Received on Wed Nov 07 2001 - 04:55:39 CET