Re: [Boost-users] program_options requires non-const argv
Steve, I ran into the same problem. Once I thought about it, I realized I had _never_ seen a C or C++ main() function prototype defined with a const second argument. I think I remember that one of the traditional C getopt() function variants actually munges the argument list by removing that arguments it recognizes, leaving anything else for direct processing by the program. I'm guessing program_options is therefore tacitly assuming the second argument is non-const also. Merrill
Merrill Cornish wrote:
Steve,
I ran into the same problem. Once I thought about it, I realized I had _never_ seen a C or C++ main() function prototype defined with a const second argument.
I think I remember that one of the traditional C getopt() function variants actually munges the argument list by removing that arguments it recognizes, leaving anything else for direct processing by the program.
I'm guessing program_options is therefore tacitly assuming the second argument is non-const also.
Simply, the standard says second argument of main is non-const. Using const version is strictly speaking, invalid, and in practice I recall there were some problems making both consts and non-const to work. - Volodya
On Jan 26, 2006, at 4:54 AM, Vladimir Prus wrote:
Simply, the standard says second argument of main is non-const. Using const version is strictly speaking, invalid,
There are circumstances where one wishes to pass something other than main()'s raw arguments to parse_command_line(). For example, I've refactored a suite of test tools to use a simple common command-line tool framework. In this framework, I save argc and argv as member variables which are initialized in the constructor of the base class of the framework. I defer the call to parse_command_line() to a method called sometime later, after derived classes have the opportunity to configure their unique options_description. In this case, it's nice to be able to declare myArgv as const char ** myArgv. boost::program_options:: doesn't really modify argv, does it?
and in practice I recall there were some problems making both consts and non-const to work.
I can see how it wold be difficult to handle deriving the non-const
type from the template arguments. If it's a trade between being const-
correct and supporting localization, clearly supporting localization
is the way to go.
Regards,
-Steve
--------
Steve Byan
Merrill Cornish escreveu:
Steve,
I ran into the same problem. Once I thought about it, I realized I had _never_ seen a C or C++ main() function prototype defined with a const second argument.
I think I remember that one of the traditional C getopt() function variants actually munges the argument list by removing that arguments it recognizes, leaving anything else for direct processing by the program.
This is still possible if the type of the second argument is char const* argv[] as shown by the following code: char const* args[] = { "zero", "one" }; std::swap(args[0], args[1]); std::cout << args[0] << std::endl; std::cout << args[1] << std::endl; It wouldn't hurt if parse_command_line and friends had a const there, if they don't change the strings by design. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
participants (4)
-
Merrill Cornish -
Pedro Lamarão -
Steve Byan -
Vladimir Prus