c++ file compilation , which includes a header file , which in turn contains SQL statements.
bandi
I have a header file [ header1.h] which has some structure definitions
embedded in "EXEC SQL BEGIN DECLARE SECTION;" and "EXEC SQL END
DECLARE SECTION;" statments.
I have another header file [header2.h] which includes the header1.h
file.
header2.h file is included in a .cpp file [ source.cpp ].
Now, when i compile it, im getting these kind of errors:
EXEC SQL END DECLARE SECTION ;
^
variable "SQL" has already
been defined
EXEC SQL BEGIN DECLARE SECTION ;
^
identifier "EXEC" is undefined
etc............................
compilation syntax
c89 source.cpp -o source.o -I /ore/include/ -Wextensions -Wverbose -g -
Wlist -Wversion2 -Wnowarn -Woptimize=0 -c
/ore/include has the header files.
As SQL compilation is not allowed on cpp files, what is the way to do?
Thanks,
sateesh
Keith Dick
I notice that your c89 command does not include -Wsql, so it could not possibly have done the correct processing of embedded SQL statements, but I do not believe that just adding -Wsql will solve your problem. The manual explicitly says that you can only access SQL/MP from C, not from C++.
The recommended approach to use SQL/MP from a C++ program is to put the embedded SQL into C functions and call those C functions at the appropriate places in your C++ code. When doing this, remember that you should use extern "C" { ... } to enclose the function prototypes in the .h file for the C funcitons. You can put extern "C" { at the top of the .h file and the matching } at the end of the .h file, with all the function prototypes in between.
I'm not sure what is the reason for the restriction that SQL/MP cannot be accessed from C++ code. Since the way C++ is implemented is that there is a preprocessor that converts the C++ code to ordinary C code, then compiles the ordinary C code, there is a small chance that you could use the -WP option to tell c89 to do only the C++ preprocessing, then use another c89 command to compile the resulting file, with the usual options for compiling with embedded SQL/MP code. I have no idea whether it would work. I am sure that HP would not give you support if you encounter some problem doing that. And I don't recommend it at all. But if it would be a huge amount of work to put the embedded SQL statements into separate C functions, it might be worth experimenting in that way.
If someone out there knows of a reason why this might appear to work, but be a very bad approach, please explain.
Just to be clear here is what I am suggesting might work:
c89 source.cpp -I /ore/include/ -WP -Wversion2 -Wextensions
c89 source.ii -o source.o -I /ore/include/ -Wsql -Wverbose -g -Wlist -Wversion2 -Wnowarn -Woptimize=0 -c
It might be that you should not include -Wversion2 in the second c89 command. The -I /ore/include/ option probably is needed in only one of the c89 commands, but I'm not sure which one. I imagine it will not hurt anything to have it in the command where it is not needed. -Wsql also turns on -Wextensions so you would not need to include both in the second c89 command. I am not sure whether -Wextensions needs to be included in the first c89 command, but I imagine it will not hurt anything.
Once more, I don't know whether this will work, and I don't recommend it, but you can try it if you like.
Note that it *is* possible to use embedded SQL/MX statements in C++ code. I assume that there is some reason that you must use SQL/MP rather than SQL/MX. Even if you must access SQL/MP tables, you can do so via SQL/MX. But perhaps SQL/MX is not available to your project.
Joachim Schmitz
> bandi wrote:
>> Hi,
>>
>> I have a header file [ header1.h] which has some structure
>> definitions embedded in "EXEC SQL BEGIN DECLARE SECTION;" and "EXEC
>> SQL END DECLARE SECTION;" statments.
As a general rule Header files should never define things (i.e. generate
code or reserve memory), but only declare things "There is, in some module
but not here, a function foo returning an int and taking a char *,
futhermore there is an int by the name of bar", i.e. the interface.
Definition, AKA the implementation, belongs into .c or .cpp files
Embeded SQL generates code -> off into a .c or .cpp file
>> I have another header file [header2.h] which includes the header1.h
>> file.
>> header2.h file is included in a .cpp file [ source.cpp ].
>>
>> Now, when i compile it, im getting these kind of errors:
>>
>> EXEC SQL END DECLARE SECTION ;
>> ^
>> variable "SQL" has already
>> been defined
>>
>> EXEC SQL BEGIN DECLARE SECTION ;
>> ^
>> identifier "EXEC" is undefined
>>
>>
>> etc............................
>>
>> compilation syntax
>> c89 source.cpp -o source.o -I /ore/include/ -Wextensions -Wverbose
>> -g - Wlist -Wversion2 -Wnowarn -Woptimize=0 -c
>>
>> /ore/include has the header files.
>> As SQL compilation is not allowed on cpp files, what is the way to
>> do?
Opps, forget about what I said about .cpp and put the embeded SQL into a .c
file.
It is possible for a C++ Program to call functions from a C module (while
the opposite is not possible, due to the name mangling)
>> Thanks,
>> sateesh
>>
>
> I notice that your c89 command does not include -Wsql, so it could
> not possibly have done the correct processing of embedded SQL
> statements, but I do not believe that just adding -Wsql will solve
> your problem. The manual explicitly says that you can only access
> SQL/MP from C, not from C++.
> The recommended approach to use SQL/MP from a C++ program is to put
> the embedded SQL into C functions and call those C functions at the
> appropriate places in your C++ code. When doing this, remember that
> you should use extern "C" { ... } to enclose the function prototypes
> in the .h file for the C funcitons. You can put extern "C" { at the
> top of the .h file and the matching } at the end of the .h file, with
> all the function prototypes in between.
And this is how to tell C++ to deal with C-modules.
> I'm not sure what is the reason for the restriction that SQL/MP
> cannot be accessed from C++ code. Since the way C++ is implemented
> is that there is a preprocessor that converts the C++ code to
Is it? That was certainly the old CFRONT way of doing it, but I don't think
it is any longer.
Bye, Jjo
Anupam Das
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Got a reply from GMCSC like this -
Subject: C++ / SQL/MP
Hello,
HP Nonstop has no C++ with preprocessor for SQL/MP.
This is a product limitation – and there are no plans to lift this
limitation.
Please inform me how to proceed with this case.
Kind Regards
NonStop Specialist
Global Mission Critical Support Center
Hewlett-Packard Company
URL: http://www.hp.com
support center e-mail: GC...@HP.COM
Dave
> Note that it *is* possible to use embedded SQL/MX statements in C++ code. I assume that there is some reason that you must use SQL/MP rather than SQL/MX. Even if you must access SQL/MP tables, you can do so via SQL/MX. But perhaps SQL/MX is not available to your project.
This is probably the best solution and I believe when one purchases
SQL they get both MP and MX, so there is really no reason not to use
it.
Dave
Keith Dick
> limitation.
> Please inform me how to proceed with this case.
>
> Kind Regards
>
> NonStop Specialist
> Global Mission Critical Support Center
> Hewlett-Packard Company
> URL: http://www.hp.com
> support center e-mail: GC...@HP.COM
Yes, that is exactly the kind of response I would expect. After all, they explicitly say in the manual that they do not support SQL/MP in C++.
I got the idea from looking at the documentation for the c89 command in the OSS Shell and Utilities Reference Manual and remembering how the old C++ implementations worked. Older C++ systems used a preprocessor to convert C++ code into pure C code, then used a normal C compiler to compile that C code. When I saw that c89 has the -WP flag which causes it to store the source code after it has been preprocessed, I thought it might be possible that this preprocessed code was like the old days and was already converted from C++ to pure C. If that were true, then maybe you could take the preprocessed code (which I assume would still contain the embedded SQL statements unchanged) and tell c89 to compile that as C code with embedded SQL/MP.
Unfortunately, I do not have access to a NonStop system to be able to experiment and see whether those guesses are correct.
One of Joachim's comments says he thinks the C++ system no longer converts to pure C, so it probably is true that this whole approach won't work. If you want to check into it to be sure, just take a small C++ source file, run c89 with the -WP option, and look at the resulting .ii file and see whether it still contains C++ statements or they have been converted to C statements. If they are still C++ statements, then this approach cannot be used to trick the software into accepting SQL/MP embedded in C++ code. If that is the case, that probably is good, since tricks like that frequently get you into some trouble down the line, even if they seem to work at the start, since the vendor doesn't support them.
So if that trick will not work, then the two options available are to use SQL/MX embedded in C++ (SQL/MX can access SQL/MP tables), or put the embedded SQL/MP into functions in pure C source files and call those C functions from the C++ code.
red floyd
> I got the idea from looking at the documentation for the c89 command in the OSS Shell and Utilities Reference Manual and remembering how the old C++ implementations worked. Older C++ systems used a preprocessor to convert C++ code into pure C code, then used a normal C compiler to compile that C code. When I saw that c89 has the -WP flag which causes it to store the source code after it has been preprocessed, I thought it might be possible that this preprocessed code was like the old days and was already converted from C++ to pure C. If that were true, then maybe you could take the preprocessed code (which I assume would still contain the embedded SQL statements unchanged) and tell c89 to compile that as C code with embedded SQL/MP.
>
The -WP flag stores the result of the C/C++ preprocessor -- that is,
#include/#define/#ifdef processing.
Keith Dick
Okay, that seals it -- this will not give a way to work around the inability to put SQL/MP into C++ code. Thanks for the answer.
So the original poster should try one of the other two approaches, unless someone out there knows of another possible solution.