Re: Converting 4GL to Unix-C/SQL

In article <1v4phjINNi7c@emory.mathcs.emory.edu>, walt@mathcs.emory.edu (Walt Hultgren {rmy}) writes: |> This is because converting to C will have no effect on many of the things |> that an I4GL program does. This is probably also true of any vendor's |> DBMS product that uses a client/server architecture. .... |> Then there is the consideration that your programs may alread be in C if |> you have the "c4gl" version of I4GL -- not pretty C, but C nonetheless :-). |> If you have the RDS version, it would still be worth your time to do some |> benchmarking. I'll second Walt's remarks, and add this: When we switched from c4gl to RDS, the users did not notice _any_ visible degradation in performance, even though we were going from a compiled language to an interpreted one. I expect that this would be true for most programs that are more bound by database operations than internal computations, and I think this situation is typical for 4GL programs. Of course, there are applications that _are_ bound by internal computations rather than by database operations, and in this case you don't want those internal computations to be written in 4GL. But rather than translating the whole program to C, you're probably better off writing those compute-bound operations as C functions, and calling those functions from the 4GL code. This could save a lot of headaches: if you don't get the C calling sequences to the Informix libraries exactly right, ugly things are likely to happen. And those calling sequences are subject to change from one version of Informix to the next. -- Harry Bochner bochner@das.harvard.edu