Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2012-11-24 09:41:55

On Sat, Nov 24, 2012 at 3:17 PM, Olaf van der Spek <ml_at_[hidden]> wrote:

> On Sat, Nov 24, 2012 at 8:42 AM, Yakov Galka <ybungalobill_at_[hidden]>
> wrote:
> >> fundamental? hardly.  std::string is not guaranteed to
> >> be null terminated.
> >
> >
> > Guaranteed (almost) since C++11. c_str() and data() now *mean the same
> > thing*,
>
> Really? Got a reference for that?
>

See C++11 [string.accessors]/1-3.

> > and s[s.size()] returned null even in C++03.
>
> Is that defined behaviour?
> You're essentially dereferencing end().
>

Yes, it is and was well defined, and no, this is just not the way it is
phrased.

See C++98 and C++03 in [lib.string.access]/1 where this is the case for the
const version only, and C++11 [string.access]/1-2 which corrects the
wording for the non-const version too.

 > The only thing that is
> > not guaranteed is that *(&s[0] + s.size()) is null. Anyway the point is
> > that you can retrieve a null terminated string from std::string in
> constant
> > time, without copying anything. So it is practically null terminated.
>
> True, but that's std::string. Not all strings are std::string.
>
> " A string_ref that's not required to be null-terminated is far more
> useful." still holds

True, but then it is unclear how it is string specific compared to
iterator_range. Or said otherwise, it solves a different problem.

-- 
Yakov