The following example could not be compiled: ================================================================= #include <string> #include <boost/program_options.hpp> namespace po = boost::program_options; int main() { std::wstring test; po::options_description desc("Allowed options"); desc.add_options() ("test", po::wvalue<std::wstring>(&test)->default_value(L"value"), "description"); } ================================================================= It is due to wvalue::default_value tries to do lexical_cast<std::string>(std::wstring). Also I cannot change default_value to default_value("value") as soon as it accepts only something convertible to std::wstring. In other words it is impossible to specify default_value for wstring option.
Sergei Politov wrote:
The following example could not be compiled: ================================================================= #include <string> #include <boost/program_options.hpp>
namespace po = boost::program_options;
int main() { std::wstring test; po::options_description desc("Allowed options"); desc.add_options() ("test", po::wvalue<std::wstring>(&test)->default_value(L"value"), "description"); } ================================================================= It is due to wvalue::default_value tries to do lexical_cast<std::string>(std::wstring). Also I cannot change default_value to default_value("value") as soon as it accepts only something convertible to std::wstring. In other words it is impossible to specify default_value for wstring option.
Can you please enter a bug report on svn.boost.org? Thanks, Volodya
Done #1645. I've failed with code formatting in issue description, sorry. Is it planned to support unicode value names, descriptions etc? (I could assist with it if needed)
Sergei Politov wrote:
Done #1645. I've failed with code formatting in issue description, sorry.
Is it planned to support unicode value names, descriptions etc? (I could assist with it if needed)
There are no immediate plans to do that. Patches to improve the situation are surely welcome, but as with unicode support for option values, I'd much prefer a solution that does not require to template any non-trivial code on the used char type. Thanks, Volodya
Hi,
The following example could not be compiled: ================================================================= #include <string> #include <boost/program_options.hpp>
namespace po = boost::program_options;
int main() { std::wstring test; po::options_description desc("Allowed options"); desc.add_options() ("test", po::wvalue<std::wstring>(&test)->default_value(L"value"), "description"); } ================================================================= It is due to wvalue::default_value tries to do lexical_cast<std::string>(std::wstring). Also I cannot change default_value to default_value("value") as soon as it accepts only something convertible to std::wstring. In other words it is impossible to specify default_value for wstring option. I've solved this by providing alternative value description in a char-based encoding. In my case, I use UTF-8 for all descriptions, and filter all output of boost::program_options through UTF8->wchar_t conversion.
So in your case desc.add_options() ("test", po::wvalue<std::wstring>(&test)->default_value(L"value", "value"), "description"); will probably compile fine. However, I agree that this is a bug - wvalue should probably use wstringstream and not stringstream for conversions. I also think that other classes like options_descriptions should accept wide strings, because otherwise we need to use the UTF8 trick to enable localization of these. Moreover, some english strings seem to be hard-coded in program_options (exception messages, etc.) There should be another way of handling cmdline errors - we can't presume that the user understands english text. And there does not seem to be a way of translating the po exceptions to localized strings without accessing/changing some po internals. Hope this helps, Filip
Filip Konvička wrote:
Moreover, some english strings seem to be hard-coded in program_options (exception messages, etc.) There should be another way of handling cmdline errors - we can't presume that the user understands english text. And there does not seem to be a way of translating the po exceptions to localized strings without accessing/changing some po internals.
I suspect all boost libraries share this problem, and nobody came with a nice solution for solving this. I can surely provide a hook, specific for program_options, that is called to translate messages. - Volodya
Moreover, some english strings seem to be hard-coded in program_options (exception messages, etc.) There should be another way of handling cmdline errors - we can't presume that the user understands english text. And there does not seem to be a way of translating the po exceptions to localized strings without accessing/changing some po internals.
I suspect all boost libraries share this problem, and nobody came with a nice solution for solving this.
I can surely provide a hook, specific for program_options, that is called to translate messages.
Sure, but program_options is in fact implementation of some UI so the need for user interaction is higher than with some other libraries. I think that providing some additional data members in the exception classes would be sufficient. That way, you don't need to provide any hooks at all. The current pattern for using exceptions is something like throw my_exception("some text "+param+": some other text "+param2); (sometimes the string construction is in my_exception's constructor). I'd rather see throw my_exception(param, param2); and somewhere in my_exception: class my_exception { .... public: string param; string param2; string what() const { return "some text "+param+": some other text "+param2; } } Cheers, Filip
Filip Konvička wrote:
Moreover, some english strings seem to be hard-coded in program_options (exception messages, etc.) There should be another way of handling cmdline errors - we can't presume that the user understands english text. And there does not seem to be a way of translating the po exceptions to localized strings without accessing/changing some po internals.
I suspect all boost libraries share this problem, and nobody came with a nice solution for solving this.
I can surely provide a hook, specific for program_options, that is called to translate messages.
Sure, but program_options is in fact implementation of some UI so the need for user interaction is higher than with some other libraries.
I think that providing some additional data members in the exception classes would be sufficient. That way, you don't need to provide any hooks at all.
The current pattern for using exceptions is something like
throw my_exception("some text "+param+": some other text "+param2);
(sometimes the string construction is in my_exception's constructor).
I'd rather see
throw my_exception(param, param2);
and somewhere in my_exception:
class my_exception { .... public: string param; string param2;
string what() const { return "some text "+param+": some other text "+param2; } }
Then, if you want to provide a localized message, you should actually write code to construct a message. If there's a localization hook, you'll basically have to run a tool to extract the string to be localized (program_options.po can be shipped for those who use gettext), translate it, and install it. Of course, it might not work on Windows -- but I'm not exactly sure how localization works on windows, in practice. Numeric message ids look like nightmare to maintain. - Volodya
Cheers, Filip
Vladimir Prus 19.2.2008 17:32:
Filip Konvička wrote:
Moreover, some english strings seem to be hard-coded in program_options (exception messages, etc.) There should be another way of handling cmdline errors - we can't presume that the user understands english text. And there does not seem to be a way of translating the po exceptions to localized strings without accessing/changing some po internals.
I suspect all boost libraries share this problem, and nobody came with a nice solution for solving this.
I can surely provide a hook, specific for program_options, that is called to translate messages.
Sure, but program_options is in fact implementation of some UI so the need for user interaction is higher than with some other libraries.
I think that providing some additional data members in the exception classes would be sufficient. That way, you don't need to provide any hooks at all.
The current pattern for using exceptions is something like
throw my_exception("some text "+param+": some other text "+param2);
(sometimes the string construction is in my_exception's constructor).
I'd rather see
throw my_exception(param, param2);
and somewhere in my_exception:
class my_exception { .... public: string param; string param2;
string what() const { return "some text "+param+": some other text "+param2; } }
Then, if you want to provide a localized message, you should actually write code to construct a message.
Yes. According to my example, I could do (but I don't have to if I don't want, that's the point) try { // work with PO } catch(my_exception& e) { cout << "My localized message for my_exception with p1=" << e.param << " p2=" << e.param2 << endl; } // ... // possibly catch/translate other PO exceptions // ... catch(some_basic_po_exception& fallback) { cout << fallback.what() << endl; // use default string }
If there's a localization hook, you'll basically have to run a tool to extract the string to be localized (program_options.po can be shipped for those who use gettext), translate it, and install it.
Uh, I'd never suggest such thing :-)
Of course, it might not work on Windows -- but I'm not exactly sure how localization works on windows, in practice. Numeric message ids look like nightmare to maintain.
Agreed. Filip
participants (3)
-
Filip Konvička -
Sergei Politov -
Vladimir Prus