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 null.
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 characters!
[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?
Regards, Reece _________________________________________________________________ Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win $1 million! http://local.msn.com/special/giveaway.asp