Re: memory leak (well, kind of...) ?

>From: uunet!pyra.co.uk!graeme (Graeme Sargent) >Subject: Re: memory leak (well, kind of...) ? >Date: Wed, 12 May 1993 09:47:59 GMT >X-Informix-List-Id: <news.3296> > >Jonathan Leffler writes: >>Why on earth would a sane ESQL/C programmer use a function which is only >>required to allow you to communicate with I4GL in an ESQL/C (and not I4GL) >>program. Someone has seriously misread the manual (or misunderstood it), >>to even think of doing that! > >How about when writing a library function which is designed to be called >from ESQL/C or 4GL? > >(And no flames about whether that's good/bad/legitimate design or not, >it's still a valid reason if you're the programmer and not the designer) It is not a valid reason in my book. When I write an ESQL/C function which is also to be called from I4GL, then I split the code into two functions, probably named something like i4gl_FunctionA and FunctionA. The i4gl_FunctionA function is designed to be called from I4GL and handles the messy details of unpacking the I4GL parameters into something ordinary C (or ESQL/C) would use, calling FunctionA to get the work done using the interface a C program would naturally use, and then packing the return values. FunctionA is then the function that a programmer working in C (and therefore in ESQL/C) would use if they ignored I4GL altogether. I would regard this as a major design issue and I'd regard what I suggest as splitting the functionality correctly, and what you suggest as doing two different (though related) jobs in a single function, and I'd suggest that splitting the functionality is the better way of dealing with the problem. The interface that I4GL uses to call C is as unnatural a way of dealing with C as I can (or want) to think of, so I hide it as best I can from programs written in C (or ESQL/C). And I also put the I4GL interface code either into a separate source file or surround it with #ifdef I4GL so that when the function is used in ESQL/C, I don't get the I4GL external references in my ESQL/C program. Yours in friendly disputation, Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>