Re: [boost] Re: static sized strings

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-05-13 10:54:39

Rob Stewart wrote:
>From: David Abrahams > John Nagle writes:
> >
> > >     If you're willing to accept a call to "new", you can just
> > > use std::string and reserve some initial size.
> >
> > It's not the same thing.  You might only be willing to accept a call
> > to "new" if things go beyond a certain length.  That's *usually* the
> > only reason I'd ever have a fixed-size buffer.  Very occasionally
> > I'll be in code that where I don't want to throw an exception, but
> > then a string that responds to overflow by throwing is no better.
>
>char_string can throw a more meaningful exception than
>std::bad_alloc.
>
>In the small string optimization or std::string with reserve
>approaches, the buffer grows when the input is too large, and
>other, downstream code may overflow or behave badly.  Stopping
>the overflow early may be better and having an automated
>mechanism for preventing overflow is wise.

There is not meant to be any buffer allocation. char_string is a 
fixed-capacity string that will not write beyond the length of that buffer.

> > > So you don't need that capabiilty in char_string.  char_string is
> > > for situations when you don't want to invoke dynamic allocation at
> > > all.  In desktop applications, that's not too common, but in real
> > > time work, inside operating systems, and in embedded applications
> > > it's not unusual.
> >
> > I'm saying, it's almost always better to degrade performance
> > gracefully as the program's input grows than it is to introduce an
> > execution discontinuity like an exception (if possible).  In many of
> > those scenarios you've named, exceptions, like dynamic allocation have
> > been banned anyway for similar real and/or imaginary reasons.
>
>There's probably room and need for both types of strings.

I don't intend the char_string buffer to be increased. I intended that the 
operations on the buffer would not go beyond the buffer (which would lead to 
overflow) and also that going over the buffer would not generate an 
exception.

It may be beneficial to have an error policy to determin the behaviour in 
the event of an overflow. I am not advocating this approach, just putting it 
up for discussion.

The only exception I can see keeping is the one in the constructor to test 
for a buffer of 0, but this would be better re-implemented as a compile-time 
check using mpl code, e.g.:

template< int n, ... >
class char_string
{
   class ok{ typedef char value; };
   class zero_buffer_error{};

   typedef mpl::if_< mpl::equal< n, 0 >, zero_buffer_error, ok >::value 
value;
};

Regards,
Reece

_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess