RE: [boost] Re: static sized strings

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 
>need
>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 
>less
>useless. E.g. a function taking a "base" argument can't iterate or look at 
>the
>string content without converting it to a c-string (so it could just as 
>well
>use a c-string argument). Why not implement the full interface in the base
>class?

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 
>mentioned
>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 
>keep
>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 
data.

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

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 
"Hello\0Foobar!"):
   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 
>an
>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 
>allow
>use of the "struct hack" as a performance option. e.g.
>
>[snip]

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

Regards,
Reece

_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!  
http://toolbar.msn.co.uk/