[program_options] split_winmain
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.
Vitaly Grechko wrote:
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.
Then, I would *really* recommend using Unix-style command line splitting. Windows style is extremely unintuitive. - Volodya
2008/12/3 Vladimir Prus
Vitaly Grechko wrote:
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.
Then, I would *really* recommend using Unix-style command line splitting. Windows style is extremely unintuitive.
- Volodya
But your library does not contain function of Unix style splitting. This is why all this mess about. I of cause can google for this code, but I think that it is inconvenient to use two command line libraries (or one non-boost) and better to ask for improvement in boost. Your library is good and I'd like to use it. Do you plan to include some Unix command line splitting to your library or/and permit split_winmain in Unix until Unix splitting is implemented?
Thanks, Vitaly _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Vitaly Grechko wrote:
But your library does not contain function of Unix style splitting. This is why all this mess about. I of cause can google for this code, but I think that it is inconvenient to use two command line libraries (or one non-boost) and better to ask for improvement in boost. Your library is good and I'd like to use it. Do you plan to include some Unix command line splitting to your library or/and permit split_winmain in Unix until Unix splitting is implemented?
Linux command line splitting sounds like a reasonable addition. Can you file a feature request on svn.boost.org? Thanks, Volodya
participants (2)
-
Vitaly Grechko -
Vladimir Prus