Re: Any Pro*C/C++ users out there?
Maxim Demenko
> 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
>
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
Ramon F Herrera
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
Ramon F Herrera
> 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
Ramon F Herrera
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
John Hurley
snip
> 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.
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!
Ramon F Herrera
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
Ramon F Herrera
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
Maxim Demenko
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];
varchar table_name[SOME_SIZE];
is required for c++ mode.
Best regards
Maxim
Ramon F Herrera
I found the solution to this one, in cppdemo1.pc:
// Declare section is required when CODE=CPP and/or PARSE={PARTIAL|
NONE}
-RFH
Ramon F Herrera
> Ramon F Herrera wrote:
> > 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
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
Ramon F Herrera
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
Paulie
On Sep 6, 6:32 pm, Ramon F Herrera <ra...@conexus.net> wrote:
> 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.
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...
> -Ramon