C++ - Question on Parsing Command line args..

[LordVader]

Small function for reference that get's command line arguments built from the msdn CommandLineToArgvW reference ..

Code Select Expand


void CheckCmdLine()
{
LPWSTR *szArgList;
int nArgs;

// stores the command line includes the following:
// program path/name, and "ALL" command arguments and the total number of arguments is stored into nArgs
szArgList = CommandLineToArgvW(GetCommandLineW(), &nArgs);

//If the command line fails szArgList is empty/null
if(NULL == szArgList)
{
//throw an exception or error here something went wrong.
}

//look for arguments don't include the patch/exe name which is nArgs == 1,
else if(nArgs >=2)
{
//Just an example to catch -gui sent thru the command line
if(!strstr((char *)szArgList," -gui"))
{
// Do stuff for the switch\trigger -gui
}
}
LocalFree(szArgList);
}

usage:

Code Select Expand


INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int mdShow)
{
CheckCmdLine();
return 0;
}

*Note this is for win32 applications not thru a console program.

Have you tested this?  I can't see that it would work, since you're checking for an ANSI string inside the pointer to your Unicode argument.  Hint: don't just blindly throw in typecasts when you get a compiler warning.

Yes the example I gave does work, about recasting the type in the function I gave..
All im doing is comparing strings to find instances of a given string, not moving/shifting any data:

Code Select Expand


if(!strstr((char *)szArgList," -gui")) // szArgList innitially is cast as: LPWSTR *szArgList;


Would that actually recast szArgList to char * overall?
Or just for checking within !strstr() ?
Both data container's are null terminated strings.
Curious, what would adverse affects of checking it this way be, even tho one is Unicode vs other as Ansi.
Aren't both null terminated strings resulting in no issues checking this way?

Keep im mind im used to windows, I do not know how other operating systems or compilers would treat that.
But in both visual c++ 6 & 7, it works fine as long for strstr you do:
(char *)szArgList, to compare  LPWSTR *string pointer <- to -> some string to find it in a  instance of a given string...

It did have issues sending LPWSTR data type to strstr, but (char *)szArgList did work with no errors/warnings.

You could probably just use a switch statment for szArgList probably to be a Bit cleaner.
Something like the given example:
Switch Statements on msdn.
Just substitute LPWSTR *buffer for char *buffer in that example..

Haven't tried that yet.

I'm sure their are better cleaner ways to do it, that was just the first thing I tried that did work.

[Kp]

I'm sure their are better cleaner ways to do it, that was just the first thing I tried that did work.

When I said it wouldn't work, I meant it in the sense that strstr will never return a match.  Your typecast is causing the compiler to assume you know what you're doing and build it anyway.  As a result, you're looking for the string "-gui" as a substring of the ANSI string composed of the first character of the Unicode argument.  Seeing as one character is definitely shorter than "-gui", strstr will never match.

Also, strstr returns a pointer on success, or NULL on failure.  So your test is asking whether -gui failed to match, not whether it successfully matched.

[LordVader]

Ok I see what your saying, and you're correct.. but it does work oddly atleast passing an argument I didn't try passing different arguments other than -gui to see if it worked that way.
Basically I just put a message box within the !strstr if check, with no arguments it launches  with no message, with -gui it found and launched the message box..
Didn't try other arguments tho to see if "anything" passed would trigger the message..

I do see the flaws in it tho with what you said Thx

Anyway i'll work on the string searching/matching sometime, the rest tho should work fine.

[Kp]

Ok I see what your saying, and you're correct.. but it does work oddly atleast passing an argument I didn't try passing different arguments other than -gui to see if it worked that way.
Basically I just put a message box within the !strstr if check, with no arguments it launches  with no message, with -gui it found and launched the message box..
Didn't try other arguments tho to see if "anything" passed would trigger the message..

I do see the flaws in it tho with what you said Thx

Anyway i'll work on the string searching/matching sometime, the rest tho should work fine.

This behavior is also entirely consistent with the broken code you posted.  If no arguments are supplied, then it will not hit your erroneous strstr check.  If any arguments are supplied, strstr will run (and fail to match), causing your if test to be true.