RDS VS. I4GL (WAS: HOW TO

J> From: jschumac@uns-dv1 (Joel Schumacher) J> So, you start developing more and more C routines to do all the things > 4GL can't do. You have hundreds of C routines that aren't used by ALL > your executables. One may use a dozen routines and another a different > dozen. With r4gl, you have 2 options: J> 1) create this HUGE runner that has every C routine you've written > so you can execute any module. (Anyone know of a maximum size > for a runner?) J> 2) you come up with a zillion specialized runners for each possible > combination of C routines your code is using and try to remember > what runner to use for what programs. You can always take advantage of a Makefile if you go the second route. You would only need to change it if you add/change custom C routines. Generally, though, most 4gl programs do not have an unwieldy number of C functions. J> With i4gl, you just put your .o files for your hundreds of C routines > into a library and link it in. The compiler picks and chooses the > routines it needs from the library automatically. No need to worry > about which runner you need to run your code. If the compiler can't > find something, it'll let you know at compile time, not runtime. Yes, clearly that's less overhead. BTW, part of the testing procedure should include thorough system testing on the deliverable object code before it's released to beta. It's o.k. if your unit testing is different, but nobody should ship without the proper system test. Also, once you know the rules about the few circumstances where the RDS and C versions differ, it's easy to deliver code that can overcome those differences, as there aren't very many. In fact some of the differences show up as problems in RDS but not C, (I'm thinking of the temporary string space problem, for example), and thus require the RDS programmer to build better code. #include <two_cents.h> Tim --- ~ SPEED 1.40 [NR] ~