Boost logo

Boost :

From: Tom Bachmann (e_mc_h2_at_[hidden])
Date: 2007-03-20 08:05:30

Hash: SHA1

>> > The easiest fix would be to add a public interface to change the value
>> > of an option in a variables map, by making op[] return a non-const
>> > reference. I'm not sure if code should be added to call semantic ->
>> > notify automically.
> Yep, I guess we need non-const-returning[] for sure. We probably should
> have variable_value overload operator=, and call semantic->notify.

Yes, this sounds cleanest.

> Do
> you think disallowing assignements that change value type is OK? Say,
> if you try to assign int to value of type double, you get exception.

This sounds sensible to me.

>> > 2 find out the type of an option
>> >
>> > This is not strictly necessary, but I'd be nice to e.g show a checkbox
>> > for bool options, a spin button for numeric options, and an entry field
>> > for other options. I currently infer the type by querying the Boost.Any
>> > that holds the option, potentially after applying the default value.
>> > This is not foolproof, however, because it fails for options that have
>> > no default value and that have not been set before.
> Technically speaking, the value_semantic base class does not require an
> option to have any type at all. At the same time, in 100% of known cases
> the type for an option is known. Perhaps I can either add 'type' method
> to value_semantics that returns type_info* and may return NULL, or just
> make it return type_info& and demand that all options have a fixed type.
> Will either of those approaches work for you?

Either will work.

>> > 3 convert from an option value to some screen representation
> [...]
> One another approach is make variable_value record original tokens it
> was constructed from. This correlates with your point (1) above --
> perhaphs after UI was changed, value_semantics->parse should be called
> to get new boost::any and the parsed tokens should be stored in variable_value.

Again, this sounds cleaner than my proposal.

>> > 4 find out what options in a po::options_description are members of what
>> > option groups
>> >
>> > This is necessary to group the options in multiple tabs. Again, there
>> > are only private interfaces to access the information.
> The problem here is that when you add one options_description to
> another options description, the original object is not retained, so
> it's not simple to have "parent pointer". It might be possible to
> have "parent group name" field in an option. Would that be too cumbersome
> to construct UI hierarchy grouping options by string parent name?

Putting the parent string into every option sounds unnecessarily
complicated too me (from a user perspective). What about making
options_description manage map of views in the main options vector, that
is, something like map<parent_string,vector<option*> >. With an adequate
public interface, my problem would be solvable in a strightforward way.

With the interface changes described, a clean options window
implementation seems to be possible.
- --
- -ness-
Version: GnuPG v1.4.6 (GNU/Linux)


Boost list run by bdawes at, gregod at, cpdaniel at, john at