Tanton Gibbs wrote: >> I realize that header file is easy. But that approach will bit sooner or >> later. It probably would be possible to supply alternative header-only >> option, but that would be a lot of work. Need to find more opinions here. >> >> BTW, if you have problems with shared libraries on cygwin, it's still >> possible to add all source files from program_options to your project and >> compile them? > > Yes that is an option, but not one I would like to use. I personally > prefer the optional header-only, but understand either way.
OK. I'll note your opinion. >> The error message indeed carry more information than "it failed". I can > also >> imagine cases where the kind of error matters. > > I think that exceptions are definitely superior to error codes because of > the amount of information they convey. Therefore, > I really like the exception option. Good. >> I have some problems here, too --- the config_file class is too small be >> become a separate library --- and was never intended to. I've no problem >> with using separate config_file, provided it can be converted into >> 'options_and_arguments' class, which is the common interface for command >> line and config file. However, I can't comment as what the separate >> config file library can do. > > Me neither. It could be that your library is accepted into boost on the > condition that when > a real config file library is accepted, you replace yours with it. Basically, given the little amount of time put in config_file, I'll be happy to replace it with anything better. >> > 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. >> >> Could you clarify why the approach with separating option to your program >> and options to another program by "--" is not appropriate? I'd be willing >> to put some though into this, but would like to understand the problem >> first. > > The -- option would be fine for my purposes. Just stupidity on my part. :-) >> Now, 'whale_opts' and 'dolphin_opts' (of type std::map<string, string>) > keep >> two different groups of options. I'm thinking something like that can be >> used. > > This is fine until Dolphin and Whale both use the same option (e.g., -f > filename) in which case they cannot have separate values. Good case. I feel that multi-pass parsing will fail in this case, too. The first parser will extract '-f' and the second one will never see it. - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
