Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-05-25 10:06:47

Martin wrote:
>I have looked at both implementation and got some comments:
>1. Both implementations use a size independent base class. I can see the
>for such a class but don't understand how to use it in the way proposed.

There are some examples in the associated C-string compatibility sections
(boost/fixed_string/safe_strings.hpp for mine; boost_fixed_string_string.hpp
for John's). This allows you to write:

   inline char * strcpy( boost::char_string & d, const char * s )
      return( d.assign( s ));

as opposed to:

   template< size_t n >
   inline char * strcpy( boost::fixed_string< n, char > & d, const char * s
      return( d.assign( s ));

allowing you to migrate code that relies on strcpy, etc easier and not have
to templatize each function (so you can keep them in a static/dynamic
library for example).

>The base class only implements a few methods so in my view it is more or
>useless. E.g. a function taking a "base" argument can't iterate or look at
>string content without converting it to a c-string (so it could just as
>use a c-string argument). Why not implement the full interface in the base

The base class actually has the full basic_string interface (minus the
constructors). It exposes 14 virtual functions that are implemented by
fixed_string (allowing the proper implementation to be called).

The complete basic_string interface is implemented by
detail::basic_string_impl (which is based on flex_string), so for example,
at( szie_t ) is used to implement operator[] as well and [const_]iter_offset
is used for the begin(), end() variations.

>2. I couldn't find any background discussion on what non-const operations
>should be allowed on the string. Only the std::string interface is
>but since the fixed_string is guaranteed to be continuos it makes sense to
>also allow non-const access to the string.

There wasn't that much discussion, although John is in favour of const-only
(safer). Feel free to add to the discussion and I'll take a lopok at
implementing them if they are reasonable.

>In both versions c_str() is const while data() is const only in the sandbox
>version. I think a const c_str() and non-const data() (as an overload to
>the std::string interface) is the way to go.

The only objection to this I can see would be relating to the safety of the
underlying string and co buffer overflow quarantees on using the non-const

>3. As mentioned in other posts, length is messy and I don't think there are
>any way to safely store the length inside the class. There will always be a
>risk that the non-const operations add/removes a '\0' in the wrong place.

Maybe the c_str() in fixed_string< n, CharT > should perform a validation to
ensure that:
   str[ len ] == CharT()
and optionally (it is not a requirement that this holds, if it does not,
then the full string is not printable, just as if you tried to output
   str[ 0..(len - 1)] != CharT()

That way the string integrity is kept, while allowing simple implementations
of operations such as length and push_back.

>solution may be to add something similar to the CString's "ReleaseBuffer()"
>(with a better name) that allows you to force an update of the length after
>unsafe operation.

That is a possibility (see John's implementation). The question is: how does
this affect performance? I am not saying my solution is the way to go, just
evaluating the various options.

>And last just an idea I got from the flex_string implementation: Why not
>use of the "struct hack" as a performance option. e.g.

This is interesting. Does it have any specific advantages over the two


Want to block unwanted pop-ups? Download the free MSN Toolbar now!

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