It was brought to my attention today that the Standard
(1998 version, anyway) says that if s is a const
std::string, then:
s[s.size()]

is well-defined and evaluates to 0.

Why is this? It seems to me that it places undue
constraint on the implementation. I have looked at
implementations in the past that just maintain a
counted string, and only append the \0 to the
buffer when c_str() is called. Such an implementation
would have to include overhead in its operator[] function
that would not be necessary without this clause.

* Old Wolf:
> It was brought to my attention today that the Standard
> (1998 version, anyway) says that if s is a const
> std::string, then:
> s[s.size()]
>
> is well-defined and evaluates to 0.

Does it?

Wouldn't /really/ surprise me but I'm unfamiliar with that requirement.

Offhand, I'd think it was Undefined Behavior.



> Why is this? It seems to me that it places undue
> constraint on the implementation. I have looked at
> implementations in the past that just maintain a
> counted string, and only append the \0 to the
> buffer when c_str() is called. Such an implementation
> would have to include overhead in its operator[] function
> that would not be necessary without this clause.

In practice all implementations use one contiguous buffer which is also
the result of c_str().

Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

In article
<5a74d5ac-f5c0-47c4-b255-7e70fa7ab651@e23g2000prf.googlegroups.com>,
Old Wolf <oldwolf@inspire.net.nz> wrote:

> It was brought to my attention today that the Standard
> (1998 version, anyway) says that if s is a const
> std::string, then:
> s[s.size()]
>
> is well-defined and evaluates to 0.
>
> Why is this? It seems to me that it places undue
> constraint on the implementation. I have looked at
> implementations in the past that just maintain a
> counted string, and only append the \0 to the
> buffer when c_str() is called. Such an implementation
> would have to include overhead in its operator[] function
> that would not be necessary without this clause.

I hazard it's because that behavior makes std::string behave more or
less like a C string, and lets you iterate through the string, exiting
when operator[] returns 0.

-dr

On 11 Dec., 07:29, Dave Rahardja <moc.xo...@ajdrahard.com> wrote:
> In article
> <5a74d5ac-f5c0-47c4-b255-7e70fa7ab...@e23g2000prf.googlegroups.com>,
> Old Wolf <oldw...@inspire.net.nz> wrote:
>
> > It was brought to my attention today that the Standard
> > (1998 version, anyway) says that if s is a const
> > std::string, then:
> > s[s.size()]
>
> > is well-defined and evaluates to 0.
>
> > Why is this? It seems to me that it places undue
> > constraint on the implementation. I have looked at
> > implementations in the past that just maintain a
> > counted string, and only append the \0 to the
> > buffer when c_str() is called. Such an implementation
> > would have to include overhead in its operator[] function
> > that would not be necessary without this clause.
>
> I hazard it's because that behavior makes std::string behave more or
> less like a C string, and lets you iterate through the string, exiting
> when operator[] returns 0.
>
That can't be the reason as this requirement is for const std::string
only.
I reckon it has to do with some legacy support from before
standardization, but it is only a guess.
A good question from the old wolf!

/Peter

On Dec 11, 6:31 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> > Why is this? It seems to me that it places undue
> > constraint on the implementation. I have looked at
> > implementations in the past that just maintain a
> > counted string, and only append the \0 to the
> > buffer when c_str() is called. Such an implementation
> > would have to include overhead in its operator[] function
> > that would not be necessary without this clause.
>
> In practice all implementations use one contiguous buffer which is also
> the result of c_str().

Yes; but implementations need not actually put the 0 at
the end of the buffer until it's required, they could
behave just like every other library's counted string
in the meantime.

* Old Wolf:
> On Dec 11, 6:31 pm, "Alf P. Steinbach" <al...@start.no> wrote:
>>> Why is this? It seems to me that it places undue
>>> constraint on the implementation. I have looked at
>>> implementations in the past that just maintain a
>>> counted string, and only append the \0 to the
>>> buffer when c_str() is called. Such an implementation
>>> would have to include overhead in its operator[] function
>>> that would not be necessary without this clause.
>> In practice all implementations use one contiguous buffer which is also
>> the result of c_str().
>
> Yes; but implementations need not actually put the 0 at
> the end of the buffer until it's required, they could
> behave just like every other library's counted string
> in the meantime.

For a const string?

Well, it's not a convincing argument, just an idea as to rationale.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:

> * Old Wolf:
>> On Dec 11, 6:31 pm, "Alf P. Steinbach" <al...@start.no> wrote:
>>>> Why is this? It seems to me that it places undue
>>>> constraint on the implementation. I have looked at
>>>> implementations in the past that just maintain a
>>>> counted string, and only append the \0 to the
>>>> buffer when c_str() is called. Such an implementation
>>>> would have to include overhead in its operator[] function
>>>> that would not be necessary without this clause.
>>> In practice all implementations use one contiguous buffer which is also
>>> the result of c_str().
>>
>> Yes; but implementations need not actually put the 0 at
>> the end of the buffer until it's required, they could
>> behave just like every other library's counted string
>> in the meantime.
>
> For a const string?
>
> Well, it's not a convincing argument, just an idea as to rationale.

Keep in mind that non-const strings also have a const-member operator[] that
gets called when the string is referred to as const, e.g., passed to a
function that takes a const string & parameter. The standard requires that
operator[]( size() ) returns 0 in those cases.


Best

Kai-Uwe Bux

On Dec 11, 10:06 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> Alf P. Steinbach wrote:
> > * Old Wolf:
> >> On Dec 11, 6:31 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> >>>> Why is this? It seems to me that it places undue
> >>>> constraint on the implementation. I have looked at
> >>>> implementations in the past that just maintain a
> >>>> counted string, and only append the \0 to the
> >>>> buffer when c_str() is called. Such an implementation
> >>>> would have to include overhead in its operator[] function
> >>>> that would not be necessary without this clause.
> >>> In practice all implementations use one contiguous buffer which is also
> >>> the result of c_str().

> >> Yes; but implementations need not actually put the 0 at
> >> the end of the buffer until it's required, they could
> >> behave just like every other library's counted string
> >> in the meantime.

> > For a const string?

> > Well, it's not a convincing argument, just an idea as to rationale.

> Keep in mind that non-const strings also have a const-member
> operator[] that gets called when the string is referred to as
> const, e.g., passed to a function that takes a const string &
> parameter. The standard requires that operator[]( size() )
> returns 0 in those cases.

I'm not sure how this interacts with the upcoming requirement
that the data in a string be contiguous, but at least at
present, the implementation of the const operator[] could be
something like:

CharT const&
basic_string< ... >:perator[]( size_t i ) const
{
static CharT const nul( 0 ) ;
return i < size() ? myRep[ i ] : nul ;
}

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze <james.kanze@gmail.com> wrote:
> On Dec 11, 10:06 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> > Alf P. Steinbach wrote:
> > > * Old Wolf:
> > >> On Dec 11, 6:31 pm, "Alf P. Steinbach" <al...@start.no> wrote:

> > >>>> Why is this? It seems to me that it places undue
> > >>>> constraint on the implementation. I have looked at
> > >>>> implementations in the past that just maintain a
> > >>>> counted string, and only append the \0 to the
> > >>>> buffer when c_str() is called. Such an implementation
> > >>>> would have to include overhead in its operator[] function
> > >>>> that would not be necessary without this clause.
> > >>> In practice all implementations use one contiguous buffer which is also
> > >>> the result of c_str().
>
> > >> Yes; but implementations need not actually put the 0 at
> > >> the end of the buffer until it's required, they could
> > >> behave just like every other library's counted string
> > >> in the meantime.
>
> > > For a const string?
>
> > > Well, it's not a convincing argument, just an idea as to rationale.
>
> > Keep in mind that non-const strings also have a const-member
> > operator[] that gets called when the string is referred to as
> > const, e.g., passed to a function that takes a const string &
> > parameter. The standard requires that operator[]( size() )
> > returns 0 in those cases.
>
> I'm not sure how this interacts with the upcoming requirement
> that the data in a string be contiguous, but at least at
> present, the implementation of the const operator[] could be
> something like:
>
> CharT const&
> basic_string< ... >:perator[]( size_t i ) const
> {
> static CharT const nul( 0 ) ;
> return i < size() ? myRep[ i ] : nul ;
> }

Is string's iterator required to behave the same way?

void foo( const string& s ) {
string::const_iterator it = s.begin();
string::value_type c = it[s.size()]; // well defined?
}

On 2007-12-11 00:31:17 -0500, "Alf P. Steinbach" <alfps@start.no> said:

> * Old Wolf:
>> It was brought to my attention today that the Standard
>> (1998 version, anyway) says that if s is a const
>> std::string, then:
>> s[s.size()]
>>
>> is well-defined and evaluates to 0.
>
> Does it?
>
> Wouldn't /really/ surprise me but I'm unfamiliar with that requirement.
>
>

It's not hard to find. [string.access]/1.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

On Dec 11, 1:16 pm, "Daniel T." <danie...@earthlink.net> wrote:
> James Kanze <james.ka...@gmail.com> wrote:
> > On Dec 11, 10:06 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> > > Alf P. Steinbach wrote:
> > > > * Old Wolf:
> > > >> On Dec 11, 6:31 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> > > >>>> Why is this? It seems to me that it places undue
> > > >>>> constraint on the implementation. I have looked at
> > > >>>> implementations in the past that just maintain a
> > > >>>> counted string, and only append the \0 to the
> > > >>>> buffer when c_str() is called. Such an implementation
> > > >>>> would have to include overhead in its operator[] function
> > > >>>> that would not be necessary without this clause.
> > > >>> In practice all implementations use one contiguous
> > > >>> buffer which is also the result of c_str().

> > > >> Yes; but implementations need not actually put the 0 at
> > > >> the end of the buffer until it's required, they could
> > > >> behave just like every other library's counted string
> > > >> in the meantime.

> > > > For a const string?

> > > > Well, it's not a convincing argument, just an idea as to
> > > > rationale.

> > > Keep in mind that non-const strings also have a const-member
> > > operator[] that gets called when the string is referred to as
> > > const, e.g., passed to a function that takes a const string &
> > > parameter. The standard requires that operator[]( size() )
> > > returns 0 in those cases.

> > I'm not sure how this interacts with the upcoming requirement
> > that the data in a string be contiguous, but at least at
> > present, the implementation of the const operator[] could be
> > something like:

> > CharT const&
> > basic_string< ... >:perator[]( size_t i ) const
> > {
> > static CharT const nul( 0 ) ;
> > return i < size() ? myRep[ i ] : nul ;
> > }

> Is string's iterator required to behave the same way?

> void foo( const string& s ) {
> string::const_iterator it = s.begin();
> string::value_type c = it[s.size()]; // well defined?
> }

Good question. I don't think so. I can't find any text
requiring it, nor anything requiring s.begin()[i] to have the
same behavior as s[i] (although logically...).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34