Re: ECPG and C++ compilation

On Fri, 2003-02-21 at 02:37, Demetres Pantermalis wrote:
> Thanks for your reply.
>
> However, I don't think that the problem has to do with C or C++ code (as
> source) and as a proof, all of the examples in the test directory compile
> without a problem with the C++ compilers, except test2.pgc and test3.pgc
> which include VARCHAR definitions (and test4.pgc which has a different
> problem - at line 15 text[10] should be changed to text[11]).
> The problem is more specific with the generated code from 'ecpg' regarding
> this VARCHAR type.
>
> A more detailed investigation on the issue:
> The generated code contains the following lines:
> #line 20 "test2.pgc"
> struct personal_struct {
> #line 20 "test2.pgc"
> struct varchar_name { int len; char arr[ 8 ]; } name ;
>
> #line 21 "test2.pgc"
> birthinfo birth ;
> } personal , * p ;
>
> and after some other lines, the 'varchar_name' struct is used to 'fetch'
> from the cursor in the following way:
> while (1) {
> strcpy(msg, "fetch");
> { ECPGdo(__LINE__, NULL, "fetch cur", ECPGt_EOIT,
> ECPGt_varchar,&(p->name),8L,1L,sizeof(struct varchar_name),
> ECPGt_int,&(i->ind_name),1L,1L,sizeof(int),
> ECPGt_long,&(p->birth.born),1L,1L,sizeof(long),
> ECPGt_long,&(i->ind_birth.born),1L,1L,sizeof(long),
> ECPGt_short,&(p->birth.age),1L,1L,sizeof(short),
> ECPGt_short,&(i->ind_birth.age),1L,1L,sizeof(short),
> ECPGt_char,&(married),0L,1L,1*sizeof(char),
> ECPGt_long,&(ind_married),1L,1L,sizeof(long),
> ECPGt_int,&(children.integer),1L,1L,sizeof(int),
> ECPGt_short,&(ind_children.smallint),1L,1L,sizeof(short),
> ECPGt_EORT);
>
> Everything is OK for C, but for C++ the struct 'varchar_name' is considered
> an incomplete type and therefore the sizeof(struct varchar_name) produces
> the error. Replacing sizeof(struct varchar_name) with a constant value (ie
> 4(for len)+8(for arr) =12) then the compilation with the C++ compiler is
> successful...
> I've run some tests with Oracle's ESQL preprocessor just to see what is
> produced. Oracle does something similar but seems to calculate the sizeof
> the structure and uses this value instead of sizeof(struct ...).
>
> Another solution is to 'typedef' the varchar_name structure, before the
> definition of the personal_struct (ie typedef struct varchar_name { int len;
> char arr[ 8 ]; } varchar_name;) and then use 'varchar_name name;' inside
> the personal_struct (...but this means post-process the pre-processor's
> output!!! ).
>

I don't think that will work. I can never get ecpg to recognize
typedefed structs, even when declaring the typedefed struct within a
DECLARE SECTION.

Probably doing the sizeof calculation within ecpg would be the proper
way to go, and using that value in the ECPGdo call instead of
sizeof(whatever). With respect to C++, anyhow. I'm sure the developers
would accept a patch, but realize that ecpg generates native C code, and
follows C conventions. C++ may parse the code differently in some
cases. Your best bet is going to be using the C compiler on these files
to generate you object code, and your C++ compiler on your native C++
code, as Peter suggested.

>
> -----Original Message-----
> From: Peter Eisentraut [mailto:peter_e(at)gmx(dot)net]
> Sent: Thursday, February 20, 2003 7:16 PM
> To: Demetres Pantermalis
> Cc: pgsql-interfaces(at)postgresql(dot)org
> Subject: Re: [INTERFACES] ECPG and C++ compilation
>
>
> Demetres Pantermalis writes:
>
> > What I get is the following error:
> > test2.pgc: In function `int main()':
> > test2.pgc:71: `sizeof' applied to incomplete type `varchar_name'
> > test2.pgc:101: `sizeof' applied to incomplete type `varchar_name'
> >
> > Can anybody suggest a method to overcome this problem?
>
> Use a C compiler to compile C code and a C++ compiler to compile C++ code,
> and then link them together if you are so inclined.
>

--
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...