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

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 Tue Nov 06 2001 - 12:16:58 CST