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...@gmail.com> wrote:

 > 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)

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...@gmail.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...@conexus.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...@sbcglobal.net> wrote:

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

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 :password;

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

I'm not a c/c++ developer by any means,so forgive me if i ask too
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...@conexus.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

On Sep 7, 10:57 am, Maxim Demenko <mdeme...@gmail.com> wrote:

 > I'm not a c/c++ developer by any means

By your answers, it seems to me like you are a more competent C++
developer than myself. :-)

You are absolutely right, that was indeed the problem.

Now I have a new one, to be posted next.

Thanks!

-Ramon

On Sep 7, 11:09 am, Ramon F Herrera <ra...@conexus.net> wrote:

I am glad to report that I am very close to building my first non-
trivial C++ program.

I began with a complex, operational C program.

The only issues left are conversions from "char *" to "unsigned char
*". My guess is that I should change all my strings to C++ string
type.

-Ramon

On Sep 6, 6:32 pm, Ramon F Herrera <ra...@conexus.net> wrote:

Aren't there Java compilers out there that will compile to
native code and not byte code?

I think the gcc will do this - a google appears to bring
up lots of stuff.

Paul...