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

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! Graeme Sargent replies: ->>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) Jonathan Leffler ripostes: ->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> I like Jonathon's approach here. While Graeme has a legitimate point about what we poor programmers must do when we can't control the requirements and design, we CAN control the partitioning of the design in our code. Jonathon's partitioning clearly separates the interface issues from the functionality issues. I believe that it will result in easier to maintain code. Regards, Alan +------------------------------+---------------------------------------+ | R. Alan Popiel | Internet: alan@den.mmc.com | | Martin Marietta, LSC *^%#! remainder of .sig eaten by .sig virus ...