Re: ARG_VAL(1)

I think the person who originally asked the question wanted to have the code call ARG_VAL(1) in all cases except this new one. I think the answer is to create a function get_arg_val_one() which is called by the common function. The standard version of this is simply: FUNCTION get_arg_val_one() RETURN ARG_VAL(1) END FUNCTION This should be in a file on its own built into the library which contains the start up function. The single program (at the moment) which doesn't actually want ARG_VAL(1) should provide its own version of get_arg_val_one() which returns the string that is required. Unless the standard version of get_arg_val_one() is isolated in a file on its own, you will not be able to link the program which requires the special behaviour because you'll get doubly-defined symbol messages. This is only a variation on Timothy Hood's answer, but it has a crucial difference -- the external interface to the common function does not change at all. This is also a minor variation on what C++ compilers do to over-ride inherited behaviour; the details are just hidden better and are less ad hoc. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> PS: You might find it better to generalize the functionality more, so that the function called from the common code is: FUNCTION local_arg_val(n) DEFINE n INTEGER RETURN ARG_VAL(n) END FUNCTION The specialized case can then handle the call with n = 1 differently. Or whatever else is appropriate. Your code would then use local_arg_val() throughout to get arguments from the command line... >From: timothy.hood@sltrib.com (Timothy Hood) >Date: Sat, 10 Jun 1995 00:23:00 GMT >X-Informix-List-Id: <list.6536> > >K> Date: Fri, 9 Jun 1995 15:46:45 -0400 > >K> We have a common function that uses arg_val(1). For one particular program > > we'd like to change the value returned from arg_val(1) so that the > > common function does something else, this way we don't need to change the > > common function. > >OK, maybe it's just that it's getting late, but I don't understand. Tell me >if I'm off here: > >Your common function that uses arg_val(1) is in a library that you are >always compiling into every program, and you don't want to have to modify >it because then you'd have to recompile every program (to ensure >compatibility, etc.)? > >You want to handle a different value for arg_val(1) than you ever have in >any existing program, and don't anticipate needing that value for any other >program. > >I have an idea if this is the case, but whether it works depends on what >the library function does. What happens if the library function sees a >value of arg_val(1) that it doesn't expect? (i.e., what you are planning >to pass for this "unique" program? If it simply ignores the arg_val and >returns control back to the program, then you can have code like this: > ># begin standard code >...do program processing >...call std arg_val handler >call custom_arg_val_handler >...continue standard code > >All you have to do is create a function to handle the custom arg_val(1) and >call it right after you call the standard arg_val handler, or before other >code expects to use it. > >The drawback to this is that you've created redundant code, and if there's >any chance that you'd use this for something else, then you've increased >future maintenance. It might be best to "bite the bullet" and integrate >this into the standard handler.