>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.