Re: C++ and Informix

Phillippe, You make some interesting points. On Sun, 26 Oct 1997, Philippe Verdy wrote: } Nick Nobbe a =E9crit dans le message <628qi0$2s2@cssun.mathcs.emory.edu>.= =2E. } >On Fri, 17 Oct 1997, Vijay Kammila wrote: } >> I have some programs written in C using INFORMIX-ESQL Version 7.22.UC1= =2E } >> If I want to change them to C++, do I need a different esql that } >> supports C++ or is it just that the files should have different } >> .extensions (like .C instead of .c and .???? instead of .ec) and } >> different compiler options (instead of esql XXX.c XXXX.ec)? } >> } > Vijay, } > I remember Jonathan Leffler gave a brief talk on how to do c++ with } > esqlc at the WAIUG forum in 1996. You will probably find more info } > (the correct kind) at the IIUG cdi archives site at www.iiug.org and } > and possibly in one of our newsletters at www.iiug.org/~waiug . } > And I think you have to mess with your includes also. } There are also other language features that ESQL/C does not support } natively, even using ANSI C with strong prototyping. } I simply solved the problem by using dummy declarations for ESQL/C } enclosed between #if 0 ... #endif pairs, in addition to strong type } declarations. } A good writing of it is for example: }=20 } #define ESQLC_DUMMY 0 } ... } int foo(char *bar, int foobar) } #if ESQLC_DUMMY } EXEC SQL BEGIN DECLARE SECTION; } char *bar; } int foobar; } EXEC SQL END DECLARE SECTION; } #endif } { } ... } } An interesting technique. I use the alternative: int foo(char *p_bar, int p_foobar) { =09EXEC SQL BEGIN DECLARE SECTION; =09char *bar =3D p_bar; =09int foobar =3D p_foobar; =09EXEC SQL END DECLARE SECTION; This is a nuisance, but reduces the possible problems with changes to the parameter names going unnoticed. One nasty feature I found in ESQL/C is: int somefunc(a, b) $char *a; $int b; { =09... } int notherfunc(int c) { =09int b =3D (c * 53 + 13) % 29; =09EXEC SQL OPEN somecursor USING :b; } /* 7.23.UC1 on Solaris 2.5.1 -- try it! */ I discovered this when I rearranged some code in a file and a variable showed up as undeclared. } You can use such dummy declarations that ESQL/C understand, and still } benefit of strong typing of ANSI C or C++. } Sometimes, you'll have to use simplified declarations of your typedefs, } and structure declarations. ESQL/C will still generate the correct code, } provided types are convertible, I agree that it will work in the short term, but I don't like fibbing to compilers; they get they're own back on the maintenance team later. } because all the generated C statements will reference your real } declarations, not those between the #if 0 #endif pairs which won't be } compiled. } Such constructs allow easier management of calling conventions, memory } models for arrays and pointers, C or C++ features, strong datatypes, ... } More, you do not need to declare all members of your structures in dummy } declarations, but just those data members that you need to reference in y= our } ESQL/C statements, i.e. structure pointers, structure names, char[] and } numeric datatypes, and so on... } If it causes too much work, just declare additionnal simple C working } variables to run with ESQL/C statements, and make appropriate copies. That's what I do; I think it is more reliable because there are no half-truths being spoken. Also, the 7.24.UC1 ESQL/C has considerably better support for C++ source code. It recognizes the .C, .cpp, .cxx (but not .cc?) extensions as C++ source code, and .ecpp as an ESQL/C file which needs to be compiled by the C++ compiler. It appears to link with the C compiler, which is unlikely to work too well. Oh well, a makefile can fix all that. Yours, Jonathan Leffler (johnl@informix.com) #include <witticism.h>