Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-05-27 07:06:51

John Nagle wrote:
> I think the relationship between "size()" and "capacity()"
>has to be such that if "size() < capacity()" you can add a
>character. So "capacity()" should not include the trailing

Makes sense.

> For consistency with "<string>", "size()" can't include
>the trailing null.

This applies for both basic_string::size() and strlen( s ).

> The big question is whether the size specified in the
>declaration (as in "char_string<80>") includes the
>trailing null.
> I don't want to express an opinion on this until
>I've had some sleep. I can think of good arguments
>for both sides.

I have modified the sandbox implementation to make it easy to switch between
the two models; it is currently using the 2nd model (adding space for the
null). One possibility is putting the choice of models as a template
parameter (e.g. bool need_null -- see comments in the sandbox code for an
implementation), that way the decision is up to the programmer and not the
library implementor.

>Reece Dunn wrote:
>>John Nagle wrote:
>>>Should the trailing null be counted in "capacity?"
>>This is a good point. At the moment fixed_string< n >::capacity() == n. It
>>would therefore make sense that this be changed so that either:
>>[1] fixed_string< n >::capacity() == n - 1 -- this would seem
>>counter-intuitive, as fixed_string< 1 > would not be able to store any
>>[2] change CharT str[ n ] to CharT str[ n + 1 ] -- i.e. add an extra
>>character for the trailing null. This would make more sense, as it is
>>similar to:
>> char * str = new char[ s.length() + 1 ];
>>I personally but a vote for solution 2, but what do other people think?


Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win
$1 million!

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