Re: [boost] [program_options] Some methods take const char*, others take std::string

Subject: Re: [boost] [program_options] Some methods take const char*, others take std::string
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2011-08-11 04:45:16

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_at_[hidden]>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
> [phone]
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Yakov