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]>
> >> 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
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 + s.size()) is null. Anyway the point is
> > that you can retrieve a null terminated string from std::string in
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk