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:27:24

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

> On Thu, Aug 11, 2011 at 10:45 AM, Yakov Galka <ybungalobill_at_[hidden]>
> wrote:
> > 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.
>
> Doesn't iterator_range treat literals as arrays by default?
> The str_ref idea is great, but IMO iterator_range isn't suitable for it.
> Also, doesn't iterator_range require memory allocations itself?
>

1) It's a proof of concept, not an implementation. iterator_range is just
one of the infinity of types which can be mapped to the Range concept and
used wherever Ranges expected.

2) Yes, it treats string literals as arrays, so what? It's exactly what we
want.
If you're talking about including or not the null terminator, then I'm still
not sure on this point. We can say that our strings don't contain zeros in
the middle (which is acceptable for function expecting const char*), then if
end() points to a null terminator we can use it as an optimization when
passing to a low-level function accepting a zero-terminated string. If end()
doesn't point to zero, then we must do a copy when passing to something like
fread(). The alternative is to never include the null terminator when
initializing from a string. This solution is also good, since only a small
fraction of our functions pass the strings to the system (where a null
terminated string is needed), and even then sometimes we *must* do a copy,
especially if we want to support Unicode on windows (consider all
boost::interprocess which cannot be used now for opening Unicode paths on
windows).

3) No, iterator_range just stores a pair of iterators, no memory allocations
are done. Also see 1), it's irrelevant to the discussion.

-- 
Yakov