Boost logo

Boost :

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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at