Re: [boost] Re: static sized strings

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-05-25 13:24:59

Rob Stewart wrote:
>From: "Reece Dunn" <msclrhd_at_[hidden]>
> >
> > What I am interested in is a comparison between
>
>* I think that data() would be better named "buffer."  The

This would go with the renaming you suggest for functions that are the same 
in the base and implementation classes (hiding issue).

>* Should fixed_string support zero-length strings?

You can have zero-length strings in my implementation (this is what 
fized_string() defaults to). What you *can't* have is a zero-*capacity* 
string, which is the same as CharT[ 0 ].

>* I'm not sure that there's enough value in
>   const_iter_offset()/iter_offset() versus begin()/end() (const
>   and non-const) in the derived class.  You eliminate four
>   trivial functions, but you may eliminate opportunities for
>   optimizations.  (I'm thinking there may be derived types that
>   have a better way of computing end and that returning the
>   result of adding zero to a pointer is slower than simply
>   returning the pointer.)

This is true. I will probably expand the interface to the four begin/end 
functions.

>* fixed_string doesn't have a const overload of at().

I shall fix this.

>   Calling fixed_string's at() "at" seems wrong.  You should take the tack
>   of requiring a derivate of detail::basic_string_impl to provide
>   uniquely named, implementation functions that basic_string_impl
>   uses to provide the public interface.  You could even suggest
>   that such functions be made private with the basic_string_impl
>   specialization made a friend.  Your current approach will
>   generate many "hiding" warnings, too.

I will rename the conflicting names.

>* fixed_string's at() shouldn't test the length and throw an
>   exception since detail::basic_string_impl::at() does it and
>   detail::basic_string_impl::operator[] calls it.

fixed_string tests against capacity as a measure against [] usage that would 
cause buffer overflow, e.g.
   fixed_srting< 5 > str;
   str[ 10 ] = 'a'; // ok: exception
vs
   char str2[ 5 ];
   str[ 10 ] = 'a'; // foobar

>* fixed_string::swap() is missing.
>* detail::basic_string_impl::get_allocator() expects
>   string_type::get_allocator() but that isn't listed in the
>   requirements levied on the derived type and isn't defined in
>   fixed_string.

These are currently missing becase (1) swap requires a deep copy and haven't 
implemented that yet; (2) allocators are not used by fixed_string (no need 
to allocate any data) so it is not implemented (I am considering if/how it 
should be implemented). NOTE: it should compile despite these missing from 
fixed_string unless you attempt to call those functions.

>* I wouldn't expect fixed_string's StringPolicy to govern how to
>   determine the length of a string passed to a mf as a CharT *.

It does not. string_type::length() returns the value of the string held in 
the class (return a variable value, defer to container, use traits_type, 
etc.). traits_type::length( const CharT * ) calculates the length of a 
string passed to it, wher traits_type is a char_triats compatible interface.

>* If I kept looking, I'm sure I'd find many more things, but you
>   are more interested in philosophical differences, so I'll stop
>   here.  Look at the end of the message for my summary.

I am actually interested in both. The feedback is appreciated and I will use 
it to improve the code.

>I think John's approach is better, only because it does less type
>indirection.  It relies on the more ordinary pvf approach to the
>core functionality.  Otherwise, the two libraries provide the
>same functionality (or can when complete).

To simplify my design, I could implement basic_string_impl using the policy 
approach that flex_string uses. The problem with this is that it requires a 
usage like:

   flex_string< fixed_string< 10, char > > str;

so in order to get the fixed_string< n > syntax, I would need two classes 
instead of just the one: this was something I was trying to move away from, 
but the approach I use has several problems:

[1] the code is less optimal (7.5k vs 5k on MS VC 7.1) in my approach, due 
to the indirection used; the flex_string policy approach would allow 
compilers to aggressively inline.

[2] the implementation functions are exposed in the interface; a policy 
approach would allow the implementation to be hidden because it can be 
derived from it like flex_string.

[3] in my current approach, I can't use typedefs from the StringPolicy in 
basic_string_impl (they are not defined yet); seperate classes will solve 
this.

There may be others to this list. So I am going to change to the flex_string 
approach and see what happens :).

Regards,
Reece

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo