Re: [boost] Re: static sized strings

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-06-22 10:42:52

From: "Reece Dunn" <msclrhd_at_[hidden]>
> Rob Stewart wrote:
> >From: "Reece Dunn"
> > >
> > > consider when doing this is that the strings don't exceed capacity,
> > > resulting in additional logic.
> >
> >That should fail, shouldn't it?  Yes, that would mean a swap()
> >that throws, but the strings aren't really swapped if you only
> >swap some characters.
> 
> The same is true though of all the other functions (e.g. assign): what 
> happens if the string doesn't fit?

Those are different functions with different semantics.
Assignment can fail for a variety of reasons.  swap() isn't
supposed to and it isn't supposed to throw.

> >I'm not sure which is worse: a swap() that throws or only
> >partially swapping.  The former violates exception safety
> >guarantee assumptions made by other code, but the latter means
> >that swap() may not really swap, which violates semantics.
> 
> I have gone for a clip to capacity design for all the fixed_string 
> functions. Thus:
> 
>    fixed_string< 5 > str;
>    str.assign( "Hello there!" ); // str == "Hello"

That's perfectly reasonable but doesn't implicitly apply to
swap().  It may be that there is no better solution than to apply
that to swap(), but I don't think it does just because it applies
to assign().

> Any error handling policy that is implemented has it's own advantages and 
> disadvantages. Another problem with using exceptions is adapting C code: 
> there may not be any try-catch blocks in the code, resulting in unhandled 
> exceptions.

The good news is that C code won't call swap()!  That is, any
code written in the C way won't think to call swap(); that's a
C++ idiom.  (Yes, I realize that we're talking about converting C
code to use a C++ class, so many changes are possible, but I'm
assuming that minimal changes are intended to such code.)

> The clip strategy is not ideal either, but I believe it is the best approach 
> considering the code it is abstracting: you will usually have a buffer large 
> enough for the application you are using it for (filenames/paths, command 
> line strings, URLs, etc.)
> 
> One possibility is making the error handling a policy class so it can be 
> adapted to suit the users needs with the current behaviour as default.

I think clipping is appropriate.  The whole point is that the
client is supposed to allocate a string large enough to hold the
expected data.  If the code ever tries to store more than
expected, the rest should just be truncated.  I don't think
there's any need to be fancier than that.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;