The use of the ValueExtractor class to specialize the handling of string arguments is ugly an inflexible (I know I wrote it :)). It was required as a quick fix at the time during heavy refactoring of the library and has worked well in practice. However, I ran in to a problem today when I wanted to implement a string-like type that should be used as a ValueArg type. This did not work because operator>> splits strings on spaces, i.e. the same reason we needed the specialization in the first place. A better solution would be to use the traits design pattern and create a traits class for each possible value type and then pass a traits object to the value extraction function for specialization purposes. In this way the type of the parameter will not determine the specialization, but a trait of the type will.
For this case only a single trait is required, AssignType, maybe we should consider if there are other useful meta-info we are interested in putting in the traits object as well. The categories I can come up with for AssignType is, StringLike (i.e. use assignment), ValueLike (i.e. use operator>>) and possibly Settable (i.e. use _value.Set()), but this is not really required because overloaded operator= can be used for this.
Log in to post a comment.