Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-05-12 14:20:30

Rob Stewart wrote:
>From: John Nagle <nagle_at_[hidden]>
> >
> > STL strings are variable-sized, with no limit. When you
> > add characters, "size()" increases. Should fixed-size
> ^^^^
>I presume you're referring to fixed-capacity strings which can
>have a variable size, right?

yup. The idea is to make it a buffer-overflow safe replacement for C style
character buffers, e.g.:

   char buf[ 100 ];
   ::sprintf( buf, "...", ... );

while allowing it to behave like a basic_string.

> > strings be similar? If the STL string operations are
> > to be meaningful, they have to be.
>Only if you want to apply mutating algorithms that modify size.
>IOW, it isn't unreasonable to choose either fixed-size or
>fixed-capacity strings. If the former, then there are no
>mutating algorithms that affect the size. If the latter, the
>size can change, but an exception occurs when trying to exceed
>the capacity.

That's the way I see it, but instead of throwing an exception, the class
simply prevents overrun and fills the available space, e.g.:

   char_string< 5 > buf;
   buf.copy( "Meine Grosse Welt!" );
   std::cout << buf << '\n'; // prints "Mein" (null terminated)

> > In STL strings, "size" doesn't include a trailing null.
> > Using "c_str" can result in expanding the string to add a
> > trailing null. With fixed-size strings, we don't have that
> > option.
> >
> > If c_str is provided, there must always be space
> > for a trailing null. So you can't use char_string
> > when you need a specific fixed length, as for Macintosh
> > 4-character file signatures. Perhaps "boost::array<char>"
> > is the way to go for that sort of thing. Trying to do
> > both null-terminated and non-null-terminated strings
> > in the same class will get ugly.
>If the string if fixed-capacity *and* there remains sufficient
>capacity, c_str() can null terminate the buffer. If there isn't
>sufficient remaining capacity, then throw an exception.
>IOW, make it a runtime error to fix the capacity too small to
>permit null termination when calling c_str(). That still leaves
>room for things like the 4-character file signature to which you
>referred, and yet prevents buffer overrun, but doesn't require
>foregoing flexibility.

That is a good idea. It will mean keeping track of the string length, but it
does permit both versions without requiring complex internals/semasntics or
seperate classes.

In order to keep interoperability with C style usage (i.e. operator const
char *()), we can have the following:

   inline const char_type * c_str()
      // null-terninate buffer: str[ len ] = char_type( '\0' );
      return( str )
   inilne operator const char *()
      return( c_str());


Tired of 56k? Get a FREE BT Broadband connection

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