Rationale for 21.3.4p1

[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.

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.

[Dave Rahardja]

In article
<5a************ *************** *******@e23g200 0prf.googlegrou ps.com>,
Old Wolf <ol*****@inspir e.net.nzwrote:

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

[peter koch]

On 11 Dec., 07:29, Dave Rahardja <moc.xo...@ajdr ahard.comwrote:

In article
<5a74d5ac-f5c0-47c4-b255-7e70fa7ab...@e2 3g2000prf.googl egroups.com>,
Old Wolf <oldw...@inspir e.net.nzwrote:

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

[Old Wolf]

On Dec 11, 6:31 pm, "Alf P. Steinbach" <[e-mail] 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.

[Kai-Uwe Bux]

Alf P. Steinbach wrote:

* Old Wolf:

>On Dec 11, 6:31 pm, "Alf P. Steinbach" <[e-mail] wrote:

>>>Why is this? It seems to me that it places undue
constraint on the implementation. I have looked at
implementati ons 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

[James Kanze]

On Dec 11, 10:06 am, Kai-Uwe Bux <jkherci...@gmx .netwrote:

Alf P. Steinbach wrote:

* Old Wolf:

On Dec 11, 6:31 pm, "Alf P. Steinbach" <[e-mail] wrote:
Why is this? It seems to me that it places undue
constraint on the implementation. I have looked at
implementatio ns 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< ... >::operator[]( size_t i ) const
{
static CharT const nul( 0 ) ;
return i < size() ? myRep[ i ] : nul ;
}

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Daniel T.]

James Kanze <ja*********@gm ail.comwrote:

On Dec 11, 10:06 am, Kai-Uwe Bux <jkherci...@gmx .netwrote:

Alf P. Steinbach wrote:

* Old Wolf:
>On Dec 11, 6:31 pm, "Alf P. Steinbach" <[e-mail] wrote:

>>>Why is this? It seems to me that it places undue
>>>constraint on the implementation. I have looked at
>>>implementati ons 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< ... >::operator[]( 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_i terator it = s.begin();
string::value_t ype c = it[s.size()]; // well defined?
}

[Pete Becker]

On 2007-12-11 00:31:17 -0500, "Alf P. Steinbach" <al***@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)

[James Kanze]

On Dec 11, 1:16 pm, "Daniel T." <danie...@earth link.netwrote:

James Kanze <james.ka...@gm ail.comwrote:

On Dec 11, 10:06 am, Kai-Uwe Bux <jkherci...@gmx .netwrote:

Alf P. Steinbach wrote:
* Old Wolf:
On Dec 11, 6:31 pm, "Alf P. Steinbach" <[e-mail] wrote:
>>Why is this? It seems to me that it places undue
>>constraint on the implementation. I have looked at
>>implementatio ns 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< ... >::operator[]( 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_i terator it = s.begin();
string::value_t ype 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:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]