It is currently Thu Oct 19, 2017 2:16 am

All times are UTC - 5 hours




 Page 1 of 1 [ 5 posts ] 
Author Message
 Post subject:
PostPosted: Tue Jul 24, 2007 6:27 pm 
Site Admin

Joined: Sun Feb 11, 2007 8:59 am
Posts: 1105
Location: Ontario Canada
In this VMK I show you how to handle command line input passed into your game from the command console. I also show you how to do the same thing within visual studio. We use this functionality to bypass the splash screen during development.


Offline
 Profile  
 
 Post subject: Re: GameDev VMK 36 - Command Line Input
PostPosted: Thu Sep 06, 2007 7:02 am 
Site Admin

Joined: Sun Feb 11, 2007 8:59 am
Posts: 1105
Location: Ontario Canada
I have a feeling that I may have introduced a compiling bug into the GameEngine project. I am finishing up some work now on VMK38C and I see that the project doesn't build properly. If you are having problems compiling your program, let me know and I can tell you how to fix it. Alternatively, watch VMK38C and you will see how to fix everything.


Offline
 Profile  
 
 Post subject: VMK36: evaluate boost::program_options
PostPosted: Wed Apr 22, 2009 1:41 am 

Joined: Wed Aug 06, 2008 7:53 pm
Posts: 182
Location: Russia
Just for information.
Boost set of C++ libraries owns a very powerful library called program_options.

http://www.boost.org/doc/libs/1_38_0/do ... tions.html

It can help whenever you extract program options either from command line or configuration file and especially suitable for big projects with sophisticated repertoire of the options (such as compilers etc).
A short description:
Boost::Program_options -> Vladimir Prus wrote:
The program_options library allows program developers to obtain program options, that is (name, value) pairs from the user, via conventional methods such as command line and config file.

Why would you use such a library, and why is it better than parsing your command line by straightforward hand-written code?

It's easier. The syntax for declaring options is simple, and the library itself is small. Things like conversion of option values to desired type and storing into program variables are handled automatically.

Error reporting is better. All the problems with the command line are reported, while hand-written code can just misparse the input. In addition, the usage message can be automatically generated, to avoid falling out of sync with the real list of options.

Options can be read from anywhere. Sooner or later the command line will be not enough for your users, and you'll want config files or maybe even environment variables. These can be added without significant effort on your part.

:roll:


Offline
 Profile  
 
 Post subject: VMK36: __targv is much better
PostPosted: Wed Apr 22, 2009 1:57 am 

Joined: Wed Aug 06, 2008 7:53 pm
Posts: 182
Location: Russia
Although this VMK is full of all kinds of merits and virtues, one can find there one unexpectedly suspicious fragment:
TCHAR **GetArgvCommandLine(int *argc) {
    #ifdef UNICODE
        return GetCommandLineW(argc); // <- Wrong! Utterly wrong!! ;)
    #else
        *argc = __argc;
        return __argv;
    #endif
}

I bet Marek has never run UNICODE branch of this code. ;)

Actually GetCommandLine has following declaration:
LPTSTR WINAPI GetCommandLine(void);
This function has no parameters and returns a pointer to the command-line string for the current process (it might be either ASCII or UNICODE string depending on the project option). Note, it returns TCHAR *, not TCHAR **.

To fix this we can use a function from the Shell API:
TCHAR **GetArgvCommandLine(int *argc) {
#   ifdef UNICODE
        return CommandLineToArgvW( GetCommandLine(), argc ); // a tiny bit better ;)
#   else
        *argc = __argc;
        return __argv;
#   endif
}


However this code still has a couple of shortcomings:
• It is necessary to release the memory after the use of CommandLineToArgW(), e.g. call LocalFree( argv ). Too bad, since ASCII branch does not need the memory deallocation at all.
CommandLineToArgW() lives in "shellapi.lib" => a programmer should include <shellapi.h> and import the library "shellapi.lib".

Luckily, there is much more simple way:
TCHAR **GetArgvCommandLine(int *argc) {
    *argc = __argc;
    return __targv; // works fine in both Unicode & Ascii modes
}


Depending on the project option __targv will be expanded as __agrv (ASCII version) or __wargv (unicode). But not everything is so smooth. To make it working we should convert our WinMain(int, int, char*, int) function to its T-aware counterpart:
_tWinMain(int, int, TCHAR *, int);

Then, if ASCII mode is in action _tWinMain is expaded (at compile time) as WinMain(int, int, char*, int). In Unicode mode it will be wWinMain(int, int, wchar_t*, int).
What is especially important is that the compiler/linker is able to discriminate both of these forms and incorporate in the target exe the call (or the code itself) of correct CRT initialization procedure: wWinMainCRTStartup (for Unicode mode) or WinMainCRTStartup (for Ascii mode) appropriately.



8)


Offline
 Profile  
 
 Post subject: __argv vs __wargv: only one is valid while the othe is 0
PostPosted: Wed Apr 22, 2009 2:11 am 

Joined: Wed Aug 06, 2008 7:53 pm
Posts: 182
Location: Russia
Both pointers char** __argv and wchar** __wargv are declared in stdlib and both of them exist in the target exe. But only one of them has valid pointer to the command line parameters table, the other is NULL:

---------+----------+---------
 MODE    |  __argv  | __wargv
---------+----------+---------
 ASCII   |  valid   |  NULL
 UNICODE |  NULL    |  valid
---------+----------+---------



_________________
«Computer scientists deal with algorithms that you may call practical in theory but unpractical in practice.» © Timothy Gowers
Offline
 Profile  
 
Display posts from previous:  Sort by  
 Page 1 of 1 [ 5 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Jump to:  

cron