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-24 11:28:20

On Mon, Aug 15, 2011 at 19:49, Christopher Jefferson
<chris_at_[hidden]>wrote:

>  [...]
> Is worrying about high efficiency, and lack of copying, in program_options
> really that important? I would prefer the simplest possible interface, even
> if it has some small inefficiencies.
>

This is not about program_options, it's about passing strings in general.
It's just this issue came up in this thread, so I proposed it here.

On Mon, Aug 15, 2011 at 22:33, Gabriel Redner <gredner_at_[hidden]> wrote:

> Hi Yakov,
>
> > It's not just for saving typing, it's for making the interface more
> generic.
> > Consider the following:
> > <snip>
> > Ok, so the above is longer than the first because we didn't define a nice
> > interface of str_ref yet, but it demonstrated the generality.
>
> This is all true, but it's important to keep in mind our use cases.
> In general, these APIs will be called with string literals.  The
> next-most-common case is for them to be called with std::strings, and
> other cases are even less likely.  So it seems best to do the simplest
> thing possible which covers the common cases and does not rule out the
> uncommon ones.
>

There are dozens of other string classes people use. If anyone could map his
contiguous storage string with compatible encoding to str_ref, it could
simplify things greatly.

>
> > Note that the most general way is to use templates accepting any Range of
> > chars, just as boost string algorithms do. But this is not good for
> separate
> > compilation, so the above is the best compromise of efficiency, separate
> > compilation and generality we can get.
>
> Your compromise is missing one factor - simplicity.  This is a simple
> API which does a simple job.  Decorating it with generic tools will
> make it harder to understand and to maintain, in exchange for some
> small benefit in uncommon use cases.
>

Once str_ref is implemented, it makes everything else simpler. So I think
that in the end things are getting simpler. Also

 In any case, it's Vladimir's library, so he has the last word on this.
>

This is not just about this library. It's relevant to interprocess too, for
example.

On Mon, Aug 15, 2011 at 23:25, Olaf van der Spek <ml_at_[hidden]> wrote:

> [...]
> This isn't the only lib that takes string references. It'd be nice to
> solve this properly once and for all.
>

Exactly!

Yet I must admit that I have a very little experience with my own proposal.
I used it successfully in compiler application where passing references to
the original strings allowed one cheaply (and lazily) compute the source of
an error.

-- 
Yakov