[Boost-users] [program_options] split_winmain

Subject: [Boost-users] [program_options] split_winmain
From: Vitaly Grechko (vitaly_at_[hidden])
Date: 2008-12-03 11:28:56

>Vitaly Grechko wrote:

>> Could _WIN32 be removed from program_options\parsers.hpp? There is no way
in
>> UNIX to parse command line independently from string. To use the library
I
>> had to dublicate parsers.hpp and winmain.cpp files localy with _WIN32
>> removed, which is ugly. Before this I tryed to define _WIN32 before
>> including parsers.hpp and undef after - this affected other boost headers
>> and did not compile.
>> I don't see the reason to have _WIN32 macro there because the code is
just
>> an algorithm and complied successfuly in all platforms. The meaning of
the
>> algorithm is in the name of the function 'split_winmain(...)'.
>> The use case example: command lines from Windows client machines go to
Unix
>> server for validation and logging. In this case split_winmain is
regularly
>> used on UNIX

>What 'validation and logging' can be possibly done on Linux, given Windows
command
>line? Why do you need to actually tokenize it?

>- Volodya

(Sorry for broken thread, It is my first message and I was a digest user and
Gmane does not contain my message)
Command lines can be sent by network from Windows to Linux program which
processes it and send back some result (client/server system). But this is
just a straightforward example. Other example: There is a tool that is
compiled on Windows and Linux. It does not have argc, argv because command
line is entered say in editbox. The tool should parse this line and the
algorithm should be the same in all operating systems to have single
behavior. In my case the user specifies a command line as an argument to a
function in script file. Probably it is safe to allow using split_winmain in
UNIX to avoid the hell described in previous message.