Boost logo

Boost :

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
> > interface? I have chosen to route the data through one of the
> > 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()

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.


Express yourself with cool new emoticons

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