I have been using Pro*C/C++ for a while, but so far all my programs
have been written in C. I just started trying to run some C++
programs, the ones that come with the precompiler: cppdemo[1-3].pc

My problem is that I would like to modify the sys_include variable and
I can't

Every time I compile, there is a message:

System default option values taken from: /home/oracle/product/10.2.0/
precomp/admin/pcscfg.cfg

So, I figure that I need to modify that file. Since my Linux is
RedHat, I remove the entry that mentions SuSe. I updated the list of C+
+ directories.

Even after those changes the precompiler seems to keep on searching
include files in the wrong/old places.

TIA,

-Ramon

ps: The only demo that builds fine is cppdemo2.pc, because it doesn't
have an #include <iostream> statement.

--------------------------------

Those include directories down here should NOT be there. I removed
them from pcscfg.cfg

proc code=cpp 'sys_include=(/home/oracle/product/10.2.0/precomp/
public,/usr/include,/usr/lib/gcc-lib/i486-suse-lin
ux/2.95.3/include,/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include,/
usr/lib/gcc-lib/i386-redhat-linux7/2.96/includ
e)' iname=cppdemo3

Ramon F Herrera wrote:
Warning mentioned by you seems to come from
$ORACLE_HOME/precomp/lib/env_precomp.mk, there is the following
hardcoded definition of CPLUS_SYS_INCLUDE:

SYS_INCLUDE_PATH=/usr/include,/usr/lib/gcc/i386-redhat-linux/4.1.1/include,/usr/lib/gcc/i386-redhat-linux/3.4.5/include,/usr/l
ib/gcc-lib/i386-redhat-linux/3.2.3/include,/usr/lib/gcc/i586-suse-linux/4.1.0/include
SYS_INCLUDE='sys_include=($(ORACLE_HOME)/precomp/public,$(SYS_INCLUDE_PATH))'
CPLUSPLUS=g++
CPLUS_SYS_INCLUDE='sys_include=($(ORACLE_HOME)/precomp/public,$(SYS_INCLUDE_PATH))'

Despite the warning, c++ demos seem to compile fine on my system ( 11gR1
, RedHat 5.3)

Besides that, there is a Metalink Note 108440.1 (the note is about
precompiler not able to find new style header files without .h
extensions on sun, but may apply to Linux as well), which essentially
suggests following workarounds:
1) create symbolic links in your local directory to required headers (
e.g. ln -s /usr/include/c++/4.1.1/iostream iostream.h)
2) modify your sample program to enclose all includes into infndef block
(then the verification of headers will be skipped by precompiler and
deferred to compilation time, which should be ok) like:
#ifndef ORA_PROC

/* include all of the header files with no extension */
#include <ostream>
#include <istream>
#include .....

#endif


I just tried the second workaround and it does indeed eliminated
precompiler warnings.

Best regards

Maxim

Thanks so much, Maxim.

I have been looking around, searching the configuration files related
to Pro*C/C++ and have made an interesting discovery.

In order for the pre-compiler to work properly, there are two critical
files. They seem to be redundant, and we have to be VERY careful AND
keep a backup of the original version because it is very easy to screw
up the system.

These are the two files:

$ORACLE_HOME/precomp/admin/pcscfg.cfg (this has 2 lines only)

$ORACLE_HOME/precomp/lib/env_precomp.mk

One fundamental problem is that the sys_include path is defined in
both files, in a mysterious co-dependent way.

I am going to start by editing those two files, in parallel and use
trial and error to see if I can find a working sys_include.

My goal is to make the C++ compilation work. So far, I cannot even
compile the 3 samples provided.

-Ramon

On Sep 6, 5:56*am, Maxim Demenko <mdeme... (AT) gmail (DOT) com> wrote:

I am not sure whether my problem is the above. My system contains both
the "new" style iostream and another header iostream.h

I believe one of the reasons I am having such a hard time trying to
compile the provided sample programs is that I have 3 directories
under /usr/include/c++:

drwxr-xr-x 6 root root 4096 Feb 12 2007 3.2.3
drwxr-xr-x 6 root root 4096 Feb 12 2007 3.3.4
drwxr-xr-x 7 root root 4096 May 17 2007 3.4.3
lrwxrwxrwx 1 root root 5 May 17 2007 3.4.6 -> 3.4.3

and I am not sure which is (if any) the correct one. In my first
attempt none of the 3 sys_include paths point to any of the above
directories worked.

I am getting actual errors (could not find included bits/xyz.h) and
not warnings.

-Ramon

On Sep 6, 5:56*am, Maxim Demenko <mdeme... (AT) gmail (DOT) com> wrote:

Maxim,

Thanks again for your tips. I fixed the problem and now I can compile
the 3 provided samples: cppdemo1.pc, cppdemo2.pc and cppdemo3.pc.

I did not have to create any soft links. All I had to do is carefully
edit the following line in TWO files at the same time:

sys_include=(/home/oracle/product/10.2.0/precomp/public,/usr/include,/
usr/lib/gcc-lib/i386-redhat-linux/3.2.3/incl
ude,/usr/include/c++/3.2.3/i386-redhat-linux,/usr/include/c++/3.2.3)

The two files in question, which apparently need to be kept
synchronized, are:

$ORACLE_HOME/precomp/admin/pcscfg.cfg

$ORACLE_HOME/precomp/lib/env_precomp.mk

I will have more questions and comments about the precompiler, as I
claim that it provides the fastest possible access to Oracle, compared
with alternatives such as Java or PL/SQL.

-Ramon

On Sep 6, 10:04*am, Ramon F Herrera <ra... (AT) conexus (DOT) net> wrote:

snip

Have fun ... I think the point is that depending on what you can do
with C ... you can write some fast running programs against an oracle
database.

You will have to do apples to apples comparisons in the types of
processing you do in plsql versus c of course.

It would be real nice to have some benchmarked samples for test cases
of C versus plsql versus java!

On Sep 6, 11:03*am, John Hurley <johnbhur... (AT) sbcglobal (DOT) net> wrote:
John,

Perhaps my scenario is specific to me, but you don't need any
benchmarks to measure the following kind of performance differential.

In one of my main applications, I had a large number of very similar
(let's say identical) tables. Such tables, for policy reasons could
not be combined into a big one.

My application was like this:

for table = client1 ... client1000
Retrieve stuff from table
end for

The above can be coded in two ways:

(1) The whole thing (external loop and actual SQL access) is coded in
PL/SQL

(2) The external loop can be written in an efficient and fast language
such as C/C++ and the inner SQL access in "EXEC SQL" (aka Pro*C/C++).

The fundamental problem in my case is that Oracle doesn't like it too
much when the table name is a variable, it seems.

In any event, my latest approach (2) is orders of magnitude faster
that my old, discarded approach based on pure PL/SQL (stored
procedures).

Your mileage may vary, of course.

As far as Java (one of my favorite all-time languages! - Have several
Java programs that I would never port) there is no way it can even
approach the performance of a native language.

-Ramon

I have a new question. I took a C program that precompiled, compiled,
linked and executed perfectly.

Now I am trying to convert it into a C++ program.

My current problem is that the following four variables are not
recognized by the C++ precompiler:

varchar username[UNAME_LEN];
varchar password[PWD_LEN];

EXEC SQL CONNECT :username IDENTIFIED BY assword;

int howMany;
varchar table_name[SOME_SIZE];

EXEC SQL SELECT COUNT(1) INTO :howMany FROM user_tables WHERE
table_name = :table_name;


It seems like the variables embedded into the EXEC SQL statements need
a different syntax?

TIA,

-Ramon

Ramon F Herrera wrote:
obvious question, but did you included your variable definition into
declare section ( as in cppdemo1.pc ) ?
If i understood it properly,
EXEC SQL BEGIN DECLARE SECTION;
varchar username[UNAME_LEN];
varchar password[PWD_LEN];
int howMany;
varchar table_name[SOME_SIZE];
EXEC SQL END DECLARE SECTION;

is required for c++ mode.

Best regards

Maxim

On Sep 7, 10:36*am, Ramon F Herrera <ra... (AT) conexus (DOT) net> wrote:
I found the solution to this one, in cppdemo1.pc:

// Declare section is required when CODE=CPP and/or PARSE={PARTIAL|
NONE}

-RFH