Another option is to define class str_ref : public iterator_range<const char*> { ... }; Convertible from both, string literals and std::strings, and provide only one overload that accepts it everywhere. Just an idea. On Wed, Aug 10, 2011 at 23:13, Vladimir Prus <vladimir@codesourcery.com>wrote:
Gabriel Redner wrote:
Hi all,
Some methods in program_options accept const char*s (e.g. option_description constructor), while others take const std::string&s (e.g. option_description::key). This makes no difference to the user if he is passing string literals, but becomes annoying if he wants to pass strings, or expressions which return strings. Of course he can put (...).c_str() everywhere, but this is ugly and unnecessary, since program_options just takes its parameters and shoves them into string variables anyways. Since changing the parameter types to const std::string& should not break existing code, I do not see a downside to doing so (plus, it would allow me to get rid of .c_str()s everywhere :-).
Does it seem reasonable for program_options public APIs to accept std::strings instead of const char*s? If so I would be happy to do the legwork and submit a patch.
This is: https://svn.boost.org/trac/boost/ticket/4142
The point is that using std::string would impose code size overhead when you pass string literal. I would be happy to see a patch, but such a patch would have to retain overloads taking const char*.
Thanks,
-- Vladimir Prus CodeSourcery / Mentor Graphics +7 (812) 677-68-40
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Yakov