Boost logo

Boost :

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;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk