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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-05-20
Hi,
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?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I moved to UNICODE an old version of TCLAP, making it configurable to be ANSI or UNICODE. To do that I "simply" added a configuration file and I did a lot of find and replace, most of them automatically.
To prevent conflits with the standard use of TCLAP, I renamed the namespace to TTCLAP.
The configuration file contains a set of define: #if defined( TCLAP_WCHAR_T) #define _TT(x) L##x #define TTCLAP TWCLAP #define TTCHAR wchar_t #define STD_STRING std::wstring #define STD_COUT std::wcout #define STD_CERR std::wcerr #define STD_ISTRSTREAM std::wistrtream #define STD_OSTRSTREAM std::wostrtream #define STD_ISTRINGSTREAM std::wistringstream #define STD_OSTRINGSTREAM std::wostringstream #else #define _TT( L #define TTCLAP TCLAP #define TTCHAR char #define STD_STRING std::string #define STD_COUT std::cout #define STD_CERR std::cerr #define STDISTRSTREAM std::istrtream #define STD_OSTRSTREAM std::ostrtream #define STD_ISTRINGSTREAM std::istringstream #define STD_OSTRINGSTREAM std::ostringstream #endif
The hardest work has been the replace of strings and chars enclosed in quote, like "val" or '-' and double quote with _TT('-') and _TT("val").
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
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)?
Thank you.
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.
Hi,
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?
Thank you.
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!
Created https://sourceforge.net/p/tclap/feature-requests/14/ to track this
Hello,
I moved to UNICODE an old version of TCLAP, making it configurable to be ANSI or UNICODE. To do that I "simply" added a configuration file and I did a lot of find and replace, most of them automatically.
To prevent conflits with the standard use of TCLAP, I renamed the namespace to TTCLAP.
The configuration file contains a set of define:
#if defined( TCLAP_WCHAR_T)
#define _TT(x) L##x
#define TTCLAP TWCLAP
#define TTCHAR wchar_t
#define STD_STRING std::wstring
#define STD_COUT std::wcout
#define STD_CERR std::wcerr
#define STD_ISTRSTREAM std::wistrtream
#define STD_OSTRSTREAM std::wostrtream
#define STD_ISTRINGSTREAM std::wistringstream
#define STD_OSTRINGSTREAM std::wostringstream
#else
#define _TT( L
#define TTCLAP TCLAP
#define TTCHAR char
#define STD_STRING std::string
#define STD_COUT std::cout
#define STD_CERR std::cerr
#define STDISTRSTREAM std::istrtream
#define STD_OSTRSTREAM std::ostrtream
#define STD_ISTRINGSTREAM std::istringstream
#define STD_OSTRINGSTREAM std::ostringstream
#endif
The hardest work has been the replace of strings and chars enclosed in quote, like "val" or '-' and double quote with _TT('-') and _TT("val").