Re: command line arguments and processing of the arguments
From: Juha Laiho (Juha.Laiho_at_iki.fi)
Date: 10/12/03
- Next message: Josh Sebastian: "Re: Key Stroke Register"
- Previous message: Bill Godfrey: "Re: Key Stroke Register"
- In reply to: jeff: "command line arguments and processing of the arguments"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 12 Oct 2003 15:32:01 GMT
gregadelliot@hotmail.com (jeff) said:
>basically at the moment i have to do something like this
>
>c:\robot.exe motor1 ccw 45
>
>Im using the argv and agrc to do this,
...
>1 thing im struggling to get working is this where I select between 2
>routines (cw and ccw) I have at the moment this
>
>if (argv[2] == ccw)
If it's C you're using for your program, then you'll need strcmp() here
instead of direct comparision. Note also that the strcmp() doesn't return
the typical truth value, but is three'valued.
>The final thing is I have 6 motors to control so I could do lots of
>else ifs to select the correct motor routine, but is there a more
>elegant way to do this??
Well, whatever you do, you'll have a multi-branch selection. You can
use parsers and dispatch tables to hide this, though -- and the result
may be more aesthetic.
So, this way you'd have to assign token values for your different
choices (cw, ccw, ...), then code the choice into the token value
(this'd then be where you have your multi-branch code -- so, you
couldn't avoid it completely, after all).
So, here's a piece of very simplistic parser you could use -- pass
your argv[2] as a parameter to this, and it'll return a corresponding
numeric value.
int parse_token(char *tok)
{
int ret=TOK_INVALID;
if (!strcmp(tok,"cw")) {
ret=TOK_CW;
} else if (!strcmp(tok,"ccw")) {
ret=TOK_CCW;
}
...
return ret;
}
... and of course you need to have the TOK_... constants defined somewhere.
Another possibility for writing the parser would be to have an array of the
keywords and getting the TOK_... codes from the same array with use of
bsearch() function (if available on your platform).
Then, you need to have the actual utility functions, so functions that
do your real work:
int cw(int val)
{
...
}
(and ccw and others)
Note that the parameter lists and return types must be the same for
all utility functions (though return types need not be same with
parameter types).
Then you'll have your actual dispatch table. I'll build this in pieces,
so you can easier look up the details from some C reference.
typedef int t_handler(int); /* Define type of the handler function */
typedef t_handler *t_handptr; /* Define pointer type to the above */
typedef t_handptr a_handptr[]; /* Define array type of the above pointers */
Then declare and initialize a variable of the array type we built.
a_handptr dispatch = { NULL, cw, ccw }; /* Note: the handler functions must
be declared before this line */
... the above assumes value of TOK_CW to be one, and TOK_CCW to be two
(so that indeksing the array with TOK_CW returns a pointer to the cw
function). The NULL as element zero is to at least somehow catch invalid
values -- actually it should rather be an error function (and parse_token
should correspondingly be written to return 0 on error).
Ok, background work is now done -- now to the easy part of _using_ what
was built. Supposing that argv[2] contains 'cw' and a variable "val"
already contains value 45 as parsed out (and converted to an integer) from
the third command line argument, the following will actually call
'cw' function with argument 45.
res = dispatch[parse_token(argv[2])](val):
There, we're finished. So, there still is the multi-branch selection,
but it's elsewhere in the code, and encapsulates less functionality.
Overall there's more code than there was to begin with, but with this
approach modularity is better and main path of execution in the code is
clearer (though initially the above calling syntax through the dispatch
table may not seem so clear -- but it hopefully becomes clearer when you
think it as "calling the function indicated by argv[2]").
I would guess that in your program the motor to which the command affects
might be another parameter for the handler function, possibly with some
kind of data structure of motor information passed as a third parameter
to the handler functions. What the handlers would return in your case is
beyond me -- perhaps just a status telling whether the command could be
performed or not.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
- Next message: Josh Sebastian: "Re: Key Stroke Register"
- Previous message: Bill Godfrey: "Re: Key Stroke Register"
- In reply to: jeff: "command line arguments and processing of the arguments"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
