Since there have been a few emails bouncing around, I'd like to chime in with my opinions on a few matters.
1. Static vs Shared I would much prefer header files only instead of a shared library. Having to deal with shared libraries are a pain on many systems (such as cygwin). Using a header file is clean and easy -- therefore much preferred by me. One of the biggest benefits to boost is that it is primarily header files only. I don't even use the regex library because I can't get it to build on Tru64. 2. redundant storage I don't have a problem with you storing arguments in both options_and_arguments as well as whatever variable I pass in. I realize that one will be typed and the other string. If it is stored in a third place as well, well that could be annoying, but I won't balk too much...probably not good design though. 3. custom parser I realize that no one will find shrink-wrapped solutions to everything. However, for a command line parser, I would hope that most common command line styles would be shrink-wrapped. For example /o --option -o -o value -o=value --option value --option=value -o val1 val2 val3 --option val1 val2 val3 -o val1 -o val2 -o val3 should all work right out of the box. Other than that, make 'em write a custom parser :) Of course, that is assuming that by "custom parser" you mean write the custom parsing function that can be used by your library. 4. I do like the idea of handler functions that could be called when the parameter was passed in. 5. As for exceptions vs return values. I don't really have a preference. Often, you can get more information from exceptions than you can from return values. If that is the case then I fully support exceptions. If you're not going to get back anything other than "it failed", then return values are probably the way to go. 6. wchar_t support. I definitely see the need for this. I like the idea of a template parameter. However, I wonder, like another poster, if you will ever need both char and wchar_t support, in which case you may not need a template parameter. The only question I have is if you will ever have the command line in char and the config file in wchar_t...then you may need them both. 7. config file. This is where I have the biggest problem. I think a config file library should be in boost, but separate from a command line library. Perhaps the two could interface through a similar facade, but I don't think they need to be intimately combined. As another poster pointed out, the command line option and its associated config file or environmental parameter are often very different in name. 8. I agree that multi-pass command line parsing is important. We eat certain arguments and pass others to separate programs all of the time. Tanton _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
