Re: [boost] Re: static sized strings

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-06-22 19:07:24

Rob Stewart wrote:
>From: "Reece Dunn" <msclrhd_at_[hidden]>
> > [1] How do I pass the buffer and capacity to the implementation while
> > allowing both fixed_string_base and fixed_string access to the 
>basic_string
> > interface? I have chosen to route the data through one of the 
>basic_string
> > constructors, requiring a const_cast. This is the best approach AFAICS.
>
>I haven't looked at your recent implementation, and I don't
>presently have the time, so I really don't know what you're
>talking about.  If you can explain the dependencies to which you
>refer, I'd appreciate it.  I think it has bearing on the swap()
>discussion.

I have a class called detail::fixed_string_impl that has three data members: 
size, capacity and a pointer to the data buffer (len, cap and str 
respectively). Doing this allows the virtual functions to be removed and the 
implementation moved out of fixed_string.

The fixed_string class can then pass its buffer and the capacity template 
parameter to the implementation via a constructor. The problem is that 
fixed_string is derived from fixed_string_base, which itself is derived from 
detail::basic_string_impl. This is needed to allow both fixed_string and 
fixed_string_base to have access to the full basic_string interface (like 
was done in the old implementation).

The solution I have taken is to use the basic_string_impl( const CharT * s, 
size_type l ) constructor and use this to pass the buffer (s) and capacity 
(l) to the string. This is not ideal since it requires a const_cast to 
extract the buffer. This required modifying the constructor implementation 
in basic_string_impl to forward the parameters to Base and not implement 
them using append.

The old implementation had the same problem with swap as the current one, 
since the string would get clipped when it is copied. For now, I will leave 
the implementation of swap as is (i.e. clipping and not signalling an 
exception), but add a note on this issue in the docs so that users are aware 
of it.

Another problem I can forsee is using a custom char_traits or format_policy 
class, e.g.

   boost::fixed_string< 20, char, std::char_traits< char > > s1;
   strcpy( s1, "Hello" ); // ok

   boost::fixed_string< 20, char, win_char_traits< char > > s2;
   strcpy( s2, "There" ); // error

This is the problem shared with basic_string when implementing functions 
using std::string.

I have also fixed the problems relating to using the strxxx functions with 
Borland: the compiler may set them as instrinsic and add a macros defining 
strxxx as __strxxx__. To get around this, I now detect if they are macros 
and the Borland compiler is being used, then create an inlined function to 
the __strxxx__ version.

Regards,
Reece

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