I'm very hopeful that program_options will simplify the mess that is the options parsing in our application, especially as it should allow us to handle command-line, config-fle, and environment-variable options in one logical step. This is all good. My initial tests have run into a small hitch, and I'm wondering whether there is a way to do what I have been trying to do: We have a core engine which has the largest options requirements. For testing, mainly, we wrap that core engine and provide a user utility. I'd like the core engine to be able to handle a broad set of options from all three directions (config, command line, environment). Easy. I'd also like the wrapping utility to have its own (smaller) set of options that control what it does. Ideally this should be as logically seperate from the engine as possible. At present we do this by simply not using command-line options for the core engine, and only using command-line options for the wrapping utility, but that is the fucntionality I most want to add at the moment - the use of multiple methods of setting (most) options at both levels (wrapper and core engine). What I would most like to be able to do is process the command line (for example) twice - once in the outer wrapping context, looking for the options that are relvant there, and once in the core engine, looking for the options there. When I try a test app with this structure, though, I get exceptions thrown when any options are encountered that are not included in both the options_descriptions used, which sort of defeats what I'm trying to do - I want to have two distinct sets of options: one for the wrapper, and one for the core, with (little or) no overlap. I would be happy if I could disable the exception behaviour, allowing the processing to complete and report to me that it encountered some unknown options along the way. This would mean that I would risk ignoring some unknown options in both passes, but I could live with that, I think. I can see a possible alternative, which requires me to pass the wrapper's options_description to the core engine, get it all parsed there, and pass back the map for examination by the wrapper. This would make some additional work for me, but would probably work fine. I guess I'd just like to know whether the other way of approaching things is going to be supported, or whether there is yet another approach I should consider? Take care, Liam -- Liam Routt Ph: (03) 8344-1315 Research Programmer caligari@cs.mu.oz.au Computer Science, Melbourne University (or liam@routt.net)