We started to adopt your library, thank you for your contribution.
However, we would like to start utilizing unicode, and as such would need support for std::wstring strings in addition to std::string.
Are there any plans to support std::wstring, or can we contribute this functionality (assuming it's feasible which I assume it is)?
Hi, thank you for your interest in TCLAP. There are no concrete plans to adapt TCLAP to support Unicode at this point, although it would be a logical next step and should be relatively straight forward. If you are willing to contribute to this I'm willing to help with that.
Yes, we'd definitely like to contribute and add wstring support. One of our engineers already took a look at it and experimented with it, but it looks like there could be a few ways we could go about it, and I don't think we're 100% sure at this point which route we should take.
It would definitely be great if you could help. How should we proceed?
I'll preface this by saying that I have precisely zero experience with unicode in C++, so this is more-or-less a guess.
First, define a WStringLike arg trait in ArgTraits.h. Then implement a SetWString method (analogous to SetString) in StandardTraits.h that instead of just copying a string converts a std::string to std::wstring. Then add an ExtractValue to Arg.h for the appropriate WStringLike ValueCategory which calls SetWString.
Finally, add an example or two to examples and then some test cases to tests!
How does that sound? Did I miss anything important?
I think it is a bit more complicated than that. We need to be able to handle unicode strings throughout TCLAP, it is not a simple matter of adding a new type. However, on the good side we don't have to deal so much with the encoding etc since we are not actually interpreting the strings. I think the right way to start is to start with a failing test case and than work from that to see what we can minimally do to make it pass, then add more tests and make them pass. This will also give us the opportunity to learn to know each other, our coding styles etc. So if you would like to introduce your developers here and submit patches to the patch tracker, that would be a good start. Again, start simple: a single failing test, and perhaps a proposal for how to make it pass. If all goes well initially we can start thinking about setting up branches, adding developers to the project etc.
mes5k, one more interesting thing for us to think about is if we want to support non-unicode systems at all. After all it is the 21th century now.
So the goal isn't just to support a wstring type, but to support unicode output throughout TCLAP? If we were to shift away from non-unicode systems then I think that might require version 2.0. I'm open to the idea, I just have limited time!
That all aside, I completely agree that a failing test case is the place to start!
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.